Parameter Wednesday – DB CFG – HADR_TIMEOUT

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_TIMEOUT
 HADR timeout value                       (HADR_TIMEOUT) = 120


> 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_timeout' with ur"

-------------------------------- ---------------- ----------- ---------------- -------------------- ----------------
hadr_timeout                     120              NONE        120              NONE                 BIGINT

  1 record(s) selected.


Specifies the time (in seconds) that the HADR process waits before considering a communication attempt to have failed.

If HADR_TIMEOUT is also set, the HADR status goes to “remote catchup pending”. If HADR_TIMEOUT is also set, then the database goes into “disconnected” if the database is not able to contact it’s peer within this time.

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.




1 – 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_TIMEOUT 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 dbm cfg for dbname using HADR_TIMEOUT 120

Rule of Thumb

The default here is good if you don’t have especially tight failover times required.

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 any short network “blips”, and if failover time is important, to the lowest possible value that allows you to do this.

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

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: 556

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.