Failover procedure

Failover refers to the process of switching normal system operations from a primary database to a standby database, particularly in the event of a failure that interrupts:

Operations at the primary database, or
Access to the primary database.

You can also use a failover procedure to mitigate the impact of scheduled downtime on database users and clients (for example, when maintenance operations require the primary database to be offline).

This section describes only the failover tasks that are specific to the Mirror Activator system. General system failover procedures are not covered in this document.

The failover procedure described in this section does not use the Replication Server warm standby switch active feature. For information about switching the active and standby databases in a warm standby application, see the Replication Server Administration Guide.

Table B-1 provides a checklist of the tasks that you must include in failover procedures for the Mirror Activator system.

The checklist in Table B-1 assumes that:

The primary database has gone offline, triggering the failover procedure to begin.

To provide recovery from a standby database failure, you will use the disk replication system to capture and mirror all changes on the standby database devices while the primary database is offline.

Sybase recommends that you perform these tasks in the order shown.

**Table B-1: Mirror Activator system failover tasks**
Task	Description
1	Verify that the Mirror Replication Agent has finished processing the last transaction record in the log, and then stop replication in the Mirror Replication Agent.
2	Verify that the Replication Server has distributed the last committed transaction in the log.
3	Check the Replication Server stable queue for open transactions. Before failback, you must purge any open transactions that remain in the Replication Server stable queue.
4	Failover the disk replication system to: Treat the standby database data and log devices as “primary” devices. Mirror all subsequent changes on the standby database data and log devices to another set of standby (or backup) devices.
5	Switch access for users and client applications from the primary database to the standby database.

Use the following procedure for Mirror Activator system failover tasks.

Verify that the Mirror Replication Agent has finished processing all transactions in the log, and then stop replication in the Mirror Replication Agent:

Log in to the Mirror Replication Agent administration port and execute the following command:
```
quiesce
```
The quiesce command completes once the Mirror Replication Agent has reached the end of the Primary database transaction log, and all generated LTL commands are sent to Replication Server.

The following output indicates that Mirror Replication Agent has reached the Admin state:
```
State  Action
-----  ------------------------------
ADMIN  Waiting for operator command.
```

See “Stopping replication in the Mirror Replication Agent” and “Determining current Mirror Replication Agent status”.

Check the Replication Server stable queue for open transactions.

admin who, sqt

Check the admin who, sqt output for the SQT thread associated with the standby database connection. The following column values indicate that all committed transactions have been distributed successfully, and that open (uncommitted) transactions remain in the stable queue:

Closed – 0
Open – (any number other than zero)
SQM Blocked – 1
First Trans – STO

Before failback, you must purge any open transactions that remain in the Replication Server stable queue.

For more information about the admin who command, see the Replication Server Reference Manual.

sysadmin hibernate_on
sysadmin sqm_purge_queue, qnum, qtype
sysadmin hibernate_off

Fail over the disk replication system.

Reconfigure the disk replication system to:

Treat the standby database data and log devices as “primary” (source) devices
Mirror all subsequent changes on the standby database data and log devices to another set of standby (backup) devices, preferably at an alternate site (neither the primary nor standby site)

Refer to the documentation provided by your disk replication system vendor for more information about the procedures in this step.

After you complete all of the previous tasks, you can switch access for users and client applications from the primary database to the standby database.