1.

Introduction

Database mirroring is a new SQL Server 2005 technology available for review for increasing database availability. Database mirroring transfers transaction log records directly from one server to another and can quickly fail over to the standby server. You can code client applications to automatically redirect their connection information, and in the event of a failover, automatically connect to the standby server and database. Fast failover with minimal data loss has traditionally involved higher hardware cost and greater software complexity. Database mirroring, however, can fail over quickly with no loss of committed data, does not require proprietary hardware, and is easy to set up and manage. It also provides many features that previous options such as Transactional Replication, Clustering and Log Shipping did not provide. However it is not necessarily best in all situations and many times the best alternative is to mix more than one High Availability option, such as Clustering and Database Mirroring. For example, Clustering could be used to handle local failure, while Database Mirroring is used to maintain a geographically separate and hot copy of database.

Page | 7

2. Database Mirroring Overview

In database mirroring, an originating SQL Server 2005 instance continuously sends a database's transaction log records to a copy of the database on another standby SQL Server instance. The originating database and server have the role of principal, and the receiving database and server have the role of mirror. The principal and mirror servers must be separate instances of SQL Server 2005. It means database mirroring works by maintaining 2 copies of single database. One copy (Principal) is usable just like any other database and second copy (Mirror, residing on different SQL Server Instance) is in a state where it is constantly receiving changes from Principal and applying them locally. In all SQL Server databases, data changes are recorded in the transaction log before any changes to actual data pages are made. The transaction log records are placed first in a database's log buffer in memory, and then flushed to disk (or 'hardened') as quickly as possible. In database mirroring, as the principal server writes the principal database's log buffer to disk, it simultaneously sends that block of log records to the mirror instance. When the mirror server receives a block of log records, it places the log records first into the mirror database's log buffer and then hardens them to disk as quickly as possible. Those transaction log records are later replayed on the mirror. Because the mirror database replays the principal's transaction log records, it duplicates the database changes on the principal database. 2.1 Partner The partner role defines that a server will be participating as either a Principal or Mirror for the specified Mirroring session. The principal and mirror servers are each considered a partner in the database mirroring session. A database mirroring session consists of a relationship between the partner servers when they mirror a database from one partner to another. A given partner server may have the principal role for one database and a mirror role for a different database. There is no role that can be defined that specifies that a given machine will be Principal or Mirror for the session.

2.2 Principal

Page | 8

The Principal role may be thought of the source in the mirrored pair. In a Database Mirroring session Principal Server is the instance of SQL Server that is hosting the Principal Database.

2.3 Mirror The Mirror role can be thought of as the destination in mirrored pair. During a Database Mirroring session the Principal sends copies of transactions to the Mirror (Async or Sync) to be applied there. This results in the Mirror maintaining an exact copy of the Principal Database that is transactional consistent. Additionally, since the Mirror is applying the same transactions as the Principal, the cache on the Mirror ends up being a close representation of the Principals cache, along the lines of a warm cache. Also, Database Mirroring sends read Metadata along with the transactions that tell the Mirror what data to cache that is related to reads, thereby making the warm cache on the Mirror hot. So, upon failover, there is not a sudden drop in performance while the cache is warmed. 2.4 Witness The Witness Defined role is used by Database Mirroring to facilitate Automatic failover by helping to establish a quorum. Whichever partner can still see the Witness after a failure has occurred (usually a network issue in this case) will take on the role of Principal and the isolated server would cease to serve the database. The witness server's role is to enable automatic failover. When database mirroring is used for high availability, if a principal server suddenly fails, if the mirror server has confirmation from the witness, it can automatically take on the role of principal and make its database available within a few seconds.

Page | 9

3. Operating Modes
There are three possible operating modes for a database mirroring session. The exact mode is based on the setting of transaction safety and whether a witness server is part of the mirroring session. 3.1Other terms Before beginning of reviewing the operating modes, there are a few terms that need to be understood. 3.1.1 Send Queue

The Send Queue shows how many Kbytes of SQL Log data is pending to be sent from the Principal to the Mirror. The Send Queue is integrated with the databases transaction log therefore, no additional space is required. Effectively, there is a marker on each transaction in the transaction log that tells whether or not that transaction has been sent to the Mirror. Those transactions that are marked as not having been sent are what are considered to be the Send Queue. The size of the Send Queue is indicative of the lag from the Principal to the Mirror and is used to determine the Recovery Point.
3.1.2 Redo Queue

The Redo Queue is the set of transactions that have been sent to the Mirror by the Principal and hardened to the Mirrors transaction log, but have not actually modified the data pages yet. After a transaction is hardened to the Mirrors log, it is then considered to be in the Redo Queue. The Mirror is in a constant state of recovery (the Redo phase of recovery) and is constantly rolling forward any transactions that end up in the Redo Queue. Once the transaction is rolled forward, it is removed from the queue. The size Redo Queue is indicative of how long it will take for the database to be available once a failover has occurred and is used to determine the Recovery Time.

Page | 10

Figure1: This diagram is from SQL Server 2005 Book Online, it demonstrates the. Time line for a Database Mirroring

Table 1: Database Mirroring Operating Modes: Operating Mode High Availability High Protection High Performance Transaction safety FULL FULL OFF Transfer mechanism Synchronous Synchronous Asynchronous Quorum required Y Y N Witness server Y N N/A Failover Type Automatic or Manual Manual only Forced only

If safety is FULL and a witness is set, synchronous data transfer will occur, and a quorum is required for database service. A quorum vote requires at least two servers to decide which role, principal or mirror, each of the two partner servers should play. In order to explore the three operating modes in more detail, let's first take a closer look at transaction safety and the role of a quorum. 3.2 Transaction Safety

If transaction safety (or just 'safety') is set to FULL, the principal and mirror servers operate in a synchronous transfer mode. As the principal server hardens its principal database log records to disk, it also sends them to the mirror. The principal then waits for a response from the mirror server. The mirror responds when it has hardened those same log records to the mirror's log disk. When safety is set OFF, the principal does not wait for acknowledgment from the mirror, and so the principal and mirror may not be fully synchronized. (That is, the mirror may not quite keep up with the principal).

Page | 11

Synchronous transfer guarantees that all transactions in the mirror database's transaction log will be synchronized with the principal database's transaction log, and so the transactions are considered safely transferred. You set safety to FULL using ALTER DATABASE [<dbname>] SET SAFETY FULL; When safety is set to OFF, the communication between the principal and the mirror is asynchronous. The principal server will not wait for an acknowledgment from the mirror that the mirror has hardened a block of transaction records. The mirror will attempt to keep up with the principal, by recording transactions as quickly as possible, but some transactions may be lost if the principal suddenly fails and you force the mirror into service.

3.3

The Quorum and the Witness Server

When the witness server is set, a database mirroring session requires a quorum to keep a database in service. A quorum is the minimal relationship among all the connected servers required by a synchronous database mirroring session. Because at least two servers are required for a quorum, when the witness is set the principal server must form a quorum with at least one other server to keep the database in service, regardless of the safety setting. Normally, if a witness is set, then the safety level is set to FULL as well. The witness server assists the principal or mirror in forming a quorum. If a witness server is present, a loss of either the principal database or the mirror database leaves two servers to form a quorum. If the principal cannot see the mirror server, but it can form a quorum with the witness, it can keep its database in service. Similarly, if the mirror and witness servers cannot see the principal server, and the mirror server can form a quorum with the witness, the mirror can take on the role of a new principal server. The witness is not considered a single point of failure in a database mirroring session, because if the witness server fails, the principal and mirror continue to form a quorum. 3.4High Protection A database mirroring session is in High Protection mode if its Transaction Safety is set to FULL. This places the session into Synchronous mode, which means that a transaction is not complete until it has
Page | 12

been completed at both the Principal and the Mirror. In High Protection mode there is no Witness server participating in the Mirroring session, therefore there is only manual failover available. When a transaction is submitted to the Principal it is simultaneously sent to the Mirror and it is not considered committed until the Mirror acknowledges that it has been written to the transaction log on the Mirror. Then the Principal informs the client that the transaction was committed. When in High Protection mode, the Mirror always has all transactions recorded in its transaction log, but it is not guaranteed that the data pages of the Mirror have been altered. When the Principal is under heavy load, it is possible and even likely that the Mirror will begin to build up a Redo Queue, which can increase the time for a failover to occur.

3.5High Availability High Availability is the same as High Protection, except for adding a Witness server. Adding the Witness server gives the Mirroring session the ability to perform automatic failover, because of the creation of a quorum. Without the Witness server, if a communications failure between the Principal and Mirror were to occur, it is possible that they could both become the Principal and both could end up receiving different transactions, thus causing a condition known as split-brain syndrome. This would cause the databases to diverge and remove the possibility of reestablishing the mirror without substantial manual effort and possible data loss. In High Availability mode, if the Principal fails, the Mirror and Witness establish a quorum and promote the Mirror to the Principal role. If there were a network issue near the Principal, then the Principal (no longer able to see the Witness and Mirror) would take itself off-line to prevent split brain. Effectively, which ever partner can still see the Witness will be the Principal. This does not mean the Witness is a single point of failure.

3.6High Performance When in High Performance mode, the transactions are sent to the Mirror asynchronously, meaning that the Principal does not wait for the transaction to be received by the Mirror before considering it committed. As soon as the transaction is hardened to the Principals log, it is considered committed.

Page | 13

Once the transaction is hardened to the log, it is also in the Send Queue and will be sent to the Mirror as resources allow.

Page | 14

4. How to start a mirroring session

To start a Mirroring session there are several steps that must be completed. 4.1Backup / Restore To prepare for the Database Mirroring session, the database that will end up being the Mirror needs to be brought to a point that is transactionaly close to the Principal. It does not have to be to the exact point, but the closer it is, the quicker the mirror will get to the synchronized state.
For a database that is relatively small and has a maintenance window during which a full backup

can be gotten to the Mirror server and restored, this step is rather straightforward. All that would need to be done would be for the Principal database to have a full backup done, shipped to the mirror, and then it would be restored on the mirror with the No Recovery option. This will leave the database that is to become the Mirror in the recovery state that it needs to be in.
If the database is larger and/or does not have a maintenance window then other techniques may

need to be used. For example, a full database backup to an external hard drive(s) shipped to the mirror location, and log backups being transferred, until the Mirror is ready. The database could be restored to the Mirror instance, and then the transaction logs applied, in order, until the Mirror database was within one log backup of the Principal. Then the mirroring session could be started and the Mirror would begin synchronizing with the Principal. The requirement is that the transactions that are missing from the Mirror must still be in the Principals transaction log, otherwise there will be a gap and the initialization of the Mirroring session will fail.

Both way, before, during, or after the restore, the communications paths for the Partners and Witness will need to be defined and they are called endpoints.

4.2Creating end points Endpoints are used to define how the servers will communicate with each other. Database Mirroring endpoints use TCP to send and receive messages between server instances in database mirroring sessions. If there are an existing set of Database Mirroring endpoints that will work for the new
Page | 15

Database Mirroring session, then they may be used, otherwise new endpoints will need to be created. A single endpoint may be used for multiple mirroring sessions. The endpoint defines the TCP port that will be used, the type of authentication, the type of encryption (None, RC4, or AES) for communications, and the role of the server.

An endpoint is created with the CREATE ENDPOINT command in TSQL or it can be created

through the GUI as part of establishing a Database Mirroring session.

Additionally, the service account that the SQL Server instance is running under on each server (Principal, Mirror, and Witness) will need to be granted permission to connect to the endpoints on the other server. If all of the Instances are running under the same domain account, then no privilege granting is necessary. Also, if the SQL Servers are not in a single domain or not in trusted domains and running under domain accounts, the Certificate Authentication will need to be used. 4.3Synchronizing the Mirror To initialize the Database Mirroring session, the ALTER DATABASE command is used. First the command is run on the soon to be Mirror Server to alter the database in recovery mode and tell it who its Partner will be. When specifying the network name of the Partner, the fully qualified TCP address must be used in the form of: TCP: //fully_qualified_domain_name:port. This is because there is no assumed port for Database Mirroring; therefore the port must always be specified. Additionally, although the documentation says that a fully qualified domain address must be used; internal testing has shown that an IP address followed by a port will also work, in the form of: TCP://###.###.###.###:port. Once the ALTER DATABASE command has been issued on the Mirror, the ALTER DATABASE command is issued on the Principal. Once the ALTER DATABASE command is issued on the Principal, a High Protection Database Mirroring session is started with a status of Synchronizing. If the intent is to establish a High Protection mode session, then the necessary settings are complete. If the mode is intended to be either High Availability or High Performance, then other commands will need to be issued.

Page | 16

4.4Adjustments

To adjust the Database Mirroring session from High Protection to High Availability a Witness must be added. Again, this is done by issuing the ALTER DATABASE command. Once a Witness is added the mode automatically changes from High Protection to High Availability.

To adjust the Database Mirroring session from High Protection to High Performance, the transaction Safety must be set to OFF. Again, this is done by issuing the ALTER DATABASE command. Once the Safety is set to OFF the mode automatically changes from High Protection to High Performance.

To adjust the Database Mirroring session from High Availability to High Performance, the transaction Safety must be set to OFF. However, it is recommended that the Witness be removed first, thereby returning the session to High Protection, before changing the transaction Safety. Again, this is done by issuing the ALTER DATABASE command. Once the Safety is set to OFF the mode automatically changes from High Availability or High Protection to High Performance.

Page | 17

5. Database Mirroring Availability Scenarios

In this section you'll explore the expected availability outcomes of database mirroring scenarios based on the following two types of events:

One or more servers or databases are down. One or more communication lines between servers are broken.

A server loss could occur when either one of the partner databases, or one of the SQL Server instances, become unavailable. Alternately, the lines of communication between the database mirroring partner servers may be interrupted, even though the servers themselves continue to operate. The following scenarios consider simultaneous failures of two components as a sequential failure of one component followed by another. For example, if Servers A and B appears to fail simultaneously, the mirroring system will treat that event as a sequence: Server A followed by Server B, or vice versa. You can use the following rules to determine the expected results of an unavailability event:
1. When a witness has been set, the principal server requires a quorum with at least one

other server to keep its database in service. If a principal cannot form a quorum, it can no longer serve the database. 2. When safety is FULL, if neither the mirror nor the witness can see the principal, the mirror server can form a quorum with the witness and change its role to become a new principal server, assuming a the mirroring session was SYNCHRONIZED when the principal went away. This is an automatic failover.
3. When safety is FULL, if the principal has done work while in quorum with the witness

but disconnected from the mirror, a principal failure will not allow the mirror to form a quorum with the witness and take on the role of a new principal server. This prevents work being lost by the session.

Page | 18

4. When safety is FULL, if a failed principal server rejoins a session after being down or

isolated, and the old mirror has previously taken on the role of new principal (in quorum with the witness), the old principal will take on the role of new mirror in the session. During the failover event, the mirror and the witness incremented the mirroring role sequence counter. Because the old principal's mirroring role sequence counter is less than that on the other partner server and the witness server, those two servers have formed a quorum before the old principal rejoined the session, and new work may have occurred on the new principal. The old principal takes on the mirror role in the session.
5. When a witness has been set, the principal requires a quorum to serve the database. If the

witness has not been set (the status of the sys.database_mirroring column mirroring_witness_name is NULL), then a quorum is not required by the principal to serve the database. No witness means that no automatic failover can occur. If there is no automatic failover, there is never a problem with split brain, and the principal does not need to contact another server to form a quorum. 5.1 High Protection Scenarios

The High Protection operating mode works with safety FULL, but with no witness. Because only a server with a principal database and a server with a mirror database are involved, there is only one line of communication between them. This dramatically reduces the number of scenarios. Case1: In the High Protection operating mode, only two SQL Server instances are involved, the principal and the mirror. Because there is no witness, automatic failover is not possible. There is only one communication line between the servers, and it can be interrupted, resulting in the configuration illustrated in Figure 2.

Figure 2: When communication is interrupted in a High Protection scenario, both partners become disconnected but the principal still serves the database.

Page | 19

Because a witness has not been set, the principal does not need a quorum with the mirror, the principal serves the database as normal. Case2: If the mirror database becomes unavailable in a High Protection scenario, the principal is the same as in the above scenario, as shown in Figure 3.

Figure 3: If the mirror server is unavailable in a High Protection scenario, the principal database is unaffected.

Case3: If the principal database becomes unavailable in a High Protection scenario, the mirror database must remain a mirror, but it will be in a disconnected state, as shown in Figure 4.

Figure 4: If the principal becomes unavailable in High Protection, the mirror database will enter a disconnected state.

Because the High Protection operating mode does not have a witness set, disruptions do not cause the principal database to become unavailable, and the mirror database remains in a recovering state. 5.2 High Performance Scenarios The High Performance operating mode works with safety OFF. No role is played by a witness server. Only a server with a principal database and a server with a mirror database are involved, and there is only one line of communication between them. Case1: In the High Performance operating mode, two SQL Server instances are involved. One houses the principal database and the other contains the mirror database. Therefore there is only one communication line between the servers, and it can be interrupted, resulting in the configuration illustrated in Figure 5.
Page | 20

Figure 5: When communication is interrupted in a High Performance scenario, both partners become disconnected but the principal database remains available.

Because no witness has been set, Server A does not require a quorum to keep its database available. Therefore the principal, though disconnected, continues to accept user activity. If you restore communication, the mirror database will attempt to catch up but may not be able to, or may be subject to redo errors if it cannot retrieve all the missing transactions. Case2: If the mirror database becomes unavailable in a High Performance scenario, the result for the principal is shown in Figure 6.

Figure 6: If the mirror server is unavailable in a High Performance scenario, the principal database is unaffected.

The principal database remains available because safety is OFF. Case3: If the principal database becomes unavailable in a High Protection scenario, the mirror database remains a mirror, but it will be disconnected, as shown above in Figure 7.

Figure 7: If the principal becomes unavailable, Server B is unaffected but enters a disconnected state.

Page | 21

In the High Performance operating mode, just as in High Protection, no automatic failover is possible. Because no witness has been set, the principal server keeps its database available when the mirror becomes unavailable. Also because safety is OFF, transactions are not guaranteed to reach the mirror. Some transactions may be lost if you force a failover to the mirror. It is not recommended to run with the safety OFF and a witness set. The witness cannot provide automatic failover, because the safety is not FULL. Furthermore, if the witness and the mirror are unavailable, then the principal has lost quorum and brings its copy of the database offline.

Page | 22

6. Safety vs. Performance

Database mirroring performance is a function of the type of activity and the transactional safety setting. The performance of the principal server is affected by the transfer of log records to the mirror. The overhead that database mirroring places on a principal server is a function of the type of activity. Database mirroring will perform best with many long transactions by many users, because the normal transactional activity of the database server will mask the overhead of transferring log records to the mirror. When a single user is issuing a large number of small transactions in sequence, the overhead of database mirroring for each transaction will become more prominent. Performance of the principal server will also be affected by the Safety setting. When safety is FULL, the principal must wait for an acknowledgment by the mirror that it has received log records before it can issue a transaction commit message back to the client. With many users and long transactions, that overhead will be inconsequential. Systems with single threads and many small transactions may operate better with safety OFF. Because the mirror server is continuously replaying data modification transactions that it receives from the principal, the data cache on the mirror server will be 'hot'. In other words, the data cache will be populated with data and index pages based on the same kinds of changes made on the principal. To make the mirror cache even more like the principal's cache, database mirroring also passes SELECT hints to the mirror so that the cache used for querying data also is reproduced on the mirror server. This will aid in making the mirror more like the principal and will reduce the remaining redo time in the case of a failover. Obviously, any additional activity on the mirror server, including queries against database snapshots, will affect the state of the cache and could increase the duration of time to finish the redo phase in the event of a failover.

Page | 23

7. Testing Database Mirroring

When setting up your own systems to test database mirroring, you have a number of options available. All mirroring requires is that the servers in the database mirroring session must be distinct SQL Server instances. Therefore you can learn about and test database mirroring on a single physical server, if you install multiple instances of SQL Server 2005's relational engine. You can also test multiple instances in a single virtual server, but your tests will be more reliable if done on a physical server. When testing database mirroring for load or stress purposes, you will need distinct physical servers. Two or three instances on a single server may consume an unrealistic share of the physical server's resources. Equally important is good connectivity between servers. The better the network connection between the principal and the mirror, the better the transfer rates for log records and messages will be. The most realistic testing will be on the actual target servers or on a test bed that has the same physical properties as your final system. When you test with multiple instances on a single server, you can only simulate the effects of server loss on database mirroring, by stopping one of the instances or shutting down a machine. With multiple physical servers, you can also test the loss of connectivity by disconnecting a network cable. The following practices may assist you in creating test conditions:

To test a server failure, just shut down the SQL Server instance, either through SQL Configuration Manager or using SHUTDOWN WITH NOWAIT. To test a communication failure, remove a network cable from the server. To test a database failure, stop the SQL Server service and rename the underlying .mdf file, and then restart the SQL Server. To cause a redo error on the mirror, add a file to the principal database on a driver volume that does not exist on the mirror server. To force a database shutdown on the principal, force the principal's data file to run out disk space. To cause a log buffer hardening to fail on the principal or mirror, force the log file to run out of disk space.

8.

Conclusion

Page | 24

Database mirroring is a new SQL Server 2005 technology that can deliver high availability and high performance solutions for database redundancy. In database mirroring, transaction log records are sent directly from a principal to a mirror database whenever the principal's transaction log buffer is written to disk (hardened). This technique can keep the mirror database nearly up to date with the principal, and with no loss of committed data. In the High Availability operating mode, if the principal fails, the mirror server will automatically become a new principal and recover its database. Using the new ADO.NET or SQL Native Access Client drivers, applications can also perform an automatic failover from the client servers as well. Database mirroring becomes an important new option in the array of high availability technologies supported by SQL Server 2005.

Page | 25

9. References
The following resources were used in writing this guide and should be read for additional information: 1) SQL Server 2005 Books Online 2) White papers 3) Database Mirroring in SQL Server 2005 by Ron Talmage 4) Database Mirroring Best Practices and Performance Considerations by Sanjay Mishra 5) sqlskills.com\blogs\

Page | 26