f



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

0
tommydkat
1/6/2006 12:34:04 AM
comp.databases.ibm-db2 12448 articles. 3 followers. arunrocks (9) is leader. Post Follow

4 Replies
598 Views

Similar Articles

[PageSpeed] 25

tommydkat@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
0
Stefan
1/6/2006 12:46:49 AM
Sweet!  Thanks!

Peace...

Tom

0
tommydkat
1/6/2006 12:52:07 AM
tommydkat@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.
0
Darin
1/6/2006 1:00:10 AM
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

0
tommydkat
1/13/2006 10:47:47 PM
Reply: