|
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
DB2 Version 10.1 Fix Pack 6 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
|
 |
