START HADR command

Authorization

One of the following authorities:

• 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

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

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

>--AS--+-PRIMARY--+----------+-+-------------------------------><
       |          '-BY FORCE-' |   
       '-STANDBY---------------'   

Command parameters

DATABASE database-alias

Identifies the database on which HADR operations are to start.

USER user-name

Identifies the user name under which the HADR operations are to be started.

USING password

The password used to authenticate user-name.

AS PRIMARY

Specifies that HADR primary operations are to be started on the database. If the primary database cannot connect to the HADR standby database within the time specified by the hadr_timeout database configuration parameter, the primary will not start.

BY FORCE

Specifies that the HADR primary database will not wait for the standby database to connect to it. After a start BY FORCE, the primary database will still accept valid connections from the standby database whenever the standby later becomes available. When BY FORCE is used, the database will perform crash recovery if necessary, regardless of the value of database configuration parameter autorestart. Other methods of starting a primary database (such as non-forced START HADR command, ACTIVATE DATABASE command, or client connection) will respect the autorestart setting.

Caution: Use the START HADR command with the AS PRIMARY BY FORCE option with caution. If the standby database has been changed to a primary and the original primary database is restarted by issuing the START HADR command with the AS PRIMARY BY FORCE option, both copies of your database will be operating independently as primaries. (This is sometimes referred to as split brain or dual primary.) In this case, each primary database can accept connections and perform transactions, and neither receives and replays the updates made by the other. As a result, the two copies of the database will become inconsistent with each other.

AS STANDBY

Specifies that HADR standby operations are to be started on the database. The standby database will attempt to connect to the HADR primary database until a connection is successfully established, or until the connection attempt is explicitly rejected by the primary. (The connection might be rejected by the primary database if an HADR configuration parameter is set incorrectly or if the database copies are inconsistent, both conditions for which continuing to retry the connection is not appropriate.)

Usage notes

The following table shows database behavior in various conditions:

Preferred replay member

In a DB2 pureScale environment, whichever member you issue the START HADR command on is designated as the preferred replay member. This member is the first choice for replaying logs on the HADR standby database (only one standby member replays logs generated on all primary members). For a member on the primary cluster, this designation is relevant only if the primary becomes a standby database. For a member on the standby cluster, this designation means that when the standby database starts, replay service attempts to start on this member. Although the preferred replay member status is persistent (that is, it remains until the next START HADR command), if replay has moved to another standby member, replay does not automatically revert back to the preferred replay member when that member is available.

If the START HADR command returns success, the preferred replay member is updated. If the START HADR command returns failure, the preferred member might or might not have been updated, depending on how far the command execution went. You can rerun the command to make sure. If a database is already active and in the desired role, the START HADR command is a nop (no operation performed). It returns an error and the preferred replay member is not updated. To redesignate the preferred replay member when a database is already online, use the procedure described in "Changing the preferred replay member".

Licensing errors

When the START HADR command is issued, 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.