DB2 Version 9.7 for Linux, UNIX, and Windows

TAKEOVER HADR command

Instructs an HADR standby database to take over as the new HADR primary database for the HADR pair.

Authorization

One of the following:

sysadm
sysctrl
sysmaint

Required connection

Instance. The command establishes a database connection if one does not exist, and closes the database connection when the command completes.

Command syntax


>>-TAKEOVER HADR ON--+-DATABASE-+--database-alias--------------->
                     '-DB-------'                   

>--+--------------------------------------+--------------------->
   '-USER--user-name--+-----------------+-'   
                      '-USING--password-'     

>--+--------------------------------+--------------------------><
   '-BY FORCE--+------------------+-'   
               '-PEER WINDOW ONLY-'

Command parameters

DATABASE database-alias

Identifies the current HADR standby database that should take over as the HADR primary database.

USER user-name

Identifies the user name under which the takeover operation is to be started.

USING password: The password used to authenticate user-name.

BY FORCE

Specifies that the database will not wait for confirmation that the original HADR primary database has been shut down. This option is required if the HADR pair is not in peer state.

PEER WINDOW ONLY: When this option is specified, there will not be any committed transaction loss if the command succeeds and the primary database is brought down before the end of the peer window period (set the database configuration parameter HADR_PEER_WINDOW to a non-zero value). Not bringing down the primary database, before the peer window expires, will result in split brain. If the TAKEOVER BY FORCE PEER WINDOW ONLY command is executed when the HADR pair is not in a peer or disconnected peer state (the peer window has expired), an error is returned.
You cannot use the PEER WINDOW ONLY option when the synchronization mode is set to ASYNC or SUPERASYNC.

Note: The takeover operation with the PEER WINDOW ONLY option can behave incorrectly if the primary database clock and the standby database clock are not synchronized to within 5 seconds of each other. That is, the operation may succeed when it should fail, or fail when it should succeed. You should use a time synchronization service (e.g., NTP) to keep the clocks synchronized to the same source.

Usage notes

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: If the primary database remains active past the time when the peer window expires, and if the primary database still has no connection to the standby database, the primary database will move out of disconnected peer state and resume processing transactions independently. In NEARSYNC mode, if the standby database fails after acknowledging receipt of transaction logs from the primary database but before writing that transaction log information to disk, then that transaction log information, in the log receive buffer, might be lost.
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: If a failure occurs during a takeover operation, the roles of the HADR databases might or might not have been changed. If possible, make sure both databases are online. Check the HADR role of the available database or databases using the Snapshot Monitor, or by checking the value of the database configuration parameter hadr_db_role. If the intended new primary is still in standby role, and takeover is still desired, re-issue the TAKEOVER HADR command (see the next guideline regarding the BY FORCE option). It is possible to end up with both databases in standby role. In that case, the TAKEOVER HADR command with the BY FORCE option can be issued at whichever node should now become the primary. The BY FORCE option is required in this case because the two standbys cannot establish the usual HADR primary-standby connection.
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).