DB2 - Problem description
Problem IC97686 | Status: Closed |
ASYNCHRONOUS PARTITION DETACH JOB MAY BE SUSPENDED BY ABP DUE TO INVALID AUTHID | |
product: | |
DB2 FOR LUW / DB2FORLUW / A50 - DB2 | |
Problem description: | |
The following probe points will be written to the diag.log if the error occurs. EDUID : 106 EDUNAME: db2taskp (WSDB) FUNCTION: DB2 UDB, catalog services, sqlrlCatalogScan::buildValues, probe:40 DATA #1 : String, 5 bytes OWNER EDUID : 106 EDUNAME: db2taskp (WSDB) FUNCTION: DB2 UDB, catalog services, sqlrlCatalogScan::buildValues, probe:40 DATA #1 : String, 20 bytes Scan interface error DATA #2 : String, 0 bytes Object not dumped: Address: 0x00002AAAB3EF428C Size: 0 Reason: Zero-length data DATA #3 : String, 7 bytes SYSJOBS DATA #4 : String, 11 bytes INDTABLES01 DATA #5 : Catalog Scan, PD_TYPE_SQLRL_CATALOG_SCAN, 720 bytes # Key Fields requested: 0 # Key Fields set up: 0 # Fetch Fields requested: 13 # Fetch Fields set up: 13 # LOB Fields: 1 # XML Fields: 0 Scan type: Insert Lock intent: SQLD_SLI_IS_NS (7) Lock isolation: SQLZ_CSTAB Scan flags 1: 0x0000000000000002 SQLD_SCAN1_INDEX_ONLY Scan flags 2: 0x00000000 CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol) [0] 0x00002AAAB2C2CBE9 _ZN16sqlrlCatalogScan13checkForErrorEv + 0x139 [1] 0x00002AAAAFD0ACE6 _ZN16sqlrlCatalogScan11buildValuesEv + 0x366 [2] 0x00002AAAAFD07954 _ZN16sqlrlCatalogScan6insertEv + 0x84 [3] 0x00002AAAB00D2663 _ZN16ABPRecordManager15createJobRecordER8sqlrr_cbsRK12A BP_JOB_DESCRl + 0x363 [4] 0x00002AAAB00D7EAB _ZN11ABPServices9createJobER8sqlrr_cbsRK12ABP_JOB_DESCP K13ABP_TASK_DESCj + 0x8B [5] 0x00002AAAB00D0FDB _Z12abpCreateJobPK8sqeAgentPK12ABP_JOB_DESCPK13ABP_TASK _DESCj + 0xAB [6] 0x00002AAAB238D1B9 _Z26sqlrlCreateIndexCleanupJobP8sqlrr_cbsP8sqlrg_pdttt + 0xC39 [7] 0x00002AAAB238606B _Z27sqlrlAlterDropCatalogChangeP8sqlrr_cbPhtS1_thP18sql rg_datapartinfoP8sqlrg_pdR23sqlrg_datapartinfo_itert25sqlrlDPart StageTra + 0x72B [8] 0x00002AAAB2386B13 _Z29sqlrlAlterDetachCatalogChangeP8sqlrr_cbPhtS1_thP18s qlrg_datapartinfoP8sqlrg_pdS1_iS1_iS5_R23sqlrg_datapartinfo_iter t25sqlrl + 0x183 [9] 0x00002AAAB237FB41 _Z21sqlrlAlterPartCatalogP8sqlrr_cbPhsS1_thS1_sS1_tiPP8 sqlrg_pdP18sqlrg_datapartinfoR23sqlrg_datapartinfo_itert25sqlrlD PartStag + 0x7E1 [10] 0x00002AAAB2390856 _Z19sqlrlPhysicalDetachP8sqlrr_cbPP8sqlrg_pdS2_P5doid1 P18sqlrg_datapartinfoR23sqlrg_datapartinfo_iterP6APD_CBP21SqlthJ obProgres + 0x1D 6 [11] 0x00002AAAB00E557A apdTaskProcessor + 0x35A [12] 0x00002AAAABC95C43 _ZN8ABPAgent19taskProcessorDriverEP17ABPTaskProContext + 0x173 [13] 0x00002AAAABC9556E _ZN8ABPAgent4mainEP17ABPTaskProContext + 0x26E [14] 0x00002AAAABCA1DEC _Z18abpAgentEntryPointP8sqeAgentP17ABPTaskProContext + 0x4C [15] 0x00002AAAAEA37C0F _Z26sqleIndCoordProcessRequestP8sqeAgent + 0x131F [16] 0x00002AAAAEA46485 _ZN8sqeAgent6RunEDUEv + 0x2E5 [17] 0x00002AAAB0006DC7 _ZN9sqzEDUObj9EDUDriverEv + 0xF7 [18] 0x00002AAAAF85E871 sqloEDUEntry + 0x301 [19] 0x00002AAAAABCE2A3 /lib64/libpthread.so.0 + 0x62A3 [20] 0x00002AAAB7F4A6DD __clone + 0x6D ..... EDUID : 106 EDUNAME: db2taskp (WSDB) FUNCTION: DB2 UDB, AIC, apdTaskProcessorCleanup, probe:201 MESSAGE : ZRC=0x801A006D=-2145779603=SQLZ_CA_BUILT "SQLCA has already been built" CALLED : DB2 UDB, AIC, apdTaskProcessor RETCODE : ZRC=0x82A90066=-2102853530=ABP_SUSPEND_TASK_PRO "Suspend the task processor" DATA #1 : String, 28 bytes Source Table Schema and Name DATA #2 : String, 8 bytes DBUSER1 DATA #3 : String, 3 bytes T1 DATA #4 : String, 12 bytes Partition ID DATA #5 : unsigned integer, 2 bytes 3 DATA #6 : String, 28 bytes Target Table Schema and Name DATA #7 : String, 8 bytes DBUSER1 DATA #8 : String, 7 bytes T1DETACH An FODC_AppErr_* directory will also be created with diagnostic information. The error occurs randomly. If these probe points are in the diag.log, the LIST UTILITIES SHOW DETAIL can be run to see whether the job is still suspended. If so, the following will be seen: $ db2 list utilities show detail ID = 1 Type = ASYNCHRONOUS PARTITION DETACH Database Name = WSDB Member Number = 0 Description = Finalize the detach for partition '3' of table 'DBUSER1 .T1' Start Time = 10/30/2013 11:04:40.302529 State = Waiting Invocation Type = Automatic Progress Monitoring: Start Time = 10/30/2013 11:05:06.132426 If there is no ASYNCHRONOUS PARTITION DETACH waiting then the problem has resolved itself. If it continues to wait, then each time the Asynchronous Background Processor (ABP) wakes up and attempts to process the detach a new FODC directory will be created. | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * All users * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to db2 v10.5.3. * **************************************************************** | |
Local Fix: | |
If the DETACH job continues to wait and FODC directories continue to be created, then database will have to be deactivated and reactivated to restart the ABP processor to see if that will resolve the problem. If it doesn't resolve the issue then the APAR fix will have to be applied. There will be no corruption to the table but the detach operation will not be able to clean up the indexes and complete until the problem is resolved. | |
available fix packs: | |
DB2 Cancun Release 10.5.0.4 (also known as Fix Pack 4) for Linux, UNIX, and Windows | |
Solution | |
First fixed in db2 v10.5.3. | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 14.11.2013 08.09.2014 08.09.2014 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) | |
10.5.0.4 |