home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC74011 Status: Geschlossen

LOG WRITES ON PRIMARY IN HADR COULD BE SUSPENDED AFTER GETTING THE NEARLY
PEER ACK MESSAGE (HDR_MSG_NPEERACK) FROM STANDBY

Produkt:
DB2 FOR LUW / DB2FORLUW / 950 - DB2
Problembeschreibung:
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.
Problem-Zusammenfassung:
USERS AFFECTED: 
 
=============== 
Customer using version 9.5 and above on all platforms. 
 
PROBLEM DESCRIPTION: 
==================== 
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). Please see the 
db2diag.log entry and stacks to help you identify applicability 
of this APAR. 
 
RECOMMENDATION: 
=============== 
Perform a forced hadr takeover by the standby.
Local-Fix:
Perform a forced hadr takeover by the standby.
verfügbare FixPacks:
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows

Lösung
Problem is first fixed in version 9.5 Fixpack 8.
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
21.01.2011
21.07.2011
21.07.2011
Problem behoben ab folgender Versionen (IBM BugInfos)
9.5.FP8
Problem behoben lt. FixList in der Version
9.5.0.8 FixList