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 IC64025 Status: Geschlossen

DB2_HADR_PEER_WAIT_LIMIT DOES NOT WORK PROPERLY DURING THE TRANSITION
FROM REMOTE CATCHUP STATE TO PEER STATE

Produkt:
DB2 FOR LUW / DB2FORLUW / 970 - DB2
Problembeschreibung:
We have a database configuration parameter HADR_TIMEOUT, which 
does not break the primary out of peer state if the primary 
keeps receiving heartbeat messages from the standby while 
blocked until an HADR database has not received any message from 
its partner for the HADR_TIMEOUT period. 
 
  Then, some transactions with log flush situation may be 
blocked if log replay on the standby database is stuck on a 
large operation such as load or reorganization and the HADR 
component will still send heartbeat messages to the primary 
database on normal schedule. 
 
  On the other hand, we have a registry variable 
DB2_HADR_PEER_WAIT_LIMIT.  When it is set, HADR primary database 
will break out of peer state if logging on the primary database 
has been blocked for the specified number of seconds by 
DB2_HADR_PEER_WAIT_LIMIT. 
 
  After disconnection, the standby database will continue 
replaying already received logs.  Once received logs have been 
replayed, the standby will reconnect to the primary.  Upon 
re-connection, normal state transition follows (first remote 
catchup state, then peer state). 
 
  So the intention of DB2_HADR_PEER_WAIT_LIMIT registry variable 
is to not block the primary database and it should be operated 
properly during the transition from remote catchup state to peer 
state (the transition is internally known as nearly-peer state).
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* ALL HADR USER                                                * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* when the registry var  hadr_peer_wait_limit was introduced,  * 
* it did not apply to the near peer state. the fix was povided * 
* in v91 and merged into v97.                                  * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* upgrade to the new fix pack                                  * 
****************************************************************
Local-Fix:
Not available
verfügbare FixPacks:
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 2 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 3a for Linux, UNIX, and Windows
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 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 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 10 for Linux, UNIX, and Windows

Lösung
extend the applicability of peer wait limit var to near peer 
state
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
22.10.2009
08.03.2010
08.03.2010
Problem behoben ab folgender Versionen (IBM BugInfos)
Problem behoben lt. FixList in der Version
9.7.0.1 FixList