|
Problem IC74771
|
Status: Closed |
SMALL TIMING WINDOW WHERE PARALLEL RECOVERY (ROLLFORWARD OR CRAS H RECOVERY) MAY HANG AFTER ALL LOG RECORDS HAVE BEEN PROCESSED. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
Customer will see that crash recovery or rollforward is not
making progress after it appears that all log records have been
processed. If you generate call stacks, you may see something
similar to this.
The redo master process is waiting :
0x00002ACC32851DCD ossSleep + 0x0059
(/home/eunicec2/sqllib/lib64/libdb2osse.so.1)
0x00002ACC2C4C770F sqlorest + 0x008f
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC2C832662
_Z15sqlpPRecReadLogP8sqeAgentP8SQLP_ACBP14sqlpMasterDbcb +
0x5de8
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC2C7FA31E _Z20sqlpParallelRecoveryP8sqeAgentP5sqlca +
0x0d54
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC2A6F7AA1 _Z26sqleSubCoordProcessRequestP8sqeAgent +
0x00f3
and so is the redo worker :
0x00002ACC2C59AAA3 sqloDumpDiagInfoHandler + 0x01bb
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC27BE3D60 address: 0x00002ACC27BE3D60 ; dladdress:
0x00002ACC27BD6000 ; offset in lib: 0x000000000000DD60 ;
(/lib64/libpthread.so.0)
0x00002ACC3325C25A semtimedop + 0x000a
(/lib64/libc.so.6)
0x00002ACC2C47C5A6 _ZN13sqlo_waitlist11timeoutWaitEi + 0x018c
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC2C47B7A9 sqloWaitEDUWaitPost + 0x025b
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC2C836FA1
_Z19sqlprWaitDuringPRecP8sqeAgentP16SQLO_EDUWAITPOST + 0x0095
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC2C83B30D _Z14sqlprFindQueueP8sqeAgentP9SQLP_DBCBmmPm +
0x04dd
(/home/eunicec2/sqllib/lib64/libdb2e.so.1)
0x00002ACC2C832E6B
_Z15sqlpPRecProcLogP8sqeAgentP8SQLP_ACBP14sqlpMasterDbcb +
0x02c7
(/home/eunicec2/sqllib/lib64/libdb2e.so.1) |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All *
****************************************************************
* PROBLEM DESCRIPTION: *
* Customer will see that crash recovery or rollforward is not *
* *
* making progress after it appears that all log records have *
* been *
* processed. If you generate call stacks, you may see *
* something *
* similar to this. *
* *
* *
* *
* The redo master process is waiting : *
* *
* *
* *
* 0x00002ACC32851DCD ossSleep + 0x0059 *
* *
* *
* (/home/eunicec2/sqllib/lib64/libdb2osse.so.1) *
* 0x00002ACC2C4C770F sqlorest + 0x008f *
* *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC2C832662 *
* *
* _Z15sqlpPRecReadLogP8sqeAgentP8SQLP_ACBP14sqlpMasterDbcb + *
* *
* 0x5de8 *
* *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC2C7FA31E _Z20sqlpParallelRecoveryP8sqeAgentP5sqlca *
* + *
* 0x0d54 *
* *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC2A6F7AA1 _Z26sqleSubCoordProcessRequestP8sqeAgent *
* + *
* 0x00f3 *
* *
* *
* *
* and so is the redo worker : *
* *
* *
* *
* 0x00002ACC2C59AAA3 sqloDumpDiagInfoHandler + 0x01bb *
* *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC27BE3D60 address: 0x00002ACC27BE3D60 ; dladdress: *
* *
* 0x00002ACC27BD6000 ; offset in lib: 0x000000000000DD60 ; *
* *
* (/lib64/libpthread.so.0) *
* *
* 0x00002ACC3325C25A semtimedop + 0x000a *
* *
* (/lib64/libc.so.6) *
* *
* 0x00002ACC2C47C5A6 _ZN13sqlo_waitlist11timeoutWaitEi + *
* 0x018c *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC2C47B7A9 sqloWaitEDUWaitPost + 0x025b *
* *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC2C836FA1 *
* *
* _Z19sqlprWaitDuringPRecP8sqeAgentP16SQLO_EDUWAITPOST + *
* 0x0095 *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC2C83B30D *
* _Z14sqlprFindQueueP8sqeAgentP9SQLP_DBCBmmPm + *
* 0x04dd *
* *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
* *
* 0x00002ACC2C832E6B *
* *
* _Z15sqlpPRecProcLogP8sqeAgentP8SQLP_ACBP14sqlpMasterDbcb + *
* *
* 0x02c7 *
* *
* (/home/eunicec2/sqllib/lib64/libdb2e.so.1) *
****************************************************************
* RECOMMENDATION: *
* Apply Version 9.5 fixpack 7 *
**************************************************************** |
| Local Fix: |
Kill DB2 and restart the recovery. DB2 will continue from the
previous point and will complete the recovery successfully. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 4 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
Apply Version 9.5 fixpack 7 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 01.03.2011
01.03.2011
01.03.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.5.FP7
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.4
|
 |
