To achieve optimal performance with High Availability Disaster
Recovery (HADR), consider HADR restrictions when designing your high
availability DB2® database solution.
The following list is a summary of HADR restrictions:
- HADR is not supported in a partitioned database environment.
- The primary and standby databases must have the same operating
system version and the same version of the DB2 database system, except for a short time
during a rolling upgrade.
- The DB2 database system
software on the primary and standby databases must be the same bit
size (32 or 64 bit).
- Clients cannot connect to the standby
database unless you have reads on standby enabled. Reads on standby
enables clients to connect to the active standby database and issue
read-only queries.
- If reads on standby is enabled, operations
on the standby database that write a log record are not permitted;
only read clients can connect to the active standby database.
- If reads on standby is enabled, write
operations that would modify database contents are not allowed on
the standby database. Any asynchronous threads such as real-time statistics
collection, Auto Index rebuild and utilities that attempt to modify
database objects will not be supported. Real-time statistics collection
and Auto Index rebuild should not be running on the standby database.
- Log files are only archived by the primary database.
- The self tuning memory manager (STMM) can
be run only on the current primary database. After the primary database
is started or the standby database is converted to a primary database
by takeover, the STMM EDU may not start until the first client connection
comes in.
- Backup operations are not supported on the standby database.
- Non-logged operations, such as changes to database
configuration parameters and to the recovery history file, as well
as LOB table columns that have the NOT LOGGED option,
are not replicated to the standby database.
- Load operations with the COPY NO option specified
are not supported.
- HADR does not support the use of raw I/O (direct disk access)
for database log files. If HADR is started via the START
HADR command, or the database is activated (restarted)
with HADR configured, and raw logs are detected, the associated command
will fail.
- Federated
server does not fully support HADR. For one-phase commit, a HADR database
can act as either a federated server (transaction manager), or a data
source (resource manager), which requires client reroute configuration.
For two-phase commit, an HADR database can only act as the data source;
the HADR database cannot act as a federated server for data consistency
limitations.
- HADR does not support infinite logging.
- The
system clock of the HADR primary database must be synchronized with
the HADR standby database's system clock.
DB2 Version 9.7 for Linux, UNIX, and Windows