Restrictions for high availability disaster recovery (HADR)

Restrictions for high availability disaster recovery (HADR)
https://www.ibm.com/docs/en/db2/11.1?topic=server-high-availability-disaster-recovery-hadr
To help achieve optimal performance with high availability disaster recovery (HADR), consider HADR restrictions when designing your high availability Db2® database solution.

HADR restrictions are as follows:
HADR is not supported in a partitioned database environment.
The primary and standby databases must be on the same operating system version and must use the same level of the Db2 database system, except for a short time during a rolling upgrade.
The Db2 software that you use for the primary database and the Db2 software that you use for the standby databases must be the same bit size (32 or 64 bit).
Clients cannot connect to the standby database unless you enable the reads on standby feature. This feature enables clients to connect to the active standby database and issue read-only queries.
Only read clients can connect to an active standby database; however, operations on the standby database that write a log record are not permitted, nor are the following operations that modify database contents:
any asynchronous threads such as real-time statistics collection
automatic index rebuilds and utilities that modify database objects
Log files are archived only by the primary database.
You can run the self-tuning memory manager (STMM) only on the current primary database. After you start the primary database or convert the standby database to a primary database by takeover, the STMM EDU might not start until the first client connection is made.
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, the recovery history file, and LOB table columns for which you specified the NOT LOGGED parameter, are not replicated to the standby database.
Load operations for which you specify the COPY NO parameter are not supported.
HADR does not support the use of raw I/O (direct disk access) for database log files. If you start HADR by using the START HADR command or the database is activated or restarted with HADR configured and raw logs are detected, the associated command fails.
Federated servers do not fully support HADR in federated two-phase commit (F2PC) scenarios. If you configure an HADR database as a federated database, it supports F2PC only with type-1 inbound connections.
HADR does not support infinite logging.
Ensure that the system clock of the HADR primary database is synchronized with the system clock of the HADR standby database.
Parent topic: High availability disaster recovery (HADR) support
Related concepts
Db2 High Availability Disaster Recovery (HADR) non-replicated operations
Db2 High Availability Disaster Recovery (HADR) replicated operations
HADR reads on standby feature
Reads on standby restrictions
Restrictions for HADR in Db2 pureScale environments
Restrictions for multiple standby databases
Related tasks
Performing rolling updates in a Db2 high availability disaster recovery (HADR) environment