By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,301 Members | 1,766 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,301 IT Pros & Developers. It's quick & easy.

DB2 v8 32 bit on Solaris 64 bit

P: n/a
I've been asked to administer a DB2 V 8 (32-bit install) on a Solaris
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
Nov 12 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Amy DBA wrote:
I've been asked to administer a DB2 V 8 (32-bit install) on a Solaris
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?


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.
Nov 12 '05 #2

P: n/a
te********@gmail.com (Amy DBA) wrote in message news:<17**************************@posting.google. com>...
I've been asked to administer a DB2 V 8 (32-bit install) on a Solaris
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

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
Nov 12 '05 #3

P: n/a
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.
Phil

te********@gmail.com (Amy DBA) wrote in message news:<17**************************@posting.google. com>...
I've been asked to administer a DB2 V 8 (32-bit install) on a Solaris
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

Nov 12 '05 #4

P: n/a
Darin McBride <dm******@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".
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*
Nov 12 '05 #5

P: n/a
pg******@gunningts.com (Phil Gunning) wrote in message news:<34**************************@posting.google. com>...
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...
Nov 12 '05 #6

P: n/a
Amy DBA wrote:
Darin McBride <dm******@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,
Nov 12 '05 #7

P: n/a
----- Original Message -----
From: "Darin McBride" <dm******@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**
Nov 12 '05 #8

P: n/a

"Darin McBride" <dm******@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.
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
Nov 12 '05 #9

P: n/a
Amy DBA wrote:

"Darin McBride" <dm******@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.
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

Nov 12 '05 #10

P: n/a
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?

"Darin McBride" <dm******@naboo.to.org.no.spam.for.me> wrote in message
news:QzxTc.107788$gE.105982@pd7tw3no...
Amy DBA wrote:

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.
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

Nov 12 '05 #11

P: n/a
Amy DBA wrote:
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 ;-)

"Darin McBride" <dm******@naboo.to.org.no.spam.for.me> wrote in message
news:QzxTc.107788$gE.105982@pd7tw3no...
Amy DBA wrote:

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.
>> 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

Nov 12 '05 #12

P: n/a
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.

Larry Edelstein

Darin McBride wrote:
Amy DBA wrote:

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 ;-)
"Darin McBride" <dm******@naboo.to.org.no.spam.for.me> wrote in message
news:QzxTc.107788$gE.105982@pd7tw3no...
Amy DBA wrote:

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.
>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


Nov 12 '05 #13

P: n/a

"Larry" <La***@nospam.net> wrote in message
news:TX*****************@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.
Nov 12 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.