By: Jay Dave | Updated: 2007-07-06 | Comments | Related: 1 | 2 | 3 | 4 | > Database Mirroring
Problem
In an earlier tip (Login failures connecting to new principal after failover using Database Mirroring) you mentioned using Database Mirroring as one of the native SQL Server high availability\disaster recovery\fault tolerant solutions. I am interested in learning more about this technology to see if it is something that I can use in my environment. Getting background information on the technology would be a good place for me to start. In addition, understanding how and when it can be used would be helpful. Where should I begin?
Solution
For a successful implementation of Database Mirroring two or three instances of SQL Server 2005 need to be installed or leverage the existing infrastructure. The databases must be in full recovery model for the each database to participate in database mirroring session. Many applications use of multiple databases on a single server. Or one application may reference multiple databases. However, database mirroring works with a single database at a time. As such, you need to take this into account when designing mirroring into your database architecture.
Server Roles
The Database Mirroring architecture components as show above are comprised of two mandatory server roles and an optional third server role. The two mandatory roles are the Principal Role and the Mirror Role these roles would be installed on the Enterprise and Standard editions of SQL Server 2005. The third and optional role is the Witness role. The function of this SQL Server 2005 instance is to act as an arbiter to determine which SQL Server instance should be fulfilling the Principal or Mirror role. For the Witness role SQL Server 2005 Enterprise, Standard, Workgroup or Express Edition are possible candidates to support the witness role.
To find out more information about the Principal Role and the Mirror Role, each of the participating SQL Servers stores metadata about the session and the current state of the databases in the sys.database_mirroring catalog view. The witness server metadata is returned using the sys.database_mirroring_witnesses catalog view.
Operating Modes
Database Mirroring is configured for three different operating modes. These modes are high availability, high performance and high protection. Each offers a different set of functionality and must be understood in order to select the appropriate configurations.
- High Availability Operating Mode
- The High Availability Operating Mode provides durable, synchronous transfer of data between the principal and mirror instances including automatic failure detection and failover. With this functionality comes a performance hit. This is because a transaction is not considered committed until SQL Server has successfully committed it to the transaction log on both the principal and the mirror database. As the distance between the principal and the mirror increases, the performance impact also increases.
- In addition, there is an continuous ping process between all three nodes (if a witness is used) to detect failover. If witness server is not visible from the mirror, you must either reconfigure the operating mode for the database mirroring session or turn off the witness. Alternatively, you can manually fail over a database mirroring session at the mirror in High Availability Mode by issuing the ALTER DATABASE SET PARTNER FAILOVER command at the principal. The same command can also be issued if you have to take principal down for maintenance.
- High Performance Operating Mode
- With the High Performance Operating Mode the overall architecture acts as a warm standby and does not support automatic failure detection or failover. The data transfer between the principal and mirror instances is asynchronous. As such, this mode provides better performance and permits geographic separate between the principal and mirror SQL Server instances. Unfortunately, this mode increases latency and can lead to greater data loss in the event of primary database failure if it is not managed properly.
- High Protection Operating Mode
- The High Protection Operating Mode operates very similar to the High Availability Mode except the failover and promotion (mirror to principal) process is manual. With this mode the data transfer is synchronous. This mode is typically not recommended except in the event of replacing the existing witness SQL Server. After replacing or recovering the witness SQL Server, the operating mode should be changed back to High Availability Operating Mode.
Additional Considerations
- Initial Synchronization - Before starting the mirroring session make sure each mirrored database is initialized and then synchronized with the Principal This means that the last known full backup of principal database and any transaction log backups need to be restored to the mirrored server with the NORECOVERY option. The NORECOVERY option maintains the mirrored database in a recovering state and does not allow any user connections.
- Additional Objects - Independent from the database mirroring process, you need to separately transfer the following objects, if applicable:
- Logins
- SQL Agent Jobs, Alerts and Operators
- SQL Server Integration Services Packages
- Support databases
- Linked Server Definitions
- Backup devices
- Maintenance plans
- SQL Mail or Database Mail settings
- Distributed Transaction Coordinator settings
- etc.
Next Steps
- Database mirroring can be setup (How to: Configure a Database Mirroring Session (SQL Server Management Studio)) in a development or test environment without much of an impact since it operates at a per database level. You can issue transactions with a test version of your business application to see how it reacts and review how quickly the data is replicated.
- If you are looking into SQL Server high availability\disaster recovery\fault tolerant solutions, the look into the following as well:
- Backup and Recovery
- Full or Differential
- Log Shipping
- Full and/or Differential and Transaction Logs
- Replication
- Snapshot, Transaction, Merge, Peer to Peer
- Clustering
- Dual or quad node
- Third party solutions
- Microsoft DPM Solution
- Backup and Recovery
- Special thanks to Jay Dave of the MSSQLTips.com community for contributing this tip!
About the author
Jay Dave has over 10 years of experience in the IT industry working as a trainer, software developer, etc.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
Article Last Updated: 2007-07-06
