Troubleshooting
Problem
When TSM API reason code "36" is received: 1) You might receive the following error when performing a database backup to Tivoli Storage Manager (TSM): [
] SQL2033N An error occurred while accessing TSM during the processing of a database utility. TSM reason code: "36". or SQL2062N An error occurred while accessing media "/home/db2inst8/sqllib/adsm/libtsm.a". Reason code: "36".[] 2) Archive of LOG Files to TSM does not work because of TSM API rc = 36Symptom
1) Database backup to TSM fails with SQL2033N (SQL2062N) and TSM reason code: "36" if database configuration parameter VENDOROPT is set.
2) Archiving of database LOG Files to TSM does not work and fails with TSM API rc = 36 if LOGARCHOPT1 (LOGARCHOPT2) is set.
Cause
The implementation of TSM APAR IC49231 is the cause of the problem. An application using FromNode or FromOwner will be prevented from doing a backup or archive.
APAR description:
TSM API DOES NOT BLOCK SESSIONS WITH FROMNODE OR FROMOWNER FROM
PERFORMING BACKUPS UP OR ARCHIVES
One example why VENDOROPT may be set:
In a DB2 HADR environment, it is needed to use "-fromnode" and "-fromowner" option in the DB2 database configuration parameter VENDOROPT for the stand-by database to be able to receive LOAD copies from the primary machine through TSM. If a HADR takeover takes place, the old primary database becomes a stand-by and needs to set the parameters in their database configuration to point to the old stand-by (now primary) machine.
AND it is needed to remove the VENDOROPT value from the new primary machine. If this is not done, the error SQL2033N (SQL2062N) with TSM reason code: "36" will occur.
If used, the HADR takeover script needs to set and reset the VENDOROPT and/or LOGARCHOPT1/LOGARCHOPT2 values.
APAR description:
TSM API DOES NOT BLOCK SESSIONS WITH FROMNODE OR FROMOWNER FROM
PERFORMING BACKUPS UP OR ARCHIVES
One example why VENDOROPT may be set:
In a DB2 HADR environment, it is needed to use "-fromnode" and "-fromowner" option in the DB2 database configuration parameter VENDOROPT for the stand-by database to be able to receive LOAD copies from the primary machine through TSM. If a HADR takeover takes place, the old primary database becomes a stand-by and needs to set the parameters in their database configuration to point to the old stand-by (now primary) machine.
AND it is needed to remove the VENDOROPT value from the new primary machine. If this is not done, the error SQL2033N (SQL2062N) with TSM reason code: "36" will occur.
If used, the HADR takeover script needs to set and reset the VENDOROPT and/or LOGARCHOPT1/LOGARCHOPT2 values.
Diagnosing The Problem
Find the return code structure that was returned from TSM in the db2diag.log. It shows TSM rc "36".
1) Sample db2diag.log for the Backup with VENDOROPT set:
2) Sample db2diag.log for LOG Archive with LOGARCHOPT1 set:
1) Sample db2diag.log for the Backup with VENDOROPT set:
2008-09-17-12.00.46.273160+120 E4976A396 LEVEL: Info
PID : 897070 TID : 1 PROC : db2agent (SAMPLE) 0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-1332 APPID: *LOCAL.db2inst1.080917100047
AUTHID : DB2INST1
FUNCTION: DB2 UDB, database utilities, sqlubSetupJobControl, probe:1410
MESSAGE : Starting an offline db backup.
2008-09-17-12.00.46.505087+120 I5373A664 LEVEL: Error
PID : 1134698 TID : 1 PROC : db2med.897070.0 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, database utilities, sqluMapVend2MediaRCWithLog, probe:939
DATA #1 : String, 108 bytes
Vendor error: rc = 11 returned from function sqluvint.
Return_code structure from vendor library libtsm.a:
DATA #2 : Hexdump, 48 bytes
0x0FFFFFFFFFFFD278 : 0000 0024 3538 3220 3336 0000 0000 0000 ...$582 36......
0x0FFFFFFFFFFFD288 : 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0FFFFFFFFFFFD298 : 0000 0000 0000 0000 0000 0000 0000 0000 ................
2008-09-17-12.00.46.505776+120 I6038A316 LEVEL: Error
PID : 1134698 TID : 1 PROC : db2med.897070.0 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, database utilities, sqluMapVend2MediaRCWithLog, probe:979
MESSAGE : Error in vendor support code at line: 582 rc: 362) Sample db2diag.log for LOG Archive with LOGARCHOPT1 set:
2008-09-17-12.06.30.696713+120 I1443A312 LEVEL: Warning
PID : 688150 TID : 1 PROC : db2logmgr (SAMPLE) 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3108
MESSAGE : Started archive for log file S0000000.LOG.
2008-09-17-12.06.30.884573+120 E1756A680 LEVEL: Error
PID : 688150 TID : 1 PROC : db2logmgr (SAMPLE) 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpInitVendorDevice, probe:1030
MESSAGE : Init failed! Vendor rc info:
DATA #1 : Vendor RC, PD_DB2_TYPE_VENDOR_RC, 4 bytes
Vendor RC=0x0000000B=11 -- see DB2 API Guide for meaning.
DATA #2 : Hexdump, 48 bytes
0x0FFFFFFFFFFFD0E0 : 0000 0024 3538 3220 3336 0000 0000 0000 ...$582 36......
0x0FFFFFFFFFFFD0F0 : 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0FFFFFFFFFFFD100 : 0000 0000 0E62 377C 0000 0000 0000 0000 .....b7|........
2008-09-17-12.06.30.894283+120 I2437A287 LEVEL: Error
PID : 688150 TID : 1 PROC : db2logmgr (SAMPLE) 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogVendor, probe:1820
RETCODE : ZRC=0x0000000B=11
2008-09-17-12.06.30.909151+120 E2725A406 LEVEL: Warning
PID : 688150 TID : 1 PROC : db2logmgr (SAMPLE) 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3150
MESSAGE : ADM1848W Failed archive for log file "S0000000.LOG" to "TSM chain 0"
from "/databases/db2inst1/NODE0000/SQL00002/SQLOGDIR/".
2008-09-17-12.06.30.909495+120 I3132A400 LEVEL: Error
PID : 688150 TID : 1 PROC : db2logmgr (SAMPLE) 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3160
MESSAGE : Failed to archive log file S0000000.LOG to TSM chain 0 from
/databases/db2inst1/NODE0000/SQL00002/SQLOGDIR/ with rc = 11.Resolving The Problem
Do not set VENDOROPT or LOGARCHOPT1 (LOGARCHOPT2) in the database configuration if database backups needs to be done.
Modify the HADR takeover script to set and reset the LOGARCHOPT1 (LOGARCHOPT2) values.
Modify the HADR takeover script to set and reset the LOGARCHOPT1 (LOGARCHOPT2) values.
[{"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"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"9.5;9.1;8","Edition":"Enterprise Server;Express;Workgroup Server","Line of Business":{"code":"LOB10","label":"Data and AI"}},{"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Recovery - Backup","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Was this topic helpful?
Document Information
Modified date:
08 December 2022
UID
swg21319072