In a hadr pair, the primary db could get into a state whereby
only select commands against the database will succeed (a).
Another symptom of the above could be that a db2stop force or a
deactivation of the database may hang (b)
Look for the following message in the db2diag.log to check for
symptom (a), no such messages would be present for symptom (b)
2010-02-12-09.00.00.386817+480 I36240844A379 LEVEL: Warning
PID : 1527822 TID : 31613 PROC : db2sysc
0
INSTANCE: DB2INST1 NODE : 000
EDUID : 12345 EDUNAME: db2hadrp (SAMPLEDB) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrTransitionPtoNPeer, probe:10645
MESSAGE : near peer catchup starts at LSO 7612272385
If the above above message is noticed and there are no further
messages such as "HADR state set to P-NearlyPeer" from
hdrSetHdrState() then for both symptoms (a) and (b) the stack
for the db2hadrp process will have to be checked to verify that
this APAR has been encountered.
After you have dumped the stacks (db2pd -stack all) then run the
grep command below and check the output is similar to the
following to verify running into the apar. Ie look for latch
type: SQLO_LT_SQLP_DBCB__wTaskSem
grep -i waiting *
5507.50.000.stack.txt:Waiting on latch type:
(SQLO_LT_SQLP_DBCB__wTaskSem) - Address: (0x2aaaf2391680), Line:
1040, File: sqlpwlg.C
5507.67.000.stack.txt:Waiting on latch type:
(SQLO_LT_SQLP_DBCB__IOTaskSem) - Address: (0x2aaaf2391600),
Line: 41, File: sqlpiPostLogger_inlines.h
$ grep -i holding *
5507.67.000.stack.txt:Holding Latch type:
(SQLO_LT_SQLP_DBCB__wTaskSem) - Address: (0x2aaaf2391680), Line:
2677, File: hdr.C HoldCount: 1
5507.67.000.stack.txt:Holding Latch type:
(SQLO_LT_SQLP_DBCB__IOTaskSem) - Address: (0x2aaaf2391600),
Line: 2676, File: hdr.C HoldCount: 1
If the above is noticed then you have run into this apar. The
fix for this apar is available in v9.7 Fixpak 1. |
