Parameter Wednesday – DB CFG – HADR_PEER_WINDOW
Edited 9/6 to correct syntax and Grammar.
DB2 Version This Was Written For
Where This Parameter Lives
How To Check Value
> db2 get db cfg for sample |grep HADR_PEER_WINDOW HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 0
> db2 "select name, substr(value,1,16) value, value_flags, substr(deferred_value,1,16) deferred_value, deferred_value_flags, substr(datatype,1,16) datatype from SYSIBMADM.DBCFG where name='hadr_peer_window' with ur" NAME VALUE VALUE_FLAGS DEFERRED_VALUE DEFERRED_VALUE_FLAGS DATATYPE -------------------------------- ---------------- ----------- ---------------- -------------------- ---------------- hadr_peer_window 0 NONE 0 NONE BIGINT
Specifies the time (in seconds) that the HADR database peer continues to act as though it is in sync after the two databases lose communication with each other.
If HADR_SYNCMODE is Async or SuperAsync, then this parameter is ignored. This parameter is also ingnored if the database on the standby is explicitly deactivated while the pair is in a peer state.
As designed, you will not be able to connect to a recently restarted primary database if the standby is not available without using the force option for starting hadr on the primary. For this reason, you should always ensure the standby is up before starting the primary.
Effects the total time it takes for a database to fail over. Does not generally affect normal functioning.
0 – 4,294,967,295
Recycle Required To Take Effect?
Yes – this annoys me with HADR parameters, but like all the rest of the HADR parameters, HADR_PEER_WINDOW requires a recycle of the database (not the database manager) to take effect.
Can It Be Set To AUTOMATIC?
No, there is no AUTOMATIC option for this parameter. You must set it based on the requirements of your HADR implentation.
How To Change It
db2 update db cfg for dbname using HADR_PEER_WINDOW 120
Rule of Thumb
There’s really no need to set this if you’re not using some sort of hearbeat or automated failover tool. If you’re using TSA/db2haicu, then you should set this – 300 seconds is a common value to use.
Usually you make a decision on this when you are building out a system or setting HADR up for the first time, and do not change it again. If you need a failover to occur quickly, then you should reduce the value for this parameter. The total failover time should maximally be HADR_TIMEOUT plus HADR_PEER_WINDOW. Essentially you want to set this parameter to a value that will allow for the amount of time that a “takeover database” command takes along with any other scripting involved in an automated failover, and if failover time is important, to the lowest possible value that allows you to do this. IBM recommends a minimum time of 120 seconds for this. I’ve seen it set lower successfully.
Related Error Messages
War Stories From The Real World
It can be confusing to understand the difference between this and HADR_TIMEOUT. Take the time to understand them before deciding on settings. Essentially, HADR_TIMEOUT is set so that a super-short network blip doesn’t cause a failover, and HADR_PEER_WINDOW is set to allow time for any failover automation to perform failover commands.
Frequently, if you don’t know what to do and you don’t really care whether your failover takes 2 minutes or 5 minutes, HADR_TIMEOUT of 120 and HADR_PEER_WINDOW of 300 work well.
Link To Info Center
Good Info center page with more details: http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.ha.doc/doc/c0056394.html
Blog Entries Related to this Parameter
Parameter Wednesday – DB CFG – HADR_TIMEOUT