Db2 High Availability Disaster Recovery (HADR) non-replicated operations

Db2 High Availability Disaster Recovery (HADR) uses database logs to replicate data from the primary database to the standby database. Non-logged operations are allowed on the primary database, but not replicated to the standby database. If you want non-logged operations, such as updates to the history file, to be reflected in the standby database, you must take extra steps to cause this to happen.

The following are examples of cases in which operations on the primary database are not replicated to the standby database:

Tables created with the NOT LOGGED INITIALLY option specified are not replicated. Attempts to access such tables after an HADR standby database takes over as the primary database result in an error.
All logged LOB columns are replicated. Non-logged LOB columns are not replicated. However, the space for them is allocated on the standby database using binary zeros as the value for the column.
Updates to database configuration using the UPDATE DATABASE CONFIGURATION and UPDATE DATABASE MANAGER CONFIGURATION commands are not replicated.
Database configuration and database manager configuration parameters are not replicated.
For user-defined functions (UDFs), changes to objects external to the database (such as related objects and library files) are not replicated. They need to be set up on the standby via other means.
The recovery history file (db2rhist.asc), and changes to it, are not automatically shipped from the primary database to the standby database.
You can place an initial copy of the history file (obtained from the backup image of the primary) on the standby database by issuing the RESTORE DATABASE command with the REPLACE HISTORY FILE parameter:
```
   RESTORE DB KELLY REPLACE HISTORY FILE
```
After HADR is initialized and subsequent backup activities take place on the primary database, the history file on the standby database becomes out of date. However, a copy of the history file is stored in each backup image. Alternatively, you can create a no table space backup image that contains a more recent copy of the history file by using the following command:
```
   BACKUP DB KELLY NO TABLESPACE
```
You can update the history file on the standby by extracting the history file from a backup image by using the following command:
```
   RESTORE DB KELLY HISTORY FILE
```
Do not use regular operating system commands to copy the history file in the database directory from the primary database to the standby database. The history file can become corrupted if the primary is updating the files when the copy is made.

If a takeover operation occurs and the standby database has an up-to-date history file, backup and restore operations on the new primary generate new records in the history file and blend seamlessly with the records generated on the original primary. If the history file is out of date or has missing entries, an automatic incremental restore might not be possible; instead, a manual incremental restore operation is required.