HADR delayed replay helps prevent data loss due to errant transactions. To implement HADR delayed replay, set the hadr_replay_delay database configuration parameter on the HADR standby database.
Delayed replay intentionally keeps the standby database at a point in time that is earlier than that of the primary database by delaying replay of logs on that standby. If an errant transaction is executed on the primary, you have until the configured time delay has elapsed to take action to prevent the errant transaction from being replayed on the standby. To recover the lost data, you can either copy this data back to the primary, or you can have the standby take over as the new primary database.
(current time on the standby - value of the hadr_replay_delay configuration parameter) >=
timestamp of the committed log record
You
should set the hadr_replay_delay database configuration
parameter to a large enough value to allow time to detect and react
to errant transactions on the primary.You can use this feature with one standby, multiple standbys, and in a DB2® pureScale® environment. With multiple standbys, typically one or more standbys stays current with the primary for high availability or disaster recovery purposes, and one standby is configured with delayed replay for protection against errant transactions. If you use this feature with one standby, you should not enable IBM® Tivoli® System Automation for Multiplatforms because the takeover will fail.
The objective of this feature is to protect against application error. If you want to use this feature and ensure that there is no data loss in the event of a primary failure, consider a multiple standby setup with a more synchronous setting on the principal standby.