The following messages are written the db2diag.log file by the
db2bm agent, relevant information is:
* Object data type 67, type:67
* A very high page number being requested to read:
Page number 18515200 == 0x11A8500, the first 0x1 is the CBIT,
which is wrong
The correct page number is 0x1A8500 == 1737984, which will be
shown in a db2dart /DEMP output
2013-12-30-08.57.07.766922+060 I4056701A13394 LEVEL:
Severe
PID : 59703522 TID : 100526 PROC :
db2sysc 0
INSTANCE: yyyyy NODE : 000 DB : xxx
APPHDL : 0-30740 APPID: *LOCAL.yyyyy.131230075506
AUTHID : yyyyyy HOSTNAME: zzzzz
EDUID : 100526 EDUNAME: db2bm.61941.7 (xxx) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbDMSMapAndRead,
probe:30
MESSAGE : ZRC=0x870F0009=-2029060087=SQLO_EOF "the data does not
exist"
DIA8506C Unexpected end of file was reached.
DATA #1 : Object descriptor, PD_TYPE_SQLB_OBJECT_DESC, 96 bytes
Obj: {pool:48;obj:4;type:67} Parent={0;0}
lifeLSN: 0000000000000000
tid: 0 0 0
...
2013-12-30-08.57.07.800932+060 E4071696A696 LEVEL:
Warning
PID : 59703522 TID : 100526 PROC :
db2sysc 0
INSTANCE: yyyyy NODE : 000 DB : xxx
APPHDL : 0-30740 APPID: *LOCAL.yyyyy.131230075506
AUTHID : yyyyyy HOSTNAME: zzzzz
EDUID : 100526 EDUNAME: db2bm61941.7 (xxx) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbDMSMapAndRead,
probe:30
MESSAGE : ADM6006E DB2 encountered an error while reading page
"18515200" from
table space "48" for object "4" (located at offset
"2314402" of
container "xxx").
...
2013-12-30-08.57.07.846456+060 E4093853A970 LEVEL:
Severe
PID : 59703522 TID : 103353 PROC :
db2sysc 0
INSTANCE: yyyyy NODE : 000 DB : xxx
APPHDL : 0-30740 APPID: *LOCAL.yyyyy.131230075506
AUTHID : yyyyyy HOSTNAME: zzzzz
EDUID : 103353 EDUNAME: db2bm.61941.7 (CAP) 0
FUNCTION: DB2 UDB, database utilities, sqlubReadDMS, probe:265
MESSAGE : SQL1655C The operation could not be completed due to
an error
accessing data on disk.
DATA #1 : SQLCA, PD_DB2_TYPE_SQLCA, 136 bytes
sqlcaid : SQLCA sqlcabc: 136 sqlcode: -1655 sqlerrml: 3
sqlerrmc: 143
sqlerrp : sqlubRea
sqlerrd : (1) 0x00000000 (2) 0x00000000 (3)
0x00000000
(4) 0x00000000 (5) 0x00000000 (6)
0x00000000
sqlwarn : (1) (2) (3) (4) (5) (6)
(7) (8) (9) (10) (11)
sqlstate:
The stack trace written to the FODC directory looks like this:
0x09000000004BDEB4 pthread_kill
0x0900000012C9DAFC sqloDumpEDU
0x09000000130ED61C sqlbDMSMapAndRead
0x09000000123C456C sqlbDMSDirectRead
0x09000000123C3AAC sqlbDirectRead
0x0900000012CF2314 sqlbDirectReadEMPPage
0x0900000012CF1FA0 sqlbMapIndirectEMPs
0x0900000012CEF95C sqlbMapLongObjectExtents
0x0900000014036548 sqlubReadDMS
0x0900000014032CD4 sqlubBMProcessData
0x090000001402EEEC sqlubbuf
0x090000001317CC4C sqleSubCoordProcessRequest
0x0900000012752C0C RunEDU
0x0900000012751D28 EDUDriver
0x0900000012751BB0 sqlzRunEDU
0x09000000127623C4 sqloEDUEntry
Root cause is triggered by CBIT values beeing stored by DB2 on
pages written out to disk.
These CBIT values are wrongly interpreted by the backup code
during EMP page processing, leading to far too high page
numbers, which trigger the SQL_EOF error.
This APAR will make sure, that CBIT values are processed
correctly, before the data is evaluated by the backup code. |
