DB2 v8 32 bit on Solaris 64 bit
Amy DBA
64-bit platform. It seems like whomever installed DB2 on the server,
goofed for not installing DB2 v8 64 bit. Do I understand correctly,
that DB2 cannot take advantage of the additional memory segments that
our 64-bit platform has unless we upgrade to 64-bit DB2 v8?
--Amy
Darin McBride
There is no way that I'm aware of to not install the 64-bit code on
Solaris.
To take advantage of all 64-bit has to offer, you "simply" need to run
/opt/IBM/db2/V8.1/instance/db2iupdt -w 64 <instance>
I say "simply" in quotes because if you have any 32-bit stored
procedures or other 32-bit applications, it may take a bit more work to
get them to work in a 64-bit instance environment. Thus, the
recommended approach is to create a new instance as 64-bit, copy/link
your code into that instance, and test before moving your production
system to 64-bit.
Note that, unlike v7, if you find 64-bit isn't working for you, you can
use db2iupdt to update back to 32-bit.
Worst case scenario is to have a 32-bit client instance where you run
your applications, and a 64-bit server instance, even on the same box,
to allow your server to take advantage of all 64-bit has to offer while
still allowing legacy 32-bit apps to work. (32-bit stored procedures
are more likely to just work than other 32-bit applications.)
I'm sure there's a technote or something somewhere on getting 32-bit
stuff to work with 64-bit instances.
John
That's correct. Sometimes this is done because of application or third
party vendor applications like PeopleSoft, Informatica, etc...The
future is 64-bit for all the obvious reasons. Flick
Phil Gunning
32-bit instances that are shared memory constrained, then 54-bit will
alleviate that problem. Some shops can't go 64-bit because of ISV
software limitations, but if that's not the case, then I'd go for it.
Phil
tech....@gmail.com (Amy DBA) wrote in message news:<17577da0.04081...@posting.google.com>...
Amy DBA
> There is no way that I'm aware of to not install the 64-bit code on
> Solaris.
when I type in 'db2level' I get this:
DB21085I Instance "arcsight" uses "32" bits and DB2 code release
"SQL08014"
with level identifier "02050106".
Informational tokens are "DB2 v8.1.0.32", "s031027", "U488487", and
FixPak "4".
Product is installed at "/opt/IBM/db2/V8.1".
> To take advantage of all 64-bit has to offer, you "simply" need to run
> /opt/IBM/db2/V8.1/instance/db2iupdt -w 64 <instance>
I'll keep your suggestion in mind for our next planned outage. For
now, I'm just going to scale back the DB config to avoid the shared
memory problems we've been having. *groan*
Amy DBA
> Amy, that is correct. Currently, 64-bit is the future.....if you have
> 32-bit instances that are shared memory constrained, then 54-bit will
> alleviate that problem. Some shops can't go 64-bit because of ISV
> software limitations, but if that's not the case, then I'd go for it.
I don't know how someone managed to get the wrong version of DB2
installed on the server, but we've had Sun OS support tell us that our
Shared Memory was being chewed up by the database manager. When I
checked the DB config, it was configured as if 64 Bit DB2 was
installed, when it obviously was not.
Looks like I've got some DBA work to do...
Darin McBride
> Darin McBride <dmcb...@naboo.to.org.no.spam.for.me> wrote in message
> news:<fidSc.70606$J06.52037@pd7tw2no>...
>
>> There is no way that I'm aware of to not install the 64-bit code on
>> Solaris.
>
> when I type in 'db2level' I get this:
> DB21085I Instance "arcsight" uses "32" bits and DB2 code release
> "SQL08014"
> with level identifier "02050106".
> Informational tokens are "DB2 v8.1.0.32", "s031027", "U488487", and
> FixPak "4".
> Product is installed at "/opt/IBM/db2/V8.1".
Yes - there is also no way that I'm aware of to not install the 32-bit
code on Solaris.
You get both - and you can choose at install time or any later point to
use 32-bit, 64-bit, or both (in different instances).
Your instance happens to be 32-bit currently.
>> To take advantage of all 64-bit has to offer, you "simply" need to run
>> /opt/IBM/db2/V8.1/instance/db2iupdt -w 64 <instance>
>
> I'll keep your suggestion in mind for our next planned outage. For
> now, I'm just going to scale back the DB config to avoid the shared
> memory problems we've been having. *groan*
You may want to create a 64-bit instance to test your application
against to see if you even want to move to 64-bit. Well, maybe I'll
rephrase that a bit: you should want to move to 64-bit, but with a test
instance, you'll be better able to see how much work that is. Without
taking down your current production 32-bit instance.
Hope that helps,
Amy DBA
From: "Darin McBride" <dmcb...@naboo.to.org.no.spam.for.me>
> You may want to create a 64-bit instance to test your application
> against to see if you even want to move to 64-bit. Well, maybe I'll
> rephrase that a bit: you should want to move to 64-bit, but with a test
> instance, you'll be better able to see how much work that is. Without
> taking down your current production 32-bit instance.
>
> Hope that helps,
I figured I would have to do something of the sort. I just couldn't beleive
what I was seeing when I found that the instance was 32-bit. grumble...
**amy**
Amy DBA
> /opt/IBM/db2/V8.1/instance/db2iupdt -w 64 <instance>
Anyone have any practical experience doing this upgrade? The technotes on
the IBM support site make it look pretty buggy.
> I say "simply" in quotes because if you have any 32-bit stored
> procedures or other 32-bit applications, it may take a bit more work to
> get them to work in a 64-bit instance environment. Thus, the
> recommended approach is to create a new instance as 64-bit, copy/link
> your code into that instance, and test before moving your production
> system to 64-bit.
We have only a few stored procedures. How to I tell if they are 32-bit or
not? They were compiled under the 32-bit instance, but are designed to work
with a 64-bit application.
Amy
Darin McBride
>
> "Darin McBride" <dmcb...@naboo.to.org.no.spam.for.me> wrote in message
>> To take advantage of all 64-bit has to offer, you "simply" need to run
>> /opt/IBM/db2/V8.1/instance/db2iupdt -w 64 <instance>
>
> Anyone have any practical experience doing this upgrade? The technotes on
> the IBM support site make it look pretty buggy.
Due to the differences in each instance, nevermind differences between
your company and any other, most people seem comfortable only if it
works in their environment - almost a catch-22.
So, for the paranoid among us (when it concerns a production database,
anyone who isn't paranoid probably should find a new, less stressful,
line of work ;->), the recommended path is always to create a test
instance with your stored procs, and hopefully some test data, perform
the upgrade, and test the upgraded 64-bit instance. Once you feel
comfy, then use a scheduled downtime to perform the real upgrade.
Assuming you find problems, you may need to recompile your stored procs
against the 64-bit instance. Off the top of my head, I can't think of
anything else that would go wrong.
Amy DBA
inline. How do I tell if my stored procedures are 32-bit or 64-bit?
"Darin McBride" <dmcb...@naboo.to.org.no.spam.for.me> wrote in message
news:QzxTc.107788$gE.105982@pd7tw3no...
Darin McBride
> Thanks again for the reply. I had another question a bit further down
> inline. How do I tell if my stored procedures are 32-bit or 64-bit?
I don't think 64-bit stored procs work in 32-bit instances, but I'm not
100% positive of that. Other than that, I'm not sure how to tell ...
I'm hoping someone else answers that question ;-)
Larry
in a 64-bit environment in order to be 64-bit.
Larry Edelstein
Simon Tobias
"Larry" <La...@nospam.net> wrote in message
news:TXUTc.222$vc4....@news4.srv.hcvlny.cv.net...
> If I'm not mistaken, stored procs must be compiled by a 64-bit compiler
> in a 64-bit environment in order to be 64-bit.
That's my understanding also.
The OS 'file' command *should* distinguish between a 32-bit and 64-bit
shared object/executable, e.g.
file myapp.so
On Solaris SPARC, you should see :
myexe32: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
myexe64: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, stripped
or
myso32.so: ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically
linked, not stripped
myso64.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically
linked, not stripped
SimonT.