DB2 - Problem description
Problem IC64699 | Status: Closed |
HADR IS DISCONNECTED INCORRECTLY WITH HADR_PEER_WAIT_LIMIT IN ASYNC MODE | |
product: | |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 | |
Problem description: | |
This happen only for HADR environment. When HADR_PEER_WAIT_LIMIT is set to a non-zero value and HADR is in ASYNC mode, Primary Server will change the HADR status to disconnected unnecessarily after sending transaction log to Standby Server. At that time, the warning message similar to the following is written to the db2diag.log. 2009-02-23-23.12.03.064802+540 I12836A446 LEVEL: Warning PID : 1683540 TID : 1 PROC : db2hadrp (NEKO 1) 0 INSTANCE: e81q17d NODE : 000 DB : NEKO1 FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEve nt, probe:20207 MESSAGE : Peer wait limit reached. Breaking connection. DATA #1 : Hexdump, 4 bytes 0x078000002099F694 : 49A2 AEAF I... . | |
Problem Summary: | |
**************************************************************** * USERS AFFECTED: * * HADR user with async mode * **************************************************************** * PROBLEM DESCRIPTION: * * Incorrect behavior of hadr edu leads to pair * * disconnectionwhen hadr_peer_wait_limit gets set and the hadr * * sync mode isasync. * **************************************************************** * RECOMMENDATION: * * apply the FP. * **************************************************************** | |
Local Fix: | |
Not available | |
available fix packs: | |
DB2 Version 9.7 Fix Pack 1 for Linux, UNIX, and Windows | |
Solution | |
The problem is fixed by interchange the order of hadr primary shipping log page and updating the timestamp since last successful logship. | |
Workaround | |
not known / see Local fix | |
Timestamps | |
Date - problem reported : Date - problem closed : Date - last modified : | 19.11.2009 10.03.2010 10.03.2010 |
Problem solved at the following versions (IBM BugInfos) | |
Problem solved according to the fixlist(s) of the following version(s) | |
9.7.0.1 |