8 Replies Latest reply: Dec 16, 2009 2:32 PM by Olaf Balzer RSS

Not able to connect to DB due to SQL2071N error

Joean Yun
Currently Being Moderated

Hi,

 

We restored an SAP BI 7.0 system running on AIX 5.3 and DB2 9.1.0.4 FixPack 4 64-bit system using UNIX file level restoration on an existing AIX server from a backup media.

 

After restoration, I changed the hostnames and file permissions and managed to be able to issue "db2start" and "db2stop" successfully for the restored database.

 

However I am currently facing a problem connecting to the database, eventhough I am able to issue the command u201Cdb2startu201D successfully to start the Database Manager, whenever I try to execute u201Cdb2 connect to DBXu201D, I get the following error:

    

SQL2071N  An error occurred while accessing the shared library

"/usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.a". Reason code: "2".

   

Iu2019ve done some Googling and some people have had similar issue (http://www.dbforums.com/db2/1638554-sql1651n-during-redirect-restore.html) , and they recommended using the command u201Cdb2 update db cfg for DBX using LOGARCHMETH1 offu201D to change the value of LOGARCHMETH1 to u2018OFFu2019. I tried updating the DB CFG parameter value of LOGARCHMETH1 to u2018OFFu2019, but for some reason eventhough the system replied that the update was successful, everytime I retrieve the value of LOGARCHMETH1 again (through "db2 get db cfg for DBX | grep -i log") itu2019s still showing u201CVENDOR:/usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.au201D, even after I tried u201Cdb2stopu201D and u201Cdb2startu201D again.

   

From this SDN forum thread ( Re: SQL1651N - during Redirect Restore), they recommended to use the program brdb6brt and version recovery method using "without rolling forward" to perform the redirected restore.

 

My question is, without resorting to another restore/backup:

 

1. Would enabling TSM on the current setup help?

 

2. Restoring the missing directory "/usr/tivoli/tsm/tdp_r3/*" on the destination server, would this help?

 

3. Any other suggestions/ideas on why the parameter change isn't reflected eventhough the system reported that the change was successful? (e.g. "DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.")

 

-


 

Below are the current parameter values from "db2 get db cfg":

   

Log retain for recovery status                          = NO

User exit for logging status                            = YES

Catalog cache size (4KB)              (CATALOGCACHE_SZ) = 2560

Log buffer size (4KB)                        (LOGBUFSZ) = 1024

Log file size (4KB)                         (LOGFILSIZ) = 16380

Number of primary log files                (LOGPRIMARY) = 20

Number of secondary log files               (LOGSECOND) = 40

Changed path to log files                  (NEWLOGPATH) =

Path to log files                                       = /db2/DBD/log_dir/NODE0000/

Overflow log path                     (OVERFLOWLOGPATH) =

Mirror log path                         (MIRRORLOGPATH) =

First active log file                                   = S0005379.LOG

Block log on disk full                (BLK_LOG_DSK_FUL) = YES

Percent max primary log space by transaction  (MAX_LOG) = 0

Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0

Percent log file reclaimed before soft chckpt (SOFTMAX) = 300

Log retain for recovery enabled             (LOGRETAIN) = OFF

User exit for logging enabled                (USEREXIT) = OFF

HADR log write synchronization mode     (HADR_SYNCMODE) = NEARSYNC

First log archive method                 (LOGARCHMETH1) = VENDOR:/usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.a

Options for logarchmeth1                  (LOGARCHOPT1) = /db2/DBD/tdp_r3/vendor.env

Second log archive method                (LOGARCHMETH2) = OFF

Options for logarchmeth2                  (LOGARCHOPT2) =

Failover log archive path                (FAILARCHPATH) = /db2/DBD/log_dir/NODE0000/

Number of log archive retries on error   (NUMARCHRETRY) = 5

Log archive retry Delay (secs)         (ARCHRETRYDELAY) = 20

Log pages during index build            (LOGINDEXBUILD) = OFF

 

 

Thank you for your help.

 

Edited by: Joean Yun on Dec 15, 2009 10:33 AM

  • Re: Not able to connect to DB due to SQL2071N error
    Manoj Chintawar
    Currently Being Moderated
    "/usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.a". Reason code: "2".

     

     

    Reason code 2 and SQL2071N error indicating following. Please refer to link for further details.

     

    The library could not be loaded because it (or a library required by it) does not exist or does not have a valid format. This sometimes means that a 32-bit library is being loaded in a 64-bit instance, or vice-versa.

     

    [http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.messages.sql.doc/doc/msql02071n.html]

  • Re: Not able to connect to DB due to SQL2071N error
    Olaf Balzer
    Currently Being Moderated

    Hi Joean,

    for the moment I can answer your third question why the parameter change was not done.

    You cannot change the parameter logarchmeth1 online like showen in the official guide, you have to bring the database offline with disconnecting all database processes (the best will be the reboot). More information about this reason you can finde in APAR IY91346.

     

    Regards

     

    Olaf

     

     

    P.S: Please check the TSM installation in db2 environment (note 82029) and please check also the apar:

     

    http://www-01.ibm.com/support/entdocview.wss?uid=swg1IZ15522

     

    Edited by: Olaf Balzer on Dec 16, 2009 9:38 AM

    • Re: Not able to connect to DB due to SQL2071N error
      Joean Yun
      Currently Being Moderated

      Hi Olaf,

       

      Thank you for your reply.

       

      I have recovered the missing directory "/usr/tivoli/tsm/tdp_r3/db264/libtdpdb264.a" from the source system, however now I'm hit by another error message when trying to run the following:

       

      1. db2 connect to DBX

      2. db2 restart database DBX

       

      The error message is:

      SQL1042C  An unexpected system error occurred.  SQLSTATE=58004.

       

      Looking into the db2diag.log, I saw a very long list of errors, some relating to "ADM1532E  Crash recovery has failed with SQLCODE "-1042" and "Recovery failed, dirty pages not flushed", just to name some of them.

       

      So my question is:

       

      1. Will copying over just the UNIX file system from a backup copy of the BI system work without any usage of "db2 backup" or "db2 restore" command? This is important because at the moment this is the method we're using.

       

      2. Executing "db2 get db cfg", I noticed the following:

       

      Backup pending                                          = NO

       

      Database is consistent                                  = NO

      Rollforward pending                                     = NO

      Restore pending                                         = NO

       

      Is there any way to fix an "inconsistent" database?

       

      Thank you.

    • Re: Not able to connect to DB due to SQL2071N error
      Joean Yun
      Currently Being Moderated

      - deleted due to duplicate post -

       

      Edited by: Joean Yun on Dec 16, 2009 10:38 AM

  • Re: Not able to connect to DB due to SQL2071N error
    Olaf Balzer
    Currently Being Moderated

    Hi Joean,

    could you please let us know an actuell output of R3trans -d as your sap connect user and also an output of db2diag.log during you try to connect to database..

     

    NO indicates that a transaction is pending or some other task is pending on the database and the data is not consistent at this point. If the system "crashes" while the database is not consistent, you will need to restart the database using the RESTART DATABASE command to make the database usable. So this information does not indicate an error, but the fact that to    

    activate the database you will have to apply database logfiles.         

     

    Think the best way to backup your database is the normal db2 backup command which also includes all necessary log files for a restore.

     

     

    Regards

    Olaf

     

    Edited by: Olaf Balzer on Dec 16, 2009 2:28 PM

Actions