Db2 High Availability Disaster Recovery (HADR) replicated operations

Db2 High Availability Disaster Recovery (HADR) uses database logs to replicate data from the primary database to the standby database. Some activities can cause the standby database to fall behind the primary database as logs are replayed on the standby database. Some activities are so heavily logged that the large amount of log files they generate can cause storage problems. Although replicating data to the standby database using logs is the core of availability strategies, logging itself can potentially have a negative impact on the availability of your solution. Design you maintenance strategy wisely, configure your system to minimize the negative impact of logging, and allow logging to protect your transaction data.
In high availability disaster recovery (HADR), the following operations are replicated from the primary database to the standby database:
  • Data definition language (DDL)
  • Data manipulation language (DML)
  • Buffer pool operations
  • Table space operations
  • Online reorganization
  • Offline reorganization
  • Metadata for stored procedures and user defined functions (but not the associated object or library files). Java stored procedures that are saved as .jar files are one exception; more information is provided below.

During an online reorganization operation, all changes made are logged in detail. As a result, HADR can replicate the operation without the standby database falling further behind than it would for more typical database updates. However, this behavior can potentially have a large impact on the system because of the large number of log records generated.

While offline reorganizations are not logged as extensively as online reorganizations, operations are typically logged per hundreds or thousands of affected rows. This means that the standby database could fall behind because it waits for each log record and then replays many updates at once. If the offline reorganization is non-clustered, a single log record is generated after the entire reorganization operation. This mode has the greatest impact on the ability of the standby database to keep up with the primary database. The standby database will perform the entire reorganization after it receives the log record from the primary database.

HADR does not replicate stored procedure and UDF object and library files. You must create the files on identical paths on both the primary and standby databases. If the standby database cannot find the referenced object or library file, the stored procedure or UDF invocation will fail on the standby database.

Important: An additional step is required during the replication operation for Java stored procedures that are saved as .jar files. After failover, applications receive a SQL4304N message when accessing the stored procedure on the new HADR primary database. To avoid this message, you must run sqlj.refresh_classes() or sqlj.recoverjar() before the stored procedure can be used. Note that this complication does not apply to Java stored procedures which are saved as .java files.