IBM Support

Backup using TSM fails with SQL2071 RC=2

Question & Answer


Question

A backup using TSM is failing with SQL2071 RC=2. This backup has worked in the past, so why has it started failing?

Answer

If the backup has worked in the past, then this error may be attributed to a recent change or upgrade in libraries.

One may see the following errors in the db2diag.log:

2009-06-24-23.00.13.565849-240 E1627A401          LEVEL: Info
PID     : 282798               TID  : 1           PROC : db2agent (idle) 0
INSTANCE: myinst               NODE : 000         DB   : MYDB
APPHDL  : 0-260                APPID: *LOCAL.myinst.090625030012
AUTHID  : MYID
FUNCTION: DB2 UDB, database utilities, sqlubSetupJobControl, probe:1410
MESSAGE : Starting an online db backup.

2009-06-24-23.00.13.573772-240 E2029A971          LEVEL: Error (OS)
PID     : 316070               TID  : 1           PROC : db2med.282798.0 0
INSTANCE: myinst               NODE : 000
FUNCTION: DB2 UDB, oper system services, sqloLoadModule, probe:130
CALLED  : OS, -, dlopen
OSERR   : ENOEXEC (8) "Exec format error"
MESSAGE : Attempt to load specified library failed.
DATA #1 : Library name or path, 35 bytes
/myinst/home/sqllib/adsm/libtsm.a
DATA #2 : shared library load flags, PD_TYPE_LOAD_FLAGS, 4 bytes
2
DATA #3 : String, 428 bytes
0509-130 Symbol resolution failed for /usr/lib/libC.a[shr_64.o] because:
0509-136   Symbol __Lock__SetupDCEThreadExceptions (number 71) is not exported from
  dependent module /usr/lib/libC.a[shrcore_64.o].
0509-022 Cannot load module /myinst/home/sqllib/adsm/libtsm.a.
0509-026 System error: Cannot run a file that does not have a valid format.
0509-192 Examine .loader section symbols with the
'dump -Tv' command.

2009-06-24-23.00.13.574723-240 E3001A853          LEVEL: Error (OS)
PID     : 316070               TID  : 1           PROC : db2med.282798.0 0
INSTANCE: myinst               NODE : 000
FUNCTION: DB2 UDB, oper system services, sqloLoadModule, probe:140
CALLED  : OS, -, dlopen
OSERR   : ENOEXEC (8) "Exec format error"
MESSAGE : Attempt to load specified library augmented with object name failed.
DATA #1 : Library name or path, 45 bytes
/atvudbp1/home/sqllib/adsm/libtsm.a(shr_64.o)
DATA #2 : shared library load flags, PD_TYPE_LOAD_FLAGS, 4 bytes
262146
DATA #3 : String, 268 bytes
0509-022 Cannot load module /myinst/home/sqllib/adsm/libtsm.a(shr_64.o).
0509-153   File /myinst/home/sqllib/adsm/libtsm.a is not an archive or
  the file could not be read properly.
0509-026 System error: Cannot run a file that does not have a valid format.

2009-06-24-23.00.13.574912-240 I3855A362          LEVEL: Warning
PID     : 316070               TID  : 1           PROC : db2med.282798.0 0
INSTANCE: atvudbp1             NODE : 000
FUNCTION: DB2 UDB, database utilities, sqluInitVendorDevice, probe:136
MESSAGE : Media controller -- fail to load vendor share library. lib =
          /atvudbp1/home/sqllib/adsm

2009-06-24-23.00.13.575055-240 I4218A346          LEVEL: Warning
PID     : 316070               TID  : 1           PROC : db2med.282798.0 0
INSTANCE: myinst               NODE : 000
FUNCTION: DB2 UDB, database utilities, sqluMCInitBackupMC, probe:982
MESSAGE : Media controller -- vendor device initialization error (zrc =
          0x00000002)

2009-06-24-23.00.13.575194-240 E4565A673          LEVEL: Severe
PID     : 282798               TID  : 1           PROC : db2agent (idle) 0
INSTANCE: myinst               NODE : 000         DB   : MYDB
APPHDL  : 0-260                APPID: *LOCAL.myinst.090625030012
AUTHID  : MYID
FUNCTION: DB2 UDB, database utilities, sqlubMWResponse, probe:1042
DATA #1 : Sqlcode, PD_TYPE_SQLCODE, 4 bytes
-2071
DATA #2 : Hexdump, 42 bytes
(hexdump)

2009-06-24-23.00.13.575439-240 E5239A920          LEVEL: Severe
PID     : 282798               TID  : 1           PROC : db2agent (idle) 0
INSTANCE: myinst               NODE : 000         DB   : MYDB
APPHDL  : 0-260                APPID: *LOCAL.myinst.090625030012
AUTHID  : MYID
FUNCTION: DB2 UDB, database utilities, sqlubMWResponse, probe:1042
MESSAGE : SQL2071N  An error occurred while accessing the shared library "".
          Reason code: "".
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
 sqlcaid : SQLCA     sqlcabc: 136   sqlcode: -2071   sqlerrml: 37
 sqlerrmc: /myinst/home/sqllib/adsm/libtsm.a 2
 sqlerrp : sqlubMWR
 sqlerrd : (1) 0x00000000      (2) 0x00000000      (3) 0x00000000
           (4) 0x00000000      (5) 0x00000000      (6) 0x00000000
 sqlwarn : (1)      (2)      (3)      (4)        (5)       (6)    
           (7)      (8)      (9)      (10)        (11)    
 sqlstate:


A -2017 error is returned with reason code 2. According to documentation, this means that the shared library cannot be loaded because it is not in a valid format.

First, verify that the system has met the documented requirements for the TSM client with respect to the libC level.

Often, this error is returned after a TSM client upgrade. If a TSM client upgrade or library upgrade was performed recently, run slibclean and restart the instance. In most cases, an instance restart resolves the problem, as it ends the processes that are using the old libraries cached in memory on AIX. In most cases, after such an upgrade, an instance recycle is recommended.

However, one may still experience this error even if no recent TSM client upgrades were performed. Moreover, log archival to TSM may continue to work while the backup fails.

This may suggest that a library update has been performed on the system recently.

Run lslpp -ha on the system and look for packages related to the C compiler. Check to see if any were updated recent:

Example:

xlC.rte

         9.0.0.0   COMMIT     COMPLETE     06/21/09     10:43:49    
        9.0.0.0   APPLY      COMPLETE     06/21/09     10:43:49    

        9.0.0.9   COMMIT     COMPLETE     06/21/09     10:55:14    

        9.0.0.9   APPLY      COMPLETE     06/21/09     10:55:11    

If some xlC packages were recently updated, this may explain why the TSM couldn't load the libC.a; although nothing changed on the TSM client, something on which the TSM client depended has changed.

The log archival may be performed by processes that started before the library updates (in the following example, the processes are from June 14, before the library updates on June 21). Since old libraries are cached in memory on AIX, the log archival is not affected as they do not see the package changes:

Example:

  40001 A myinst 487852 479414   0  60 20 723e6510  6192            Jun 14      -  9:20 db2logmgr (MYDB) 0
  40001 A myinst 164552 479414   0  60 20 f22ce510  1744            Jun 14      -  1:53 db2loggr (MYDB) 0
  40001 A myinst 180988 479414   0  60 20 1a2ef8510  3440            Jun 14      - 38:10 db2loggw (MYDB) 0


For the backups, in contrast, DB2 spawns a new process to speak with the TSM client. This results in library mismatch (as the old ones are in memory), and it needs to be fixed by ending the processes to clear the old libraries in memory. For this reason, an instance restart is required.

Check the recovery history to see if it conforms to this logic. i.e., the last successful backup was before the package changes, and every backup after the package changes failed.

In this case, the issue is caused by system changes involving libraries upon which the TSM client relied. To clear out the old libraries in memory, the instance has to be restarted.

[{"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Recovery - Backup","Platform":[{"code":"PF002","label":"AIX"}],"Version":"9.7;9.5;9.1;10.1;10.5;11.1","Edition":"Enterprise Server;Express;Personal;Personal Developer's;Workgroup Server","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
16 June 2018

UID

swg21392250