
Fabian Tech Tips

SQL Database Mirror: Implementation, Monitoring, and Troubleshooting
Jan 24
10 min read
0
19
0
SQL Database Mirror: Implementation, Monitoring, and Troubleshooting
Database mirroring in SQL Server is a valuable tool for enhancing database availability and disaster recovery. By creating a synchronized copy of a database on a separate server instance, database mirroring ensures continuous operation even if the primary server fails 1. This article provides a comprehensive guide to implementing, monitoring, and troubleshooting SQL database mirroring.
Implementing Database Mirroring
Database mirroring involves creating a live, synchronized copy of a database on a separate SQL Server instance. This technology offers several benefits, including increased database availability, improved data protection, and enhanced availability during upgrades. In the event of a primary server failure, the mirror server can quickly take over, minimizing downtime 2.
Before implementing database mirroring, ensure the following prerequisites are met:
All participating servers (principal, mirror, and witness, if any) must be running the same version of SQL Server 3.
Both the principal server and mirror server must be running the same edition of SQL Server 3.
Both servers are connected and can communicate with each other 1.
The database to be mirrored uses the full recovery model 1.
Steps to Implement Database Mirroring
Prepare the Principal Database: Set the recovery model of the database to Full. This ensures that all database changes are logged, which is necessary for the mirroring process 1.
Backup the Principal Database: Create a full database backup and transaction log backup of the principal database. This backup serves as the base for the mirror database and allows for restoring the database to a consistent state 1.
Configure the Mirror Server: Ensure that the mirror server instance is ready to host the mirrored copy of the database. This includes ensuring sufficient disk space and network connectivity 1.
Restore the Principal Database Backup: Copy the full database backup and transaction log backup files to the mirror server and restore them using the WITH NORECOVERY option. This option keeps the mirror database in a restoring state, ready to receive and apply transaction log records from the principal database 1.
Set Up Database Mirroring: On the principal server, enable database mirroring and specify the mirror server. This establishes the mirroring session between the two server instances 1.
Start Database Mirroring: Start the mirroring session to begin synchronizing the databases. This initiates the process of transferring transaction log records from the principal to the mirror server 1.
Configuring Inbound and Outbound Connections
To ensure secure and reliable communication between the principal and mirror servers, you need to configure inbound and outbound connections. This involves creating certificates and endpoints on both servers and granting appropriate permissions 4.
Configure Outbound Connection for Principal Database
Create a certificate for the principal server database.
Create a mirroring endpoint.
Back up the principal server certificate and copy it to the mirror server.
Configure Outbound Connection for Mirror Database
Create a certificate on the mirror server.
Create a mirroring endpoint.
Back up the mirror server certificate and copy it to the principal server.
Configure Inbound Connections on Mirror Server
Set up a login on the mirror server for the principal server.
Create a user account for the principal server login.
Configure the certificate with the created user.
Grant connect permission to the created endpoint.
Ensure that the firewall allows inbound connections on the necessary ports.
Database SSL Configuration
For enhanced security, you can configure SSL encryption for database mirroring. This involves granting the SQL Server service account access to the certificate used for SSL encryption 5.
Operating Modes
SQL Server database mirroring offers different operating modes to suit various needs 4:
High Safety: This mode ensures data integrity by synchronizing every transaction between the principal and mirror databases. It offers the highest level of data protection but may impact performance due to the synchronous operation. In this mode, the mirror database is in a restoring state and is not accessible to applications 4.
High Safety with Automatic Failover: This mode requires a third server instance, called a witness, to monitor the principal and mirror servers. The witness enables automatic failover if the principal server fails. This mode combines high safety with increased availability.
High Performance: This mode prioritizes performance by using asynchronous operation. Transactions are committed on the principal server without waiting for the mirror server to write the log to disk. This mode is suitable for applications where speed is critical, but it may involve some data loss in case of a failover. In this mode, the mirror database can be accessed with some potential data loss 4.
It's important to choose the operating mode that best suits your needs, balancing data protection with performance requirements.
Read-Only Access to Mirror Database
Database mirroring allows you to create a snapshot on the mirror database and use it for read-only purposes. This can be a valuable feature for reporting requirements or other read-only operations, as it offloads read traffic from the principal database 6.
Restrictions
While database mirroring offers significant benefits, it's essential to be aware of its limitations:
Only user databases can be mirrored. You cannot mirror the master, msdb, tempdb, or model databases 3.
A mirrored database cannot be renamed during a database mirroring session 3.
Database mirroring does not support FILESTREAM. A FILESTREAM filegroup cannot be created on the principal server, and mirroring cannot be configured for a database that contains FILESTREAM filegroups 3.
Database mirroring is not supported with either cross-database transactions or distributed transactions 3.
Monitoring Database Mirroring
Monitoring the health and performance of a mirrored database is crucial to ensure high availability and data protection. SQL Server provides several tools and techniques for monitoring database mirroring:
Database Mirroring Monitor
Database Mirroring Monitor is a graphical user interface tool in SQL Server Management Studio (SSMS) that allows administrators to view the status of mirrored databases, including performance metrics and warning thresholds 7.
To launch the Database Mirroring Monitor:
Connect to the principal server instance in SSMS.
Expand Databases and select the database to be monitored.
Right-click the database, select Tasks, and then click Launch Database Mirroring Monitor.
SQL Diagnostic Manager
SQL Diagnostic Manager is another tool that can be used to monitor database mirroring. It provides a 'Databases' table that displays various information about mirrored databases, including:
Database Name
Server Instance
Current Role (principal or mirror)
Partner Instance
Mirroring State
Witness Connection
Operational State
Operating Mode
Performance metrics (e.g., unsent log, send rate, unrestored log) 8
System Stored Procedures
The sp_dbmmonitor system stored procedures provide a programmatic way to monitor database mirroring. These procedures allow administrators to:
Create a job that periodically updates the status information for every mirrored database on the server instance. (sp_dbmmonitoraddmonitoring) 9
Change the value of a database mirroring monitoring parameter. (sp_dbmmonitorchangemonitoring) 9
Return status rows for a monitored database. (sp_dbmmonitorresults) 9
Stop and delete the mirroring monitor job. (sp_dbmmonitordropmonitoring) 9
Database Mirroring Monitor Job
A database mirroring monitoring job, Database Mirroring Monitor Job, operates in the background to update mirroring status. SQL Server Agent calls this job at regular intervals (the default is once a minute) to collect and update status information 9.
Key Metrics to Monitor
When monitoring database mirroring, pay attention to the following key metrics:
Metric | Description | How to Monitor |
Unsent log | The amount of log waiting to be sent from the principal to the mirror server (in KB). | Database Mirroring Monitor, sp_dbmmonitorresults |
Unrestored log | The amount of log waiting to be restored on the mirror server (in KB). | Database Mirroring Monitor, sp_dbmmonitorresults |
Oldest unsent transaction | The age of the oldest unsent transaction in the send queue. | Database Mirroring Monitor, sp_dbmmonitorresults |
Mirror commit overhead | The average delay per transaction (in milliseconds) caused by waiting for the mirror server to write the log record. | Database Mirroring Monitor, sp_dbmmonitorresults |
Transaction delay | The average amount of time it takes for a transaction to be committed on the mirror server after being committed on the principal server. | SQL Diagnostic Manager |
Send rate | The rate at which the principal server is sending log to the mirror server (in KB per second). | SQL Diagnostic Manager |
Recovery rate | The rate at which the mirror server is applying log records (in KB per second). | SQL Diagnostic Manager |
Monitoring these metrics can help you identify potential issues, such as network latency, performance bottlenecks, or data loss, and take corrective action. It's also important to understand how much data was lost when the principal server becomes unavailable during high-performance mode, which can be determined by monitoring the amount of unsent transaction log 9.
Warning Thresholds
Database Mirroring Monitor allows you to configure warning thresholds for key performance metrics. If a metric exceeds its threshold, an informational event is sent to the Windows event log, alerting administrators to potential issues 10.
Troubleshooting Database Mirroring
Troubleshooting database mirroring involves identifying and resolving issues that may arise during setup, configuration, or operation. Here are some common issues and troubleshooting steps:
Types of Failures
Failures in a database mirroring session can be categorized into two types 11:
Hard Errors: These are errors reported by underlying components, such as network failures, hardware failures, or operating system issues.
Soft Errors: These are errors detected by the database mirroring time-out mechanism, such as network timeouts or resource issues.
Common Issues and Troubleshooting Steps
Error Message 1418: This error indicates that the server network address cannot be reached or does not exist. Verify the network address name and ensure network connectivity 12.
Account Issues: Ensure that the accounts under which SQL Server is running have the correct permissions. If the accounts are in different domains, create a login for one account on the other server and grant CONNECT permissions on the endpoint 12.
Endpoint Issues: Verify that the endpoints are correctly configured on all participating servers. Check the port numbers, ensure the endpoints are started (STATE=STARTED), and verify that the ROLE is correct. Also, ensure that the login for the service account from the other server instance has CONNECT permission on the endpoint 12.
Network Access: Ensure that each server instance can access the ports of the other server instances over TCP. Use the netstat command-line utility to display all the ports on which a server is listening and identify any connectivity issues 13.
Mirror Database Preparation: Ensure that the mirror database is restored with the WITH NORECOVERY option and that all log backups have been applied 12.
Failed Create-File Operation: If a create-file operation fails, remove the mirroring session, restore a full backup of the affected filegroup, and manually restore the log backup on the mirror database using the WITH NORECOVERY and WITH MOVE options 12.
Starting Mirroring with Transact-SQL: When using Transact-SQL to start mirroring, ensure that the ALTER DATABASE database_name SET PARTNER ='partner_server' statements are issued in the correct order. The first statement must be run on the mirror server 12.
Cross-Database Transactions: