DB2 Version 10.1 for Linux, UNIX, and Windows
DB2 Version 10.1 for Linux, UNIX, and Windows
This parameter specifies the number of seconds that must pass from the time that a transaction is committed on the primary database to the time that the transaction is committed on the standby database.
The hadr_replay_delay configuration parameter enables delayed replay on the HADR standby database, meaning that the standby intentionally lags the HADR primary database as the logs from the primary are replayed. The standby database must be in SUPERASYNC mode before hadr_replay_delay can be set to a nonzero value. You cannot set the parameter on the primary database. You must disable delayed replay on the standby before it can take over as the primary.
If you enable delayed replay, it is recommended that you also enable log spooling by setting the hadr_spool_limit database configuration parameter. Because of the intentional delay, replay position can be far behind log receive position on standby. Without spooling, log receive can only go beyond replay by the amount of the receive buffer. With spooling, the standby can receive much more logs beyond replay position, providing more protection against data loss in case of primary failure. Note that in either case, because of the mandatory SUPERASYNC mode, the primary will not be blocked by the delayed replay.
With delayed replay, if there is an errant transaction on the primary and it is noticed before it is replayed on the standby, you can roll forward the database to a time that is right before when the errant transaction is committed, then stop roll forward to retrieve data lost on the primary.