469,929 Members | 1,674 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,929 developers. It's quick & easy.

Question about DB2 UDB 8.2 and 32-bit and 64-bit instances

Well, I've finally gotten UDB 8.2 FixPak 3 up and running on my HP-UX
11i system, thanks to Mr McBride and IBM support. :)

I created a 32-bit instance and that's running just fine. However, I
learned today that I need to have a 64-bit instance. So, can I create
a 64-bit instance "next to" the 32-bit instance I've got running now or
must I nuke my 32-bit instance and then create a 64-bit instance?

Thanks in advance for your help!

Peace...

Tom

Jan 6 '06 #1
4 3620
to*******@gmail.com wrote:
Well, I've finally gotten UDB 8.2 FixPak 3 up and running on my HP-UX
11i system, thanks to Mr McBride and IBM support. :)

I created a 32-bit instance and that's running just fine. However, I
learned today that I need to have a 64-bit instance. So, can I create
a 64-bit instance "next to" the 32-bit instance I've got running now or
must I nuke my 32-bit instance and then create a 64-bit instance?

Thanks in advance for your help!

Peace...

Tom


You can safely create 64-bit and 32-bit instances in parallel on the
same system.

pick a user that you want to be the owner of that instance (it has to be
a different user than the one who owns the 32bit instance), say,
dbinst64, and run the following command as root:

db2icrt -u dbinst64 -w 64 dbinst64

(this assumes that you want the fenced user to be identical to the
instance owner. If you want to keep them separate, pick another user for
the fenced userID (this also has to be distinct from the fenced userID
of the 32bit instance) and use that username for the -u flag

Hope this helps.

-- stefan
Jan 6 '06 #2
Sweet! Thanks!

Peace...

Tom

Jan 6 '06 #3
to*******@gmail.com wrote:
Well, I've finally gotten UDB 8.2 FixPak 3 up and running on my HP-UX
11i system, thanks to Mr McBride and IBM support. :)
I'm glad to hear it :-) Personally, I'm still kinda curious as to why those
problems were happening in the first place, so if you can have your
sysadmin tell me any information that would be helpful in replicating your
OS authentication system on our HP machines, I would like to kick it around
our HP guys to see if we can replicate it. That said, it's always nice
that the workarounds work, too!
I created a 32-bit instance and that's running just fine. However, I
learned today that I need to have a 64-bit instance. So, can I create
a 64-bit instance "next to" the 32-bit instance I've got running now or
must I nuke my 32-bit instance and then create a 64-bit instance?


Most definitely. You have two choices: create a new instance, or modify
your existing instance. The former is easy since you've already done this
once before: using db2icrt (with the "-w 64" flag) or db2isetup (select the
"64-bit" option on the applicable panel). The latter is just as easy:
using db2iupdt with the "-w 64" flag.

With the former, you will have two instances going - one 32-bit, one 64-bit.
On one hand, you can play natively with each (64-bit apps don't run in
32-bit instances, while 32-bit apps can be made to run in 64-bit instances,
but are much easier to run in 32-bit instances). On the other, they take
up more memory (both RAM and on disk). So you may decide to convert your
32-bit instance to 64-bit.

Doing so means that all your configuration and data will be seamlessly moved
to support 64-bit. It's also not a "do or die" scenario - you can later
decide you don't like 64-bit for your instance, move it back (db2iupdt -w
32 <instancename>), and create a brand new 64-bit instance. The only real
downside is trying to get your 32-bit applications to work in the 64-bit
instance. It can be done - some parts easier than others. Fenced mode
procedures, for example, are supposedly trivial to migrate: from what I
hear, there's no work involved at all (although there's a small performance
penalty). Unfenced procedures need to be manually moved to become fenced
procedures (64-bit engine can't load and run a 32-bit unfenced procedure).
Other applications may need to have the SHLIB_PATH tweaked to load
libraries from sqllib/lib32 since sqllib/lib will have 64-bit libraries in
it.

With separate instances, you can have your 32-bit apps running in the 32-bit
instance and talking to your 64-bit server running in the 64-bit instance
with pretty much no problem.

Just things to think about. I don't think either way is a negative - just
different.
Jan 6 '06 #4
Darin McBride wrote:

I'm glad to hear it :-) Personally, I'm still kinda curious as to why those
problems were happening in the first place, so if you can have your
sysadmin tell me any information that would be helpful in replicating your
OS authentication system on our HP machines, I would like to kick it around
our HP guys to see if we can replicate it. That said, it's always nice
that the workarounds work, too!
Well, I'm technically the sysadmin for the box so I would be the person
to work with on this. I was asked by the other IBM person working on
the problem about remote access possibility to our server, which we
don't have in place.

If it's worth it, we can discuss other options. I'll send you e-mail.
:)
With the former, you will have two instances going - one 32-bit, one 64-bit.
On one hand, you can play natively with each (64-bit apps don't run in
32-bit instances, while 32-bit apps can be made to run in 64-bit instances,
but are much easier to run in 32-bit instances). On the other, they take
up more memory (both RAM and on disk). So you may decide to convert your
32-bit instance to 64-bit.
I believe we ended up having two instances running, one 32-bit and one
64-bit. TODAY, I just got my 32-bit app updating my 64-bit database,
so I'm happy once again. :)
Other applications may need to have the SHLIB_PATH tweaked to load
libraries from sqllib/lib32 since sqllib/lib will have 64-bit libraries in
it.


Yep, this is exactly what I needed to do in addition to re-link with
the "+s" linker option.

Thanks again for all of your help! :)

Peace...

Tom

Jan 13 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Rated R1 | last post: by
5 posts views Thread by syntax | last post: by
35 posts views Thread by David Cleaver | last post: by
5 posts views Thread by Carlos Guzmán Álvarez | last post: by
7 posts views Thread by Joe Fallon | last post: by
13 posts views Thread by christian.bongiorno | last post: by
4 posts views Thread by Peter Proost | last post: by
5 posts views Thread by Lakesider | last post: by
10 posts views Thread by Topi Linkala | last post: by
17 posts views Thread by Richard Harter | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.