|
Problem IC78622
|
Status: Closed |
AN EDU MAY HANG DURING POST-CRASH DIAGNOSTIC INFORMATION GATHERING. |
| product: |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 |
| Problem description: |
In certain circumstances an EDU that has crashed whilst
traversing locking data may hang whilst producing diagnostic
information dumps.
To verify if it is this issue check:
- DB2 instance has hung.
- There is evidence of a crash having occurred in the
db2diag.log.
- The reported crash information gathering has not completed for
some time.
- There is a trap stack file
(<pid>.<edu>.<dbpartitionnum>.trap.txt) that has been generated
under the DUMPDIR (likely in an FODC sub-directory) in which the
stack will have the top frames:
sqlpLatchHashEntryForTableLockShare
sqlplrm
sqlpxprp
sqlrr_tran_router
...
- The trap file shows (amongst others) a latch of type
"SQLO_LT_SQLP_LTRN_CHAIN__entry_latch" being held.
- A second stack trace generated for the EDU, explicitly via
db2pd -dump <EDU> or as part of an attempted db2stop, shows in
the stack file (<pid>.<edu>.<dbpartitionnum>.stack.txt) nested
signals with the second stack matching that of the trap file:
sqloXlatchConflict
gettrans
sqlpLockDump
sqlp_dump_state
sqldDumpContext
sqldDumpContext
sqlrr_dump_ffdc
sqlrr_signal_handler
sqloExecuteEDUExitList
Nested signal handlers detected
sqlpLatchHashEntryForTableLockShare
sqlplrm
sqlpxprp
sqlrr_tran_router
...
- It also shows it waiting on a latch of type
"SQLO_LT_SQLP_LTRN_CHAIN__entry_latch" with the same address as
in the original trap file.
To resolve the hang situation the instance will have to be
explicitly killed. Before stopping DB2 it is recommended a core
dump of the db2sysc process is manually gathered (if possible)
as it will likely be required for the investigation into the
cause of the initial crash. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All. *
****************************************************************
* PROBLEM DESCRIPTION: *
* In certain circumstances an EDU that has crashed whilst *
* traversing locking data may hang whilst producing diagnostic *
* information dumps. *
* *
* To verify if it is this issue check: *
* *
* - DB2 instance has hung. *
* - There is evidence of a crash having occurred in the *
* db2diag.log. *
* - The reported crash information gathering has not completed *
* for some time. *
* - There is a trap stack file *
* (<pid>.<edu>.<dbpartitionnum>.trap.txt) that has been *
* generated under the DUMPDIR (likely in an FODC *
* sub-directory) in which the stack will have the top frames: *
* *
* sqlpLatchHashEntryForTableLockShare *
* sqlplrm *
* sqlpxprp *
* sqlrr_tran_router *
* ... *
* *
* - The trap file shows (amongst others) a latch of type *
* "SQLO_LT_SQLP_LTRN_CHAIN__entry_latch" being held. *
* *
* - A second stack trace generated for the EDU, explicitly via *
* db2pd -dump <EDU> or as part of an attempted db2stop, shows *
* in the stack file (<pid>.<edu>.<dbpartitionnum>.stack.txt) *
* nested signals with the second stack matching that of the *
* trap file: *
* *
* sqloXlatchConflict *
* gettrans *
* sqlpLockDump *
* sqlp_dump_state *
* sqldDumpContext *
* sqldDumpContext *
* sqlrr_dump_ffdc *
* sqlrr_signal_handler *
* sqloExecuteEDUExitList *
* *
* Nested signal handlers detected *
* *
* sqlpLatchHashEntryForTableLockShare *
* sqlplrm *
* sqlpxprp *
* sqlrr_tran_router *
* ... *
* *
* - It also shows it waiting on a latch of type *
* "SQLO_LT_SQLP_LTRN_CHAIN__entry_latch" with the same address *
* as in the original trap file. *
* *
* To resolve the hang situation the instance will have to be *
* explicitly killed. Before stopping DB2 it is recommended a *
* core dump of the db2sysc process is manually gathered (if *
* possible) as it will likely be required for the *
* investigation into the cause of the initial crash. *
****************************************************************
* RECOMMENDATION: *
* Update to version 9.5 fixpack 9 or later fixpacks. *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
This problem is first fixed in version 9.5 fixpack 9. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 13.09.2011
12.03.2012
12.03.2012 |
| Problem solved at the following versions (IBM BugInfos) |
9.5.FP9
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.5.0.9
|
 |
