DB2 FOR LUW / DB2FORLUW / 950 - DB2

For queries which involve certain operators (eg. merge-join) 
which require base table rows to be temped or sorted, we are 
incorrectly estimating the column length for XML columns. Not 
only are we over-estimating the column length of inlined XML 
columns (should always use 256, but we are using the inline 
length) for sort/temp tables, but we are under-estimating it for 
outlined XML columns (should again be using 256, but are using 
80 instead). So while inserting records into the system temp 
table, we could have a scenario where according to our (WRONG) 
estimation the next record will fit in the current page but it 
actually cannot fit. In such a scenario we hit a severe error 
when we try to insert the record. 
 
Symptom: 
Engine is brought down and DB gets marked bad 
 
Sample error in db2diag.log - 
 
2009-05-07-10.54.41.773797-420 I21359E1511    LEVEL: 
SeverePID     : 8027    TID : 47586157259072 PROC : db2sysc 1 
 
INSTANCE: rkubis     NODE : 001  DB   : CT08PCOL 
APPHDL : 0-51  APPID: *N0.rkubis.090507175432 
AUTHID : RKUBIS      EDUID : 61    EDUNAME: db2agntp (CT08PCOL) 
1 
FUNCTION: DB2 UDB, data management, setupDATInfo, probe:3182 
RETCODE : ZRC=0x87040055=-2029780907=SQLD_PRGERR "Unknown 
PROGRAM ERROR" 
 DIA8576C A data management services programming error occurred. 
 
MESSAGE : Descriptor row length exceeds maximum allowed. 
DATA #1 : unsigned integer, 4 bytes 
42066 
DATA #2 : unsigned integer, 4 bytes 
32677 
CALLSTCK: 
[0] 0x00002B476CBDC8D9 pdLogRC + 0x167 
[1] 0x00002B476CCA2E1E /home/rkubis/sqllib/lib64/libdb2e.so.1 
+0xD73E1E 
[2] 
0x00002B476CCAAA72_Z21sqldCompleteTCBforDATP8sqeAgentP8SQLD_TCBP 
16SQLB_OBJECT_DESC 
S4_iiP12SQLD_TDIRRECP13SQLD_TDESCRECim + 0x2EE 
[3] 0x00002B476CC84658 
/home/rkubis/sqllib/lib64/libdb2e.so.1+0xD55658 
[4] 
0x00002B476CC83594_Z23sqldInternalCreateTableP8sqeAgentP19SQLD_T 
ABLECREATE_CB 
+ 
0x334 
[5] 
0x00002B476CC830D1_Z19sqldTableCreateTempP8sqeAgentPtS1_hmmiP10S 
QLD_FIELDP12SQLD_C 
OLINFOi  +0x1D9 
[6] 
0x00002B476E8A9997_Z24sqlri_mgjnAppendToBufferP8sqlrr_cbP10sqlri 
_mgjn 
+ 0xAFD 
[7] 0x00002B476F1D506C _Z8sqlri_mjP8sqlrr_cb + 0x10FE 
[8] 
0x00002B476D1194F9_Z15sqlriSectInvokeP8sqlrr_cbP12sqlri_opparm + 
0xE5 
[9] 0x00002B476E6AFEC8 _Z16sqlrr_dss_routerP8sqlrr_cb + 0x6D4

**************************************************************** 
* USERS AFFECTED:                                              * 
* All                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* For queries which involve certain operators (eg. merge-join) * 
*                                                              * 
* which require base table rows to be temped or sorted, we are * 
*                                                              * 
* incorrectly estimating the column length for XML columns.    * 
* Not                                                          * 
* only are we over-estimating the column length of inlined XML * 
*                                                              * 
* columns (should always use 256, but we are using the inline  * 
*                                                              * 
* length) for sort/temp tables, but we are under-estimating it * 
* for                                                          * 
* outlined XML columns (should again be using 256, but are     * 
* using                                                        * 
* 80 instead). So while inserting records into the system temp * 
*                                                              * 
* table, we could have a scenario where according to our       * 
* (WRONG)                                                      * 
* estimation the next record will fit in the current page but  * 
* it                                                           * 
* actually cannot fit. In such a scenario we hit a severe      * 
* error                                                        * 
* when we try to insert the record.                            * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Apply FP5                                                    * 
****************************************************************

Since the problem is caused by inserting a record into a system 
temp page which does not have enough space to hold it, we MIGHT 
be able to avoid the problem by creating a system temp 
tablespace with a larger page size than what is currently 
available. If however there is already a system temp tablespace 
with 32K page size (largest page size possible), then this 
workaround will definitely not work. 
Also, if possible, try to rewrite the failing query to avoid 
using the operators which result in records being put into 
temp/sort table.

DB2 Version 9.5 Fix Pack 5 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
 DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
 

not known / see Local fix

Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :

30.06.2009
15.02.2010
15.02.2010