|
Problem IC65603
|
Status: Closed |
WHEN ROW LENGTH EXCEEDS TEMPORARY TABLESPACE PAGE SIZE, RETURN -901 ERROR INSTEAD OF MARKING DATABASE BAD |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
As a consequence of the underlying issue in APAR IC61811, the
database is marked bad when a query requires a row length that
exceeds the temporary tablespace page size. The database then
goes down and crash recovery is required.
For example, when a query involving XML columns is calculated to
have 12k row length, but the temporary tablespace page size is
only 8k, the following error is seen:
2009-07-16-15.23.27.170841-240 I958361A1665 LEVEL: Severe
PID : 1331306 TID : 12730 PROC : db2sysc
0
INSTANCE: dbinst1 NODE : 000 DB : SAMPLEDB
APPHDL : 0-17122 APPID: ...
AUTHID : SAMPLEID
EDUID : 12730 EDUNAME: db2agent (SAMPLEDB) 0
FUNCTION: DB2 UDB, data management, setupDATInfo, probe:2860
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
12496
DATA #2 : unsigned integer, 4 bytes
8101
CALLSTCK:
[0] 0x09000000062D6398 pdLogRC@glue15 + 0x118
[1] 0x0900000006EB1990
@101@setupDATInfo__FP8sqeAgentP8SQLD_TCBP12SQLD_TDIRRECP13SQLD_T
DESCREC + 0x140
[2] 0x09000000059E6368
sqldCompleteTCBforDAT__FP8sqeAgentP8SQLD_TCBP16SQLB_OBJECT_DESCT
3iT5P12SQLD_TDIRRECP13SQLD_TDESCRECT5Ul + 0x28C
[3] 0x09000000059E5B8C
@101@sqldCreateDAT__FP8sqeAgentPUsN32UiT6UlT8iN310_P10SQLD_FIELD
P12SQLD_COLINFOP15SQLD_RCTCOLINFOT10_PiPP8SQLD_TCBPcUsN221_T6 +
0x5C4
[4] 0x09000000059E4798
sqldInternalCreateTable__FP8sqeAgentP19SQLD_TABLECREATE_CB +
0x290
[5] 0x09000000059E43FC
sqldTableCreateTemp__FP8sqeAgentPUsT2UcUlT5iP10SQLD_FIELDP12SQLD
_COLINFOT7 + 0xF4
[6] 0x0900000007538B90
sqlri_mgjnAppendToBuffer__FP8sqlrr_cbP10sqlri_mgjn + 0x65C
[7] 0x09000000057599DC sqlri_mj__FP8sqlrr_cb + 0x204
[8] 0x09000000058FBA40
sqlriSectInvoke__FP8sqlrr_cbP12sqlri_opparm + 0xFFFFFFFFFFFFF878
[9] 0x09000000059C12E8
sqlrr_process_fetch_request__FP14db2UCinterface + 0x13C
The fix will ensure that instead of marking the database bad due
to the severe error, the statement will fail with a -901 error,
and the database will remain up. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* Potentially all users. *
****************************************************************
* PROBLEM DESCRIPTION: *
* An error in a temporary tablespace could cause the *
* instanceto abend unneccessarily. This APAR instead return *
* an errorto the user and the instance will remain available. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to the latest fixpack. *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
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 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Problem is first fixed in DB2 UDB version 9.7 fix pack 2. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 19.01.2010
25.05.2010
25.05.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP2
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.2
|
 |
