|
Problem IC71664
|
Status: Closed |
SQL0901N ENCOUNTERED BY APD CLEANUP PROCESSING DURING RANGE PARTITION DETACH |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
During range partition detachment, the DETACH is stuck in
'Waiting' in LIST UTILITIES output, while the Asynchronous
Detach Process (APD) processes hit -901 with "A hard
invalidation is already taking place for this object". In the
db2diag.log, the -901 reported for the asynchronous detach
process may appear similar to the entry below.
2010-09-08-21.19.33.006553-240 I3532E878 LEVEL: Severe
PID : 15610 TID : 47141393262912PROC :
db2sysc 1
INSTANCE: db2inst1 NODE : 001 DB : SAMPLE
APPHDL : 1-38495 APPID: *N1.DB2.100909011946
AUTHID : DB2INST1
EDUID : 221680 EDUNAME: db2taskp (SAMPLE) 1
FUNCTION: DB2 UDB, relation data serv, sqlrr_dump_ffdc,
probe:300
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -901 sqlerrml: 60
sqlerrmc: A hard invalidation is already taking place for this
object!
sqlerrp : SQLRA0B5
sqlerrd : (1) 0x00000000 (2) 0x00000000 (3)
0x00000000
(4) 0x00000000 (5) 0xFFFFFFEC (6)
0x00000001
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:
These entries would appear for other db2taskp EDUs. Stack dumps
are generated for these EDUs, and the stack would have
sqlra_inval_obj_hard before the -901 is returned, e.g.
<StackTrace>
-----FUNC-ADDR---- ------FUNCTION + OFFSET------
0x00002ADF2F8CCF5D ossDumpStackTraceEx + 0x01e5
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2osse.so.1)
0x00002ADF2F8C7CE2 _ZN11OSSTrapFile6dumpExEmiP7siginfoPvm +
0x00cc
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2osse.so.1)
0x00002ADF2CC10493 sqlo_trce + 0x0365
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CC53C99 sqloDumpDiagInfoHandler + 0x00ed
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2A1E54C0 address: 0x00002ADF2A1E54C0 ; dladdress:
0x00002ADF2A1D7000 ; offset in lib: 0x000000000000E4C0 ;
(/lib64/libpthread.so.0)
0x00002ADF2A1E26B2 pthread_kill + 0x0032
(/lib64/libpthread.so.0)
0x00002ADF2CC53581 sqloDumpEDU + 0x0045
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2BF34874 _Z15sqldDumpContextP9sqeBsuEduiiiiiPKcPvi +
0x069e
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2B821D73 _Z15sqlrr_dump_ffdcP8sqlrr_cbii + 0x04bb
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2BA19B2A _Z13sqlzeDumpFFDCP8sqeAgentjP5sqlcai + 0x0020
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2BA18EB7
_Z12sqlzeSqlCodeP8sqeAgentjmjP5sqlcaitP13__va_list_tag + 0x00f7
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CE7BD74 sqlrrSqlCode + 0x00e2
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CEE696C
_Z20sqlra_inval_obj_hardP8sqlrr_cbP23sqlra_anchor_dependencyP23s
qlra_cached_dependencyjiPtj
+ 0x0102
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CEE763E
_Z21sqlra_inval_vars_hardP8sqlrr_cbhPhjS1_sjiPtj + 0x027c
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CEE7BF4
_Z22sqlra_event_inval_hardP8sqlrr_cbP20sqlr_rpc_apm_request +
0x009c
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CED292C
_Z19sqlra_execute_eventP8sqlrr_cbP20sqlr_rpc_apm_request +
0x0332
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CED2B80
_Z27sqlra_broadcast_request_catP8sqlrr_cbP20sqlr_rpc_apm_request
+ 0x0124
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CED38A3
_Z23sqlra_broadcast_requestP8sqlrr_cbP20sqlr_rpc_apm_request +
0x0309
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2CEEAD2C
_Z20sqlra_invalidate_pkgP8sqlrr_cbPhsP11sqlrrstringhS1_scm14sqln
q_depUsageP13sqlra_columnsjib
+ 0x0622
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2D1E5B9A
_Z21sqlrlAlterPartCatalogP8sqlrr_cbPhsS1_thS1_sS1_tiP19sqlrl_tbs
pace_parmsPP8sqlrg_pdP18sqlrg_datapartinfoR23sqlrg_datapartinfo_
itert25sqlrlDPartStageTransitionS5_P21SQLD_ATTACH_INDEX_MAPP17sq
lrlStatsCarrierjP21SqlthJo
bProgressPhase + 0x14b8
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2D1ED33D
_Z19sqlrlPhysicalDetachP8sqlrr_cbPP8sqlrg_pdS2_P5doid1P18sqlrg_d
atapartinfoR23sqlrg_datapartinfo_iterP6APD_CBP21SqlthJobProgress
Phase
+ 0x01d1
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2BAB7BC7 apdTaskProcessor + 0x03bb
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2B24B908
_ZN8ABPAgent19taskProcessorDriverEP17ABPTaskProContext + 0x016a
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2B24B49A _ZN8ABPAgent4mainEP17ABPTaskProContext +
0x0126
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2B2511DC
_Z18abpAgentEntryPointP8sqeAgentP17ABPTaskProContext + 0x0054
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2B38DD43 _Z26sqleIndCoordProcessRequestP8sqeAgent +
0x0463
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2B39AEC1 _ZN8sqeAgent6RunEDUEv + 0x0381
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2BA19ED8 _ZN9sqzEDUObj9EDUDriverEv + 0x00a6
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2BA19E2F _Z10sqlzRunEDUPcj + 0x0009
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2B7ABB0E sqloEDUEntry + 0x02f0
(/var/ibmdb2/nyqxt270/sqllib/lib64/libdb2e.so.1)
0x00002ADF2A1DD367 address: 0x00002ADF2A1DD367 ; dladdress:
0x00002ADF2A1D7000 ; offset in lib: 0x0000000000006367 ;
(/lib64/libpthread.so.0)
0x00002ADF305AC0AD clone + 0x006d
(/lib64/libc.so.6)
</StackTrace>
This -901 can occur if there is a concurrent DDL running on the
table from which the detach is detaching a partition. The same
symptom can occur if the ADMIN_MOVE_TABLE() procedure is called
while DDL is being performed against the same table. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* ALL *
****************************************************************
* PROBLEM DESCRIPTION: *
* During range partition detachment, the DETACH is stuck in *
* 'Waiting' in LIST UTILITIES output, while the Asynchronous *
* Detach Process (APD) processes hit -901 with "A hard *
* invalidation is already taking place for this object". This *
* -901 can occur if there is a concurrent DDL running on the *
* table from which the detach is detaching a partition. The *
* same symptom can occur if the ADMIN_MOVE_TABLE() procedure *
* is called while DDL is being performed against the same *
* table. *
****************************************************************
* RECOMMENDATION: *
* Update to Version 9.7 Fix Pack 4 *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
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 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Problem was first fixed in Version 9.7 Fix Pack 4 |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC73646
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 04.10.2010
09.05.2011
09.05.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP4
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.4
|
 |
