DB2 - Problem description
Problem IC81663 | Status: Closed |
EXTENT RECLAIM ON MDC TABLES MAY RETURN SQL0984C AND CAUSE THE INSTANCE CRASH. | |
product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
Problem description: | |
SQL0984C may occur when doing extent reclaim on MDC tables, such as: CALL SYSPROC.ADMIN_MOVE_TABLE('SCHEMA', 'TABLENAME', '', '', '', '', '', '', '', '', 'MOVE'); This may result in: SQL0984C COMMIT or ROLLBACK was not successful. Subsequent SQL statements cannot be processed. The database then undergoes crash recovery. The following conditions must be met for the problem to occur: 1) Extent reclaim (e.g. reorg, admin_move_table) of an MDC table. 2) The table must be located in an old-type DMS tablespace, i.e. a DMS table space created before 9.7 and migrated to 9.7 From db2diag.log, the error starts like this: 2011-10-14-09.35.30.079025-660 I3934177A503 LEVEL: Error PID : 475282 TID : 13610 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 DB : sample APPHDL : 0-62052 APPID: *LOCAL.testdb.111013203449 AUTHID : testdb EDUID : 13610 EDUNAME: db2agent (FDB) 0 FUNCTION: DB2 UDB, buffer pool services, sqlbDMSMapObj2Pool, probe:840 MESSAGE : ZRC=0x8402001B=-2080243685=SQLB_EMP_MAP_INFO_NOT_FOUND "EMP MAP INFO NOT FOUND" 2011-10-14-09.35.30.079198-660 I3934681A551 LEVEL: Error PID : 475282 TID : 13610 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 DB : sample APPHDL : 0-62052 APPID: *LOCAL.testdb.111013203449 AUTHID : testdb EDUID : 13610 EDUNAME: db2agent (FDB) 0 FUNCTION: DB2 UDB, buffer pool services, sqlbDMSMapObj2Pool, probe:840 DATA #1 : String, 119 bytes Obj={pool:34;obj:1963;type:0} State=x37 Parent={34;1963}, EM=125038, PP0=125040 Page=1 Cont=0 Offset=125040 BlkSize=3 The top stack trace: MarkDBBad sqldmpnd sqlptppl sqlptppl sqlpxcm1 sqlrrcom_dps sqlrrcom sqlrr_commit | |
Problem Summary: | |
See APAR Description | |
Local Fix: | |
1. Avoid extent reclaim such as "reorg table <tablename> reclaim extents only allow write access" OR 2. db2set DB2_HASH_PURGE_THRESH=0 A side effect is a potentially slower performance when dropping small tables, accompanied with a possible latch contention. However, if small tables are not being dropped frequently, this workaround will be acceptable. Setting DB2_HASH_PURGE_THRESH=0 reverts the performance of dropping small tables to the same level as pre-9.7 releases. | |
available fix packs: | |
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows | |
Solution | |
Problem first fixed in DB2 for Linux, UNIX, and Windows 9.7 Fix Pack 6 | |
Workaround | |
See APAR Description | |
BUG-Tracking | |
forerunner : APAR is sysrouted TO one or more of the following: IC84453 follow-up : | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 26.02.2012 06.06.2012 06.06.2012 |
Problem solved at the following versions (IBM BugInfos) | |
9.7. | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.7.0.6 |