Hi all,

I just set up 64-bit DB2 V 8.1 FP 18 on one of our 64 bit linux systems. If I give db2level I get --

DB21085I Instance "db2inst1" uses "32" bits and DB2 code release "SQL08029" with
level identifier "030A0106".

I want to restores a backup image from a 32-bit installation of Db2 V 8.1 FP 15 on one of our other systems to the system above. Here is the db2level from that one --

DB21085I Instance "db2inst1" uses "32" bits and DB2 code release "SQL08028" with
level identifier "03090106".


Am I correct in assuming that I don't need to update the instance on the 64-bit installation? Basically I want to know if I need to give this command --

db2iupdt -w 64 db2inst1


thanks!!

Taking a backup image from a 32 bit 8.1 FP 15 image and restoring it to a 32 bit 8.1 FP 18 instance should work just fine.

Andy

thanks, it's actually 'Taking a backup image from a 32 bit 8.1 FP 15 image and restoring it to a 64 bit 8.1 FP 18 instance'.. has failed on me so far.. I see the log files extracted and the completed work size correct after a few hours but it fails to come to the prompt.

What is not working? How about supplying us with any error messages. Can you supply the full output of db2level from both instances?

Andy

Sure, db2level on the 32 bit version is --

DB21085I Instance "db2inst1" uses "32" bits and DB2 code release "SQL08028" with
level identifier "03090106".
Informational tokens are "DB2 v8.1.2.136", "s070720", "MI00189", and FixPak
"15".
Product is installed at "/opt/IBM/db2/V8.1".


And db2level on the 64 bit one is --

DB21085I Instance "db2inst1" uses "64" bits and DB2 code release "SQL08029" with
level identifier "030A0106".
Informational tokens are "DB2 v8.1.3.160", "s090715", "MI00295", and FixPak
"18".
Product is installed at "/opt/IBM/db2/V8.1".

Here is the restore command I ran on the 64 bit version --

db2 restore db dbname from /home/db2inst1 taken at 20110403050002 logtarget /home/db2inst1/logs/ REPLACE EXISTING COMPRLIB /home/db2inst1/sqllib/lib/libdb2compr.so


Basically, I left the command running overnight and noticed that after many hours ( 9 -10 hrs), it had not given any message saying that the restore was completed successfully, etc...seems like it was hanging. After a few hours into the restore, I gave the command -- db2 list utilities show detail and the completed work bytes gave the total size of the image so it seemed like it was done restoring even though it was hanging.


As far as the errors go, as soon as I ran the restore command, I started seeing these errors and when I checked it after I let it run overnight the errors were still showing up ( in the hang state as well) in the db2diag.log file--


2011-04-21-15.18.55.537791-300 I8654222E378 LEVEL: Warning
PID : 4771 TID : 139958417889024PROC : db2agent (DBNAME)
INSTANCE: db2inst1 NODE : 000 DB : DBNAME
APPHDL : 0-140 APPID: *LOCAL.db2inst1.110421201859
FUNCTION: DB2 UDB, base sys utilities, sqleCheckForBackupRestore, probe:10
RETCODE : ZRC=0xFFFFFBA1=-1119

2011-04-21-15.18.55.537865-300 I8654601E379 LEVEL: Severe
PID : 4771 TID : 139958417889024PROC : db2agent (DBNAME)
INSTANCE: db2inst1 NODE : 000 DB : DBNAME
APPHDL : 0-140 APPID: *LOCAL.db2inst1.110421201859
FUNCTION: DB2 UDB, base sys utilities, sqlePrepareForSerialization, probe:20
RETCODE : ZRC=0xFFFFFBA1=-1119

2011-04-21-15.18.55.537942-300 I8654981E360 LEVEL: Severe
PID : 4771 TID : 139958417889024PROC : db2agent (DBNAME)
INSTANCE: db2inst1 NODE : 000 DB : DBNAME
APPHDL : 0-140 APPID: *LOCAL.db2inst1.110421201859
FUNCTION: DB2 UDB, base sys utilities, sqleserl, probe:10
RETCODE : ZRC=0xFFFFFBA1=-1119

2011-04-21-15.18.55.538174-300 I8655342E405 LEVEL: Error
PID : 4253 TID : 140238019151616PROC : db2hmon
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, Health Monitor, HmonMainCB::refreshDbAutonomicSwitches, probe:160
MESSAGE : Failed connecting to database "DBNAME "
DATA #1 : Hexdump, 4 bytes
0x00007F8BB5508F0C : A1FB FFFF ....

2011-04-21-15.18.55.539625-300 I8655748E378 LEVEL: Warning
PID : 4770 TID : 139958417889024PROC : db2agent (DBNAME)
INSTANCE: db2inst1 NODE : 000 DB : DBNAME
APPHDL : 0-141 APPID: *LOCAL.db2inst1.110421201900
FUNCTION: DB2 UDB, base sys utilities, sqleCheckForBackupRestore, probe:10
RETCODE : ZRC=0xFFFFFBA1=-1119

2011-04-21-15.18.55.539705-300 I8656127E379 LEVEL: Severe
PID : 4770 TID : 139958417889024PROC : db2agent (DBNAME)
INSTANCE: db2inst1 NODE : 000 DB : DBNAME
APPHDL : 0-141 APPID: *LOCAL.db2inst1.110421201900
FUNCTION: DB2 UDB, base sys utilities, sqlePrepareForSerialization, probe:20
RETCODE : ZRC=0xFFFFFBA1=-1119

Are you sure /home/db2inst1/sqllib/lib/libdb2compr.so points to a 32-bit library? It should, since it was compressed on a 32-bit system.

I think you can only restore an offline backup when changing migrating the database, which is what you are doing going from 32 bit to 64.

Andy

Thanks, haven't seen anything about the offline backup within the same version.. although have read that it's necessary when going from say 8.2 to 9.5.. will let you know what I find.

Another thing that's new is the server with the restore issue is Debian Squeeze whereas our other servers are Debian etch. It almost seems like there is some clash with squeeze..

I don't know about Debian, but the restore from your source to target instance using an online / compressed image should work. Did you try to clean-up all processes/resources owned by the instance and redo the restore? You can try removing logtarget.

Thanks, I agree.. restore from an online backup should work.. yes, I cleaned all the processes.. just curious.. how could removing logtarget help?

We don't know why it's hanging so we can simplify it by removing logtarget. Make sure to remove all IPC resources (ipcrm) as well.