Results 1 to 12 of 12
  1. #1
    Join Date
    Nov 2007
    Posts
    265

    Unanswered: 32 bit instance on 64 bit linux O/S

    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!!
    Last edited by db2user24; 04-21-11 at 17:31.

  2. #2
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    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

  3. #3
    Join Date
    Nov 2007
    Posts
    265
    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.

  4. #4
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    What is not working? How about supplying us with any error messages. Can you supply the full output of db2level from both instances?

    Andy

  5. #5
    Join Date
    Nov 2007
    Posts
    265
    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
    Last edited by db2user24; 04-21-11 at 17:37.

  6. #6
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1
    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.

  7. #7
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    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

  8. #8
    Join Date
    Nov 2007
    Posts
    265
    Quote Originally Posted by ARWinner View Post
    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.

  9. #9
    Join Date
    Nov 2007
    Posts
    265
    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..

  10. #10
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,369
    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.

  11. #11
    Join Date
    Nov 2007
    Posts
    265
    Quote Originally Posted by BELLO4KA View Post
    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?

  12. #12
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,369
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •