Asynchronous Database Mirroring (High-Performance Mode)
When transaction safety is set to OFF, the database mirroring session operates asynchronously. Asynchronous operation supports only one operating mode—high-performance mode. This mode enhances performance at the expense of high availability. High-performance mode uses just the principal server and the mirror server. Problems on the mirror server never impact the principal server. On the loss of the principal server, the mirror database is marked DISCONNECTED but is available as a warm standby.
High-performance mode, supports only one form of role switching: forced service (with possible data loss), which uses the mirror server as a warm standby server. Forced service is one of the possible responses to the failure of the principal server. Because data loss is possible, you should consider other alternatives before forcing service to the mirror. For more information, see "Responding to Failure of the Principal," later in this topic.
The following figure shows the configuration of a session using high-performance mode.
.gif "Partner-only configuration of a session")
In high-performance mode, as soon as the principal server sends the log for a transaction to the mirror server, the principal server sends a confirmation to the client, without waiting for an acknowledgement from the mirror server. Transactions commit without waiting for the mirror server to write the log to disk. Asynchronous operation permits the principal server to run with minimum transaction latency.
The mirror server attempts to keep up with the log records sent by the principal server. But the mirror database might lag somewhat behind the principal database, though typically the gap between the databases is small. However, the gap can become substantial if the principal server is under a heavy work load or the system of the mirror server is over loaded.
When Is High-Performance Mode Appropriate?
High-performance mode can be useful in a disaster-recovery scenario in which the principal and mirror servers are separated by a significant distance and where you do not want small errors to impact the principal server.
Note
Log shipping can be a supplement to database mirroring and is a favorable alternative to asynchronous database mirroring. For information about the advantages of log shipping, see Configuring High Availability. For information on using log shipping with database mirroring, see Database Mirroring and Log Shipping.
The Impact of a Witness on High-Performance Mode
If you use Transact-SQL to configure high-performance mode, whenever the SAFETY property is set to OFF, we strongly recommend that the WITNESS property also be set to OFF. A witness can coexist with high-performance mode, but the witness provides no benefit and introduces risk.
If the witness is disconnected from the session when either partner goes down, the database becomes unavailable. This is because, even though high-performance mode does not require a witness, if one is set, the session requires a quorum consisting of two or more server instances. If the session loses quorum, it cannot serve the database.
When a witness is set in a high-performance mode session, the enforcement of quorum means that:
- If the mirror server is lost, the principal server must be connected to the witness. Otherwise, the principal server takes its database offline until either the witness or mirror server rejoins the session.
- If the principal server is lost, forcing service to the mirror server requires that the mirror server be connected to the witness.
Note
For information about the types of quorums, see Quorum: How a Witness Affects Database Availability.
Responding to Failure of the Principal
When the principal fails, the database owner has several choices, as follows:
Leave the database unavailable until the principal becomes available again.
If the principal database and its transaction log are intact, this choice preserves all of the committed transactions at the expense of availability.Stop the database mirroring session, manually update the database, and then begin a new database mirroring session.
If the principal database is lost but the principal server is still running, immediately attempt to back up the tail of the log on the principal database. If the tail-log backup succeeds, removing mirroring may be your best alternative. After removing mirroring, you can restore the log onto the former mirror database, which preserves all of the data.Note
If the tail-log backup failed and you cannot wait for the principal server to recover, consider forcing service, which has the advantage of maintaining the session state.
Force service (with possible data loss) on the mirror server.
Forced service is strictly a disaster recovery method and should be used sparingly. Forcing service is possible only if the principal server is down, the session is asynchronous (transaction safety is set to OFF), and either the session does not have any witness (the WITNESS property is set to OFF) or the witness is connected to the mirror server (that is, they have quorum).
Forcing service causes the mirror server to assume the role of principal and serve its copy of the database for clients. When service is forced, whatever transaction logs the principal has not yet sent to the mirror server are lost. Therefore, you should limit forced service to situations where possible data loss is acceptable and immediate database availability is critical. For information on how forced service works and on best practices for using it, see Forced Service (with Possible Data Loss).
See Also
Concepts
Forced Service (with Possible Data Loss)
Synchronous Database Mirroring (High-Safety Mode)
Transact-SQL Settings and Database Mirroring Operating Modes
Understanding Log Shipping