Parameter Wednesday – DB CFG – HADR_PEER_WINDOW

Edited 9/6 to correct syntax and Grammar.

DB2 Version This Was Written For


Parameter Name


Where This Parameter Lives

Database Configuration

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"

-------------------------------- ---------------- ----------- ---------------- -------------------- ----------------
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.


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.

Tuning Considerations

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:

Related Parameters

I’m listing all the configurable HADR config parameters here, as they are related

Blog Entries Related to this Parameter


Parameter Wednesday – DB CFG – HADR_SYNCMODE

Parameter Wednesday – DB CFG – HADR_TIMEOUT

Ember Crooks
Ember Crooks

Ember is always curious and thrives on change. She has built internationally recognized expertise in IBM Db2, spent a year working with high-volume MySQL, and is now learning Snowflake. Ember shares both posts about her core skill sets and her journey learning Snowflake.

Ember lives in Denver and work from home

Articles: 554

One comment

  1. Love your articles!
    One minor typo…
    db2 update dbm cfg for dbname using HADR_PEER_WINDOW 120
    should be
    db2 update db cfg for dbname using HADR_PEER_WINDOW 120

    Plus, loose should be lose, but that’s much less relevant 🙂

    Keep up the great DB2 pointers!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.