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 High Availability Disaster
Recovery (HADR) restrictions:
- HADR is not supported in a partitioned database environment.
- HADR is not supported in DB2 pureScale® environments.
- 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.
- The SET
WRITE command cannot be issued 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 in federated two phase commit (F2PC) scenarios.
When a HADR database is configured as a federated database, it only
supports F2PC with type-1 inbound connections.
- 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 10.1 for Linux, UNIX, and Windows