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 table reorganization, all operations are logged in detail, which can generate large numbers of log records. This process can cause the standby database to fall behind. Multiple concurrent online reorganizations on tables residing in the same table space have a greater impact on the standby falling behind compared to tables residing in different table spaces. Avoid running multiple concurrent online table reorganizations in parallel.

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 procedures or UDF object and library files, therefore 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.