|
Problem IC61996
|
Status: Closed |
DB2 MIGHT CRASH IF THE "IN <TABLESPACE>" CLAUSE IS SPECIFIED FOR A "CREATE INDEX" STATEMENT ON A GLOBAL DECLARED TEMPORARY TABLE |
| product: |
DB2 FOR LUW / DB2FORLUW / 910 - DB2 |
| Problem description: |
When working on the non-catalog node, DB2 will crash with signal
11 if the "IN <tablespace>" clause was specified for a "CREATE
INDEX" statement on a global declared temporary table. The
statement should have returned the error SQL0109N instead, since
"CREATE INDEX IN <tablespace>" is only valid for a partitioned
table.
The db2diag.log shows the crash as follows:
2009-07-03-14.24.35.408292+540 E3536874A884 LEVEL: Severe
PID : 1261956 TID : 1 PROC :
db2tcpcm 0
INSTANCE: db2inst1 NODE : 000
FUNCTION: DB2 UDB, oper system services, sqloEDUSIGCHLDHandler,
probe:50
DATA #1 : <preformatted>
Detected the death of an EDU with process id 2351464.
The signal number that terminated this process was 11.
Look for trap files (t2351464.*) in the dump directory.
CALLSTCK:
[0] 0x0900000004851BDC
@49@sqloEDUSIGCHLDHandler__FiP9siginfo_tPv + 0x15C
[1] 0x0000000000000000 ?unknown + 0x0
[2] 0x0000000000000000 ?unknown + 0x0
[3] 0x0000000000000000 ?unknown + 0x0
[4] 0x0000000000000000 ?unknown + 0x0
[5] 0x0000000000000000 ?unknown + 0x0
[6] 0x0000000000000000 ?unknown + 0x0
[7] 0x0000000000000000 ?unknown + 0x0
[8] 0x0000000000000000 ?unknown + 0x0
[9] 0x0000000000000000 ?unknown + 0x0
And the trap file indicates it crashed in the function
sqlrl_copy_fetch_flds.
-------Frame------ ------Function + Offset------
0x000000000000F414 ?unknown + 0x0
0x0900000005EB3194
sqlrl_copy_fetch_flds__FP8sqlrr_cbiN22P11sqlrl_valueT5P13sqlr_rp
creply + 0x4F8
0x0900000005EB2BB8
sqlrl_copy_fetch_flds__FP8sqlrr_cbiN22P11sqlrl_valueT5P13sqlr_rp
creply@glue38B + 0x7C
0x09000000048B8078
sqlrl_fetch_one_row__FP8sqlrr_cbiP10sqlrl_fldsT2T3N22P8SQLZ_RID
+ 0x39C
0x09000000055ACB50 sqlrlCheckExists__FP8sqlrr_cbUcPUciT3T4Pb +
0x380
0x0900000005608200
sqlnq_index_in_clause__FPP8stknode_i10actiontypePUcP3loc + 0x298
0x09000000046D6A40 sqlnp_smactn__FP8sqlnp_cbi - 0x4
0x09000000046E851C sqlnp_parser__FP8sqlnp_cb + 0x128
0x090000000480FE70 sqlnp_main__FP12sqlnq_stringsPP9sqlnq_qur +
0x170
0x0900000004890D38
sqlnn_cmpl__FP20sqle_agent_privatecbP11sqlrrstrings17sqlnn_compi
leModeT3P14sqlrr_cmpl_enviT7PP9sqlnq_qur + 0x818
0x0900000004890430
sqlnn_cmpl__FP20sqle_agent_privatecbP11sqlrrstrings17sqlnn_compi
leModeT3P14sqlrr_cmpl_env + 0x24
0x0900000004CA62D0
sqlra_compile_var__FP8sqlrr_cbP14sqlra_cmpl_envPUciUsN54P16sqlra
_cached_varPiPUl + 0x608
0x0900000004CAA8EC
sqlra_find_var__FP8sqlrr_cbP17sqlra_cached_stmt13sqlra_stmt_idUi
T4PUcT4UsUcP14sqlra_cmpl_enviPiT11_T12_N311_T12_P14SQLP_LOCK_INF
OPP16sqlra_cached_varT12_PUlb + 0x3B0
0x0900000004CA55B4 sqlra_get_var__FP8sqlrr_cbiPiT2bT3 + 0x444
0x0900000004402BD4 sqlri_ddl_get_section__FP8sqlrr_cb + 0x58
0x0900000004402460 sqlri_ddl_common__FP8sqlrr_cb + 0x84C
0x0900000004403614 sqlriddl__FP8sqlrr_cb + 0x28
0x0900000005D345F4 sqlri_dss__FP8sqlrr_cb + 0x474
0x0900000004A98F78 sqlriSectInvoke__FP8sqlrr_cbP12sqlri_opparm +
0x14
0x0900000004ABE2F0 sqlrr_process_execute_request__FP8sqlrr_cbi +
0x80
0x0900000004A9258C sqlrr_execute__FP14db2UCinterfaceP9UCstpInfo
- 0x104
0x0900000004A896E8
sqljs_ddm_excsqlstt__FP14db2UCinterfaceP14sqljsDDMObject + 0x474
Please note that the problem occurs only in V9.1. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All DB2 Version 9.1 GA through Fix Pack 8 serverson Linux, *
* Unix and Windows using data partitionfeature (DPF) *
* environment only. Users who issue a"CREATE INDEX" statement *
* on a global declaredtemporary with "IN <tablespace>" clause *
* from anon-catalog node. *
****************************************************************
* PROBLEM DESCRIPTION: *
* When working on the non-catalog node, DB2 crashed withsignal *
* 11 if the "IN <tablespace>" clause was specified fora"CREATE *
* INDEX" statement on a global declared temporarytable. The *
* statement should have returned the error SQL0109Ninstead, *
* since "CREATE INDEX IN <tablespace>" is only validfor a *
* partitioned table. *
****************************************************************
* RECOMMENDATION: *
* 1) Don't specify the "IN <tablespace>" clause whencreatingan *
* index for a global temporary table2) Connect tothe DB from *
* the catalog node when using"CREATE INDEX IN<tablespace>" for *
* a global temporary table *
**************************************************************** |
| Local Fix: |
1) Don't specify the "IN <tablespace>" clause when creating an
index for a global temporary table
2) Connect to the DB from the catalog node when using "CREATE
INDEX IN <tablespace>" for a global temporary table |
| available fix packs: |
DB2 Version 9.1 Fix Pack 9 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 10 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 11 for Linux, UNIX and Windows
DB2 Version 9.1 Fix Pack 12 for Linux, UNIX and Windows
|
| Solution |
Problem was first fixed in Version 9.1 Fix Pack 9 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 13.07.2009
26.04.2010
26.04.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.1.FP9
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.1.0.9
|
 |
