DB2 - Problem description
Problem IC97386 | Status: Closed |
PD_GET_DIAG_HIST() FUNCTION WITH GIVEN TIMESTAMP PARAMETERS OR DB2DIAG TOOL WITH -H OR -t OPTION MAY HANG OR CRASH. | |
product: | |
DB2 FOR LUW / DB2FORLUW / A10 - DB2 | |
Problem description: | |
PD_GET_DIAG_HIST() table function with given timestamp parameters, or following db2diag commands: db2diag -H db2diag -t may become stuck looping without making any progress. They keep on dumping the same record or records indefinitely on the screen, or into a file. For PD_GET_DIAG_HIST() table function , it can leave sessions that cannot be forced from the DBMS. Operating system tools like top will show db2sysc process consuming up to 100% CPU. Using 'db2pd -edus' will reveal a single thread/EDU consuming most/all CPU time within the db2sysc process. A db2trc of this EDU will show it is looping in the following two functions: pdDiagGetNextRecordFromBuffer pdDiagReadFromFileIntoBufferBS Another symptom of the problem addressed by this APAR, might be a segmentation fault with following message in the db2diag.log: 2014-05-30-12.57.06.134995+120 I454687549E3355 LEVEL: Event PID : 6668 TID : 46912833054464 PROC : db2sysc 0 INSTANCE: db2inst1 NODE : 000 DB : SAMPLE APPHDL : 0-32561 APPID: *LOCAL.db2inst1.140530105704 AUTHID : db2inst1 HOSTNAME: host1 EDUID : 121 EDUNAME: db2agent (SAMPLE) 0 FUNCTION: DB2 UDB, oper system services, sqloPGRPRegisterOneCrash, probe:2154 MESSAGE : lastCrashCount DATA #1 : unsigned integer, 8 bytes 0 DATA #2 : String, 10 bytes inRecovery DATA #3 : Boolean, 1 bytes false CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol) [0] 0x00002AAAABE3ABFE pdLog + 0x38E [1] 0x00002AAAAE2E123D sqloPGRPRegisterOneCrash + 0x17D [2] 0x00002AAAAE328C01 sqloEDUCodeTrapHandler + 0x871 [3] 0x00002AAAAACDB7C0 /lib64/libpthread.so.0 + 0xF7C0 [4] 0x00002AAAAD52447B pdDiagLogGetNextTimestamp + 0x7B [5] 0x00002AAAAD56F7C8 pdDiagGetNextLogRecord + 0x118 [6] 0x00002AAAAD56F4DB pdDiagGetNextRecordFromBuffer + 0x3B [7] 0x00002AAAAD56F128 pdDiagGetNextRecord + 0x238 [8] 0x00002AAAAD4D10EF _ZN17PADiagLogCollEngn11getNextRowsEjPP13PA_DATA_VALUEPjS3_ + 0x54F [9] 0x00002AAAAE60818A _Z25sqlrwGetPDDiagHist_v10fp3P8sqlrr_cbP22sqlrwGetPDDiagHistArgs PPvPl + 0xA0A [10] 0x00002AAAACD44031 _Z30sqlrwGetWLMTableFunctionResultP8sqlrr_cbP20sqlrw_rpc_tf_requ estPPvPl + 0x571 [11] 0x00002AAAACD42C72 _Z36sqlrwGetWLMTableFunctionMergedResultjPPv + 0x1E2 [12] 0x00002AAAAC2CA64B _Z29sqlerTrustedRtnCallbackRouterjPPv + 0x8B [13] 0x00002AAC1EC3AAF7 pd_get_diag_hist_v10fp3 + 0x1A07 ... | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * All * **************************************************************** * PROBLEM DESCRIPTION: * * See Error Description * **************************************************************** * RECOMMENDATION: * * Upgrade to DB2 Version 10.1 FixPack 4 * **************************************************************** | |
Local Fix: | |
Change the size of db2diag.log. For example: truncate the current db2diag.log file by executing '> db2diag.log'. This will break the loop and result in SQL1042C being returned by the EDU. | |
available fix packs: | |
DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows | |
Solution | |
First fixed in DB2 Version 10.1 FixPack 4 | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 04.11.2013 03.06.2014 23.07.2014 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) | |
10.1.0.4 |