DB2 - Problem description
| Problem IC97928 | Status: Closed |
ALTER TABLE DROP COLUMN ON A TABLE WITH AN INDEX WITH RANDOM ORDERING MIGHT LEAD TO INDEX CORRUPTION | |
| product: | |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 | |
| Problem description: | |
This APAR applies only to indexes which have been created with
the new RANDOM keyword for the index keypart order. The RANDOM
keyword was introduced in the V10.5.1 product.
If an ALTER TABLE statement with the DROP COLUMN option is run
on the table with the index with random ordering, then the
packed descriptor for the index in the system catalog might
become corrupted.
The index packed descriptor corruption could surface in various
ways, or go unnoticed for some time. The packed descriptor
corruption might lead to index corruption, which could then lead
to a trap or incorrect results. It might be difficult to detect
if incorrectly returned results.
Because of the various errors that might occur because of this
index corruption, it is recommended that any user using an index
with random ordering move up to a level with the fix and run the
db2cat command to see if they are affected by the index
corruption issue (see the local fix section of the APAR for more
details).
One example of an error that could surface as a result of the
corruption is the following probe point which might be seen in
the db2diag.log file if a trap occurs:
2013-11-17-05.13.04.134876-300 I744884390A549 LEVEL:
Severe
PID : 21889084 TID : 79920 PROC :
db2sysc 1
INSTANCE: db2usr1 NODE : 001 DB :
SAMPLEDB
APPHDL : 1-58998 APPID:
9.26.97.181.41845.131117184210
AUTHID : DB2USR1 HOSTNAME: host1.torolab.ibm.com
EDUID : 79920 EDUNAME: db2agent (SAMPLEDB) 1
FUNCTION: DB2 UDB, index manager, procLeaf2Del, probe:2
DATA #1 : Hexdump, 4 bytes
0x070000005F3F65C4 : 8709 002C
A stack traceback such as the following could be produced in
this case:
0x09000000005A5B50 pthread_kill + 0xB0
0x09000000099F7150 sqloDumpEDU + 0xD0
0x090000000AC5B5A4
@159@sqlischdDumpData__FP7SQLI_CBP11SQLI_SDGLOBi + 0x2DC
0x0900000009222DC4 sqlischd__FP7SQLI_CBP11SQLI_SDGLOBUsUi +
0x8F4
0x09000000091DE754 sqlischd__FP7SQLI_CBP11SQLI_SDGLOBUsUi +
0x730
0x09000000091DDA34
sqlidelk__FP8sqeAgentP9SQLD_IXCBP10SQLI_IXPCRP8SQLD_KEY8SQLZ_RID
UlP16SQLB_OBJECT_DESC + 0x404
0x09000000091DC614
sqldKeyDelete__FP13SQLD_DFM_WORKP8SQLD_TCBP13SQLD_TDATARECP15SQL
D_TDATAREC328SQLZ_RIDiUl + 0x7C0
0x09000000091D8E00 sqldRowDelete__FP8sqeAgentP8SQLD_CCBUlPPv +
0x11A8
0x09000000091D992C sqlridel__FP8sqlrr_cb + 0x15C
0x090000000910FEAC sqlriSectInvoke__FP8sqlrr_cbP12sqlri_opparm +
0x74
0x09000000093880B8
sqlrr_execimmd__FP14db2UCinterfaceP16db2UCprepareInfo + 0x11E8
0x0900000009386FB8
sqlrr_execimmd__FP14db2UCinterfaceP16db2UCprepareInfo + 0xE8
0x09000000086CAB78
sqljsParseRdbAccessed__FP13sqljsDrdaAsCbP13sqljDDMObjectP14db2UC
interface + 0xC124
0x0900000008718A84 @72@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb
+ 0x9A3C
0x0900000008718A84 @72@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb
+ 0x9A3C
0x09000000086ED2DC @72@sqljsSqlam__FP14db2UCinterfaceP8sqeAgentb
+ 0x1DB4
0x09000000081654F8
@72@sqljsDriveRequests__FP8sqeAgentP14db2UCconHandle + 0xA8
0x0900000008165FE4
@72@sqljsDrdaAsInnerDriver__FP18SQLCC_INITSTRUCT_Tb + 0x5E0
0x0900000009BF475C RunEDU__8sqeAgentFv + 0x3EA28
0x0900000009C44C04 RunEDU__8sqeAgentFv + 0xDC
0x0900000008C9A7BC EDUDriver__9sqzEDUObjFv + 0x124
0x090000000993CB10 sqloEDUEntry + 0x38C
If a table does have indexes with RANDOM ordered columns
defined, then the db2cat command should be run against the table
error to identify whether this is indeed the error. Prior to
applying the fix for this APAR, the db2cat command will not
automatically report the corruption. However, manual inspection
can be done as follows to verify if this APAR is the cause of
your index corruption.
For indexes with RANDOM order the db2cat output will contain two
lists of the keyparts of the index. The second list of keyparts
will have one or more additional keyparts with Keypart ID =
65534. The corresponding columns in each of the keypart lists
should be examined to ensure that their Keypart ID's are the
same in each list. If they are not then this APAR fix should be
applied. In order to compare keyparts between the lists, start
with the keyparts in the first list and compare them one at a
time to the keyparts in the second list. If you encounter a
Keypart ID of 65534 in the second list, just skip past it and
compare to the next keypart. For example, as seen in the output
below, the Keypart ID of keypart 1 from the first list should be
compared to Keypart ID of keypart 2 from the second list because
we need to skip over keypart 1 in the second list. Next, the
Keypart ID of keypart 2 from the first list should be compared
to the Keypart ID of keypart 3 from the second list. In the
sample output below, the Keypart ID for Keypart 2 is 10 in the
first set of keyparts but the Keypart ID value is 9 for the
corresponding Keypart 3 in the Extend set of keyparts. The
Keypart ID's are evidence of index corruption. Also, the Keypart
ID's for Keypart 4 in the first set of keyparts and Keypart 5 in
the second set are also different. Both are evidence of the
corruption which can occur from the problem described in this
APAR.
For example. assume that the the following table and index
definitions have been corrupted:
db2 "create table t1 (c1 float, c2 char(176), c3 decimal
(5,0), c4 smallint)"
db2 "create index i1 on t1 (c1 random, c2, c3 desc, c4)"
Running the following db2cat command such
as:
db2cat -d sampledb -s db2usr1 -n t1 -o <output file>
will result in output like the following written to the output
file. In this sample output, the Keypart ID for Keypart 2 is 10
in the first set of keyparts but the Keypart ID value is 9 for
the corresponding Keypart 3 in the Extend Index Info set of
keyparts. The Keypart ID's for Keypart 4 in the first set of
keyparts and Keypart 5 in the second set are also different.
This is evidence of the corruption.
No. of keys : 4
No. of Unique keys : 4
Keypart 1
Keypart ID : 5
Keypart flags : x10
Codepage : 0
Description of keypart
Type , Length : FLOAT/DOUBLE , 8
Nullable : 1
Keypart 2
Keypart ID : 10
Keypart flags : x0
Codepage : 1208
Description of keypart
Type , Length : CHAR , 176
Nullable : 2
Keypart 3
Keypart ID : 15
Keypart flags : x1
Codepage : 0
Description of keypart
Type , Length : DECIMAL , 5.0
Nullable : 1
Keypart 4
Keypart ID : 9
Keypart flags : x0
Codepage : 0
Description of keypart
Type , Length : SMALL INTEGER , 2
Nullable : 1
...
Extend Index Info
...
No. of keys : 5
No. of Unique keys : 5
Keypart 1
Keypart ID : 65534
Keypart flags : x0
Codepage : 0
Description of keypart
Type , Length : SMALL INTEGER , 2
Nullable : 2
Keypart 2
Keypart ID : 5
Keypart flags : x0
Codepage : 0
Description of keypart
Type , Length : FLOAT/DOUBLE , 8
Nullable : 1
Keypart 3
Keypart ID : 9
Keypart flags : x0
Codepage : 1208
Description of keypart
Type , Length : CHAR , 176
Nullable : 2
Keypart 4
Keypart ID : 15
Keypart flags : x1
Codepage : 0
Description of keypart
Type , Length : DECIMAL , 5.0
Nullable : 1
Keypart 5
Keypart ID : 10
Keypart flags : x0
Codepage : 0
Description of keypart
Type , Length : SMALL INTEGER , 2
Nullable : 1 | |
| Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * All users * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 version 10.5.0.3. * **************************************************************** | |
| Local Fix: | |
If you have hit the problem described in this APAR then the index must be dropped and a new index must be created. This will resolve the immediate corruption problem. However the index will still be open to further corruption until this APAR fix is applied. To avoid further corruption do not issue the ALTER TABLE DROP COLUMN statement against any table which has indexes defined with columns in RANDOM order. Note that marking the index object bad and recreating the indexes will not resolve the corruption. Keep in mind that you might be affected but have not yet seen an error so it is recommended that all users with indexes defined with RANDOM order apply the APAR fix.. Once this APAR fix is applied the db2cat command with the -v option should be run against all tables with indexes defined with RANDOM order to detect whether any corruption exists in your database. The output file will contain details of any errors found. The -v option will only detect the errors once the APAR fix has been applied: db2cat -d <dbname> -v -s <schema> -n <table> -o <outputfile> | |
| available fix packs: | |
DB2 Version 10.5 Fix Pack 3 for Linux, UNIX, and Windows | |
| Solution | |
The problem is first fixed in DB2 version 10.5.0.3. | |
| Workaround | |
not known / see Local fix | |
| Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 25.11.2013 27.02.2014 07.04.2015 |
| Problem solved at the following versions (IBM BugInfos) | |
| Problem solved according to the fixlist(s) of the following version(s) | |
| 10.5.0.3 |
|
| 10.5.0.3 |
|