75 ways to demystify DB2: #12: Tech Tip : Fixpack upgrade in HADR environment with SUPERASYNC mode

Body

When performing a DB2 fixpack upgrade (rolling upgrade), for example from DB2 V9.7 FP8 to DB2 V9.7 FP9, in an HADR environment where HADR_SYNCMODE is set to SUPERASYNC as shown below :

  HADR database role                                      = PRIMARY
 HADR local host name                  (HADR_LOCAL_HOST) = myhost1
 HADR local service name                (HADR_LOCAL_SVC) = 60059
 HADR remote host name                (HADR_REMOTE_HOST) = myhost2
 HADR remote service name              (HADR_REMOTE_SVC) = 60059
 HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst1
 HADR timeout value                       (HADR_TIMEOUT) = 180
 HADR log write synchronization mode     (HADR_SYNCMODE) = SUPERASYNC
 HADR peer window duration (seconds)  (HADR_PEER_WINDOW) = 0

you can switch the role of the databases between the primary and standby when the synchronization mode is SUPERASYNC. In this mode, the HADR pair can never be in a peer state or disconnected peer state. Log shipping only use remote catchup state. Hence, a non forced takeover is allowed in this state.

The caution in this case is to be mindful of a long takeover if the standby is too far behind the primary before performing the rolling update. Therefore, before starting a none forced takeover operation, check the log gap between the primary and standby databases using the command db2pd -hadr -db dbname.

For example :

Database Partition 0 -- Database SAMPLE -- Active Standby -- Up 37 days 02:36:00 -- Date 2015-02-25-18.52.47.553528

HADR Information:
Role    State                SyncMode   HeartBeatsMissed   LogGapRunAvg (bytes)
Standby RemoteCatchup        Superasync 0                  1

ConnectStatus ConnectTime                           Timeout
Connected     Mon Jan 19 16:16:49 2015 (1421705809) 180

ReplayOnlyWindowStatus ReplayOnlyWindowStartTime             MaintenanceTxCount
Inactive               N/A                                   0

LocalHost                                LocalService
myhost2                                  60059

RemoteHost                               RemoteService      RemoteInstance
myhost1                                  60059              db2v97

PrimaryFile  PrimaryPg  PrimaryLSN
S0000000.LOG 0          0x0000000004650010

StandByFile  StandByPg  StandByLSN         StandByRcvBufUsed
S0000000.LOG 0          0x0000000004650010 0%
 

A large gap causes a long elapsed time for the takeover operation. Because the standby database must retrieve the logs in the gap and replay them. It is recommended that you perform non forced takeover operations only when the log gap is small.