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. You can update the history file on the standby by extracting
the history file from a backup image 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.