|
Problem IC70831
|
Status: Closed |
SQLDOBJTABINSERTRID, PROBE:1152 - DATABASE MARKED BAD |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
The occurs when creating an index on an Range Cluster Table
(i.e. a table that is created with the ORGANIZE BY KEY SEQUENCE
clause).
An error message like this will be found in the db2diag.log:
FUNCTION: DB2 UDB, data management, sqldObjTabInsertRID,
probe:1152
RETCODE : ZRC=0x87040001=-2029780991=SQLD_BADPAGE "Bad Data
Page"
DIA8500C A data file error has occurred, record id is
"".
An FODC_DBMarkedBad directory will be created in db2dump with
the following functions on the stack:
0x00002AE2179C959C
_Z15sqldDumpBadPageP8sqeAgentP8SQLD_TCBP13SQLD_PAGESLOTP11SQLB_F
IX_CBmii
+ 0x076e
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE2179B3D4B address: 0x00002AE2179B3D4B ; dladdress:
0x00002AE215FB4000 ; offset in lib: 0x00000000019FFD4B ;
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE2179B4344 _Z8sqldoisrP8sqeAgenttPtP15SQLD_OBJTAB_REC +
0x0268
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE2179E9336 address: 0x00002AE2179E9336 ; dladdress:
0x00002AE215FB4000 ; offset in lib: 0x0000000001A35336 ;
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE2179E64D5
_Z20sqldBeginIndexCreateP8sqeAgentP17SQLD_CREATEINX_CB + 0x1b3d
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE218BFDB18
_Z20sqlrlCreateIndexPartP8sqlrr_cbP8sqlrg_idP17SQLD_CREATEINX_CB
i
+ 0x006a
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE218BFE429
_Z21sqlrlCreateLocalIndexP8sqlrr_cbP8sqlrg_pdP14sqlrg_partkeydP8
sqlrg_idP18sqlrg_datapartinfoP17SQLD_CREATEINX_CBibb
+ 0x072d
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE218C0B74A
_Z18sqlrl_create_indexP8sqlrr_cbPhsS1_sS1_sS1_sP11sqlrg_xinfosmS
1_P16sqlrl_index_parmsP22sqlrl_extendedIdx_infomiiP18sqlrg_xmlIn
dexInfoP16SQLD_SCANINXINFO
+ 0x56b8
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE21832B2C9 _Z22sqlnq_create_index_endP9sqlnq_qtbiii +
0x0eb5
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
0x00002AE21832D5A1
_Z23sqlnq_create_index_stmtPP8stknode_i10actiontypePhP3loc +
0x03fb
(/home/ztoth/sqllib/lib64/libdb2e.so.1)
The problem is caused by insufficient clean up of DB2 meta when
dropping the last index in an range clustered table whose
indexes reside in a different tablespace than the table. At
this point the table still things it's indexes own a given
object ID, but another table can reuse this ID when creating an
index object. Then when new indexes on the range clustered
table are created, an attempt is made to reuse the object ID,
but we get an error because the object ID is already in use. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All users *
****************************************************************
* PROBLEM DESCRIPTION: *
* The occurs when creating an index on an Range Cluster Table *
* (i.e. a table that is created with the ORGANIZE BY KEY *
* SEQUENCE clause). *
* *
* An error message like this will be found in the db2diag.log: *
* FUNCTION: DB2 UDB, data management, sqldObjTabInsertRID, *
* probe:1152 *
* RETCODE : ZRC=0x87040001=-2029780991=SQLD_BADPAGE "Bad Data *
* Page" *
* DIA8500C A data file error has occurred, record id *
* is "". *
* *
* An FODC_DBMarkedBad directory will be created in db2dump *
* with the following functions on the stack: *
* 0x00002AE2179C959C *
* _Z15sqldDumpBadPageP8sqeAgentP8SQLD_TCBP13SQLD_PAGESLOTP11SQ *
* LB_FIX_CBmii + 0x076e *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE2179B3D4B address: 0x00002AE2179B3D4B ; dladdress: *
* 0x00002AE215FB4000 ; offset in lib: 0x00000000019FFD4B ; *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE2179B4344 *
* _Z8sqldoisrP8sqeAgenttPtP15SQLD_OBJTAB_REC + 0x0268 *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE2179E9336 address: 0x00002AE2179E9336 ; dladdress: *
* 0x00002AE215FB4000 ; offset in lib: 0x0000000001A35336 ; *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE2179E64D5 *
* _Z20sqldBeginIndexCreateP8sqeAgentP17SQLD_CREATEINX_CB + *
* 0x1b3d *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE218BFDB18 *
* _Z20sqlrlCreateIndexPartP8sqlrr_cbP8sqlrg_idP17SQLD_CREATEIN *
* X_CBi + 0x006a *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE218BFE429 *
* _Z21sqlrlCreateLocalIndexP8sqlrr_cbP8sqlrg_pdP14sqlrg_partke *
* ydP8sqlrg_idP18sqlrg_datapartinfoP17SQLD_CREATEINX_CBibb + *
* 0x072d *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE218C0B74A *
* _Z18sqlrl_create_indexP8sqlrr_cbPhsS1_sS1_sS1_sP11sqlrg_xinf *
* osmS1_P16sqlrl_index_parmsP22sqlrl_extendedIdx_infomiiP18sql *
* rg_xmlIndexInfoP16SQLD_SCANINXINFO + 0x56b8 *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE21832B2C9 _Z22sqlnq_create_index_endP9sqlnq_qtbiii *
* + 0x0eb5 *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* 0x00002AE21832D5A1 *
* _Z23sqlnq_create_index_stmtPP8stknode_i10actiontypePhP3loc + *
* 0x03fb *
* (/home/ztoth/sqllib/lib64/libdb2e.so.1) *
* *
* The problem is caused by insufficient clean up of DB2 meta *
* when dropping the last index in an range clustered table *
* whose indexes reside in a different tablespace than the *
* table. At this point the table still things it's indexes *
* own a given object ID, but another table can reuse this ID *
* when creating an index object. Then when new indexes on the *
* range clustered table are created, an attempt is made to *
* reuse the object ID, but we get an error because the object *
* ID is already in use. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 9.7.3. *
**************************************************************** |
| Local Fix: |
Export the data from the range clustered table, drop the table,
and recreate the table and import the data that was previously
exported. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
The problem was fixed in DB2 9.7.3. |
| Workaround |
Export the data from the range clustered table, drop the table,
and recreate the table and import the data that was previously
exported. |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 27.08.2010
08.11.2012
08.11.2012 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.3
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.3
|
 |
| 9.7.0.3
|
|
