home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

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
DB2 Version 10.5 Fix Pack 3a for Linux, UNIX, and Windows
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows
DB2 Version 10.5 Fix Pack 9 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 FixList
10.5.0.3 FixList