DB2 FOR LUW / DB2FORLUW / A10 - DB2

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 
...

**************************************************************** 
* USERS AFFECTED:                                              * 
* All                                                          * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 Version 10.1 FixPack 4                        * 
****************************************************************

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.

DB2 Version 10.1 Fix Pack 4 for Linux, UNIX, and Windows
 DB2 Version 10.1 Fix Pack 6 for Linux, UNIX, and Windows
 

First fixed in DB2 Version 10.1 FixPack 4

keiner bekannt / siehe Local-Fix

Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:

04.11.2013
03.06.2014
23.07.2014