Instructs an HADR standby database to take over as the new HADR primary database for the HADR pair.
One of the following:
Instance. The command establishes a database connection if one does not exist, and closes the database connection when the command completes.
>>-TAKEOVER HADR ON--+-DATABASE-+--database-alias---------------> '-DB-------' >--+--------------------------------------+---------------------> '-USER--user-name--+-----------------+-' '-USING--password-' >--+--------------------------------+-------------------------->< '-BY FORCE--+------------------+-' '-PEER WINDOW ONLY-'
You cannot use the PEER WINDOW ONLY option when the synchronization mode is set to ASYNC or SUPERASYNC.
The following table shows the behavior of the TAKEOVER HADR command when issued on an active standby database for each possible state and option combination. An error message is returned if this command is issued on an inactive standby database.
Standby state | BY FORCE option used | Takeover behavior |
---|---|---|
Disconnected peer | No | NOT ALLOWED (SQL1770N) |
Disconnected peer | Yes, just BY FORCE | ALLOWED - NO ASSURANCE OF DATA CONSISTENCY Note: A
"no transaction loss" takeover is also possible using the TAKEOVER
BY FORCE command without the PEER WINDOW ONLY option,
i.e., unconditional failover, as long as the necessary conditions
hold. Such a failover can be executed even long after the expiration
of the peer window that was in effect when the primary failed.
|
Disconnected peer | Yes, BY FORCE PEER WINDOW ONLY | ALLOWED - GREATER DEGREE OF DATA CONSISTENCY There
are situations in which data loss can still happen:
|
Local catchup | No | An error message is returned. |
Local catchup | Yes | An error message is returned. |
Peer | No | Primary database and standby database switch
roles. If no failure is encountered during takeover, there will be no data loss. However, if failures are encountered during takeover, data loss might occur and the roles of the primary and standby might or might not have been changed. The following is a guideline for handling failures during a takeover in which the primary and standby switch roles:
|
Peer | Yes | Old primary marked as invalid, preventing it from writing any more logs or committing any more transactions. The next log write attempt brings down the database. However, if sessions on the old primary only run read-only queries, the old primary might stay up indefinitely. Existing client connections stay open as long as they perform read-only operations and new client connections might be accepted. To avoid a situation of dual-primary, it is recommended that you stop transaction processing on old primary first before issuing a TAKEOVER HADR command with the BY FORCE option. |
Remote catchup | No | In SUPERASYNC mode, you can perform non-forced takeover operations in remote catchup state. An error is returned in other synchronization modes. Before starting a non-forced takeover operation, check the log gap between the primary and standby databases. Because the standby database must retrieve the logs in the gap and replay them, a large gap will cause a long elapsed time for the takeover operation. It is recommended that you perform non-forced takeover operations only when the log gap is small. To reduce the log gap between the primary and the standby databases, consider stopping or reducing the workload on the primary database. |
Remote catchup | Yes | In SUPERASYNC mode, you can perform forced takeover operations in remote catchup state. An error will be returned in other synchronization modes. |
Remote catchup pending | No | An error message is returned. |
Remote catchup pending | Yes | The standby database becomes the primary database. |
When issuing the TAKEOVER HADR command, the corresponding error codes might be generated: SQL1767N, SQL1769N, or SQL1770N with a reason code of 98. The reason code indicates that there is no installed license for HADR on the server where the command was issued. To correct the problem, install a valid HADR license using the db2licm or install a version of the server that contains a valid HADR license as part of its distribution.
When you issue the TAKEOVER BY FORCE PEER WINDOW ONLY command, and it succeeds (you called it while the primary was disconnected from the standby, but still within the peer window), then there will not be any transaction information on the primary database that was not already copied to the standby database.
If you have reads on standby enabled, any user application currently connected to the standby will be disconnected to allow the takeover to proceed. Depending on the number of readers that are active on the standby, the takeover operation can take slightly longer to complete than it would if there were no readers on the standby. New connections will not be allowed during the role switch. Any attempt to connect to the HADR standby during the role switch on takeover will receive an error (SQL1776N).