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.
