DATABASE MIRRORING  Mirroring is mainly implemented for increasing the database availability.  Is configured on a Database level.  Mainly involves two or three servers depending upon the mode in which mirroring is configured.  This is among the best Disaster Recovery techniques providing database availability and automatic failover mechanisms.

Mirroring Terminology:  Principal  Mirror  Mirrored Pair  Witness  Quorum  End Point Endpoint is the method by which the Principal communicates with the Mirror. The mirror listens on a port defined in the endpoint. The default is Each database mirror pair listens on its own unique port.  Select * from sys.database_mirroring_endpoints (gives the list of Mirrored End points)

Database mirroring operating modes:  High Availability Mode: Provides synchronous data transfer between principal and Mirror. Provides automatic failover capability with the help of witness server. Performance impacted when Principle and Mirror servers are placed at a large distance.  High Safety Mode: Data is synchronous. Does not provide automatic failover capability(No witness server)  High Performance Mode: Data is not in sync and no automatic failover capability.

Prerequisites for Database Mirroring  Both the principal and mirror servers should be running the same edition of Microsoft SQL Server The partners require either SQL Server 2005 Standard Edition or SQL Server 2005 Enterprise Edition or SQL server 2005 Developer Edition.  SQL 2005 SP1 or later version is required for Mirroring.  The principal database must be in the FULL recovery model.  Verify that the mirror server has enough disk space for the mirror database  All of the server instances in a mirroring session should use the same master code page and collation.  The mirror database must have the same name as the principal database  The mirror database must be initialized from a restore of the principal database with NORECOVERY, followed by restores in sequence of principal transaction log backups. Prior to configuring mirroring ensure that at least 1 transaction log is restored in addition to full backup with NORECOVERY mode. First take full backup and one Transaction log backup from Principal server and restore it on Mirror server with NO Recovery Option. ************* We’ll Do Practical's ******************

How can I bring mirror database online after principal server is down ? First thing you will look into is about the mode in which mirroring is configured. We will see all the Possible options. Safety FULL with Witness(High Availability): If mirroring is configured in High Availability mode (Full safety) then we don't need to worry about failover as the mirror server will form a quorum with witness and will initiate an automatic failover. The safety level can be set using the below command, ALTER DATABASE dbname SET SAFETY FULL ALTER DATABASE dbname SET SAFETY OFF Safety FULL without Witness: This scenario provides high safety, but automatic failover is not allowed. This mode is called as High Protection mode. In the event of failure of the principal, the database service becomes unavailable. You need manual intervention to make the database service available. You must break the mirroring session and then recover the mirror database. For example, prior to the failure, Server_A and Server_B acted as principal and mirror respectively. Server_A fails. You need to execute the following on Server_B to make the database service available: ALTER DATABASE dbname SET PARTNER OFF RESTORE DATABASE dbname WITH RECOVERY

Safety OFF (High performance) : In the event of failure of the principal, the database service becomes unavailable. You can perform a force service to make the database service available on the mirror. However, since the safety level is OFF, it is possible that there were transactions that didn’t make it to the mirror at the time of the failure of the principal. These transactions will be lost. Therefore, manual failover with safety OFF involves acknowledging the possibility of data loss. For example, prior to the failure, Server_A and Server_B acted as principal and mirror respectively. Server_A fails. You need to execute the following on Server_B to make the database service available: ALTER DATABASE dbname SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS Once the database on Server_A becomes operational, it automatically assumes the role of the mirror. However, the mirroring session remains SUSPENDED, and you will need to manually RESUME the mirroring session.

Advantages Database Mirroring: Database mirroring architecture is more robust and efficient than Database Log Shipping. It can be configured to replicate the changes synchronously to minimized data loss. It has automatic server failover and client failover mechanism. Configuration is simpler than log shipping and replication, and has built-in network encryption support (AES algorithm). Disadvantages of Database Mirroring: Potential data lost is possible in asynchronous operation mode. RTO will vary and depend on several factors, such as propagation interval time and bandwidth speed. Mirror server/database is not available for user operation. It only works at database level and not at server level. It only propagates changes at database level, no server level objects, such as logins and fixed server role membership, can be propagated.