HADR Solution

MIRRORING
OVERVIEW OF DATABASE MIRRORING
• Database mirroring is a high-availability solution at the database level,
implemented on a per-database basis.
• To maximize database availability, you must minimize planned as well as
unplanned downtime.
• It maintains two copies of a single database that must reside on different
instances of SQL Server Database Engine (server instances).
• This feature will be removed in a future version of Microsoft SQL Server.
Avoid using this feature in new development work, and plan to modify
applications that currently use this feature. Use Always On availability
groups instead.
• Typically, these server instances reside on computers in different locations. One
server instance serves the database to clients (the principal server), while the
other server instance acts as a hot or warm standby server (the mirror server).
• At any given time, only one copy of the
database is available to clients.
This copy of the database is the principal
database.
The SQL Server that hosts this principal
database is the principal server.
• Database mirroring works by transferring and
applying the stream of database log records to
the copy of the database.
The copy of the database is the mirror
database.
The SQL Server that hosts this mirror
database is the mirror server.
The principal and mirror servers are each
considered a partner in a database mirroring
session.
• Database mirroring applies every
database modification (DML, DDL, and so
on) made to the principal database to the
mirror database.
• You cannot mirror the master, msdb,
tempdb, or model databases.
• You can mirror multiple databases from a
SQL Server instance, though. You cannot
remirror the mirror database.
• Mirroring does not support a principal
database having more than one mirrored
partner.
Benefits of Database Mirroring
• Increases availability of a database.
• In the event of a disaster, in high-safety mode with automatic failover, failover
quickly brings the standby copy of the database online (without data loss)
• Increases data protection.
• Database mirroring provides complete or almost complete redundancy of the
data, depending on whether the operating mode is high-safety or
high-performance.
• Improves the availability of the production database during upgrades.
• To minimize downtime for a mirrored database, you can sequentially upgrade
the instances of SQL Server that are hosting the failover partners. 
Database Mirroring Terms and Definitions

1. Principal ---> The Principal is the originating server i.e it is the

source server which contains the database which is configured for
mirroring.
2. Mirror ---> The Mirror is the receiving database in a mirror pair i.e it
is the destination server which contains the mirrored database.
3. Mirrored Pair ---> A Principal and Mirror operating together are
called a Mirrored Pair. The changes on the principal are reflected in
the mirrored database
4. Witness ---> is an optional instance of SQL Server
that enables the mirror server in a high-safety
mode session to recognize whether to initiate an
automatic failover.
The witness does not serve the database.
Supporting automatic failover is the only role of
the witness.
For high-performance mode, we strongly
recommend that you always keep the witness
set to OFF. 
Any SQL Server edition from SQL Express to
Enterprise Edition can act as a witness.
It ensures that both principal and mirror are
functioning properly and help for automatic
failover.
• 5. Quorum ---> is a relationship between
two or more connected server instances in
a database mirroring session, which acts as
a tiebreaker to determine which server
instance should be the principal.
• Whenever a witness is set for a database
mirroring session, quorum is required.
• Quorum is a relationship that exists when
two or more server instances in a
database mirroring session are
connected to each other. 
• quorum involves three interconnected
server instances. When a witness is set,
quorum is required to make the database
available.
• How Quorum Affects Database Availability
 6. Endpoint ---> Endpoint is the method by which
SQL Server Database engine communicates with
applications.
• Database mirroring endpoints use Transmission Control
Protocol (TCP) to send and receive messages between the
server instances participating database mirroring sessions or
hosting availability replicas.
• The database mirroring endpoint listens on a unique TCP port
number.
• The default endpoint is 5022.
• Each database mirror pair listens on its own unique
port.

To list all the database mirror endpoints run,

---> Select * from sys.database_mirroring_endpoints
To list all the endpoints
---> Select * from sys.tcp_endpoints
OPERATING MODES OF DATABASE
MIRRORING
• High-safety mode
• High-performance mode
• Synchronous Database Mirroring
(High-Safety Mode)
• Alternative high-safety modes (with automatic failover
and without automatic failover), and contains information
about the role of the witness in automatic failover.
• When transaction safety is set to FULL, the database
mirroring session runs in high-safety mode and operates
synchronously after an initial synchronizing phase. 
• the principal server begins sending its active log to the mirror
server. The mirror server writes all of the incoming log
records to disk as quickly as possible.
• principal server receives a message from the mirror server
stating that it has hardened the transaction's log to disk. Note
the wait for this message increases the latency of the
transaction.
• The time required for synchronization depends essentially on
how far the mirror database was behind the principal
database at the start of the session (measured by the number
of log records initially received from the principal server),
• the work load on the principal database, and

• the speed of the mirror system.

• After a session is synchronized, the hardened log that has yet

to be redone on the mirror database remains in the redo
queue.
High-Safety Mode Without Automatic
Failover
When the partners are connected and
the database is already synchronized,
manual failover is supported. 
If the mirror server instance goes
down, the principal server instance is
unaffected and runs exposed (that is
without mirroring the data).
If the principal server is lost, the mirror
is suspended, but service can be forced
to the mirror server (with possible data
loss).
High-Safety Mode with Automatic Failover
Automatic failover provides high availability
by ensuring that the database is still served
after the loss of one server.
The witness simply supports automatic
failover by verifying whether the principal
server is up and functioning.
The mirror server initiates automatic failover
only if the mirror and the witness remain
connected to each other after both have been
disconnected from the principal server.
Asynchronous Database Mirroring
(High-Performance Mode)-
In this configuration you don’t need a WITNESS Server
and
The Mirror Server acts as an WARM standby and does
not support automatic failure detection or failover.
When transaction safety is set to OFF, the database
mirroring session operates asynchronously.
supports only one form of role switching: forced
service (with possible data loss), which uses the
mirror server as a warm standby server. 
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.
This mode provide better performance and you can
have geographic dispersion between the principal and
the mirror.
Operating Modes of Database Mirroring
DATABASE MIRRORING IN ACTION
Preparing the
Endpoints
• For database-mirroring partners to
connect, they must trust each other.
• This trust is established by means of
Transmission Control Protocol (TCP)
endpoints.
• Therefore, on each partner, you must
create the endpoint using the T-SQL
statement CREATE ENDPOINT and grant
the connect permission on these
endpoints using the GRANT CONNECT
ON ENDPOINT statement.
Create Endpoint on each server and grant
permission for logins.
IF NOT EXISTS(SELECT * FROM sys.endpoints WHERE type = 4)
CREATE ENDPOINT DBMirrorEndPoint
STATE = STARTED AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING ( AUTHENTICATION = WINDOWS, ROLE = ALL)

GRANT CONNECT ON ENDPOINT::DBMirrorEndPoint TO

[MyDomain\MirrorServerServiceAccount]
GO

GRANT CONNECT ON ENDPOINT::DBMirrorEndPoint TO

[MyDomain\WitnessServerServiceAccount]
GO
Preparing the Database for Mirroring
1. Use the AdventureWorks database for this example, which must be
in the recovery model of FULL:
2. Connect to the principal server and take full back up of the
database
3. Next, restore this database on your designated mirror server with
the NORECOVERY option for the RESTORE DATABASE statement.
4. Connect to the principal server and take log backup
5. Connect to the mirror server and restore the transaction log that
you backed up on the principal server to the mirror server with
NORECOVERY mode to synchronize the mirror with the principal.
5. Connect to the mirror server and run the below command
USE MASTER
GO
ALTER DATABASE AdventureWorks
SET PARTNER = 'TCP://YourPrincipalServer:5022'
6. connect to the principal server, and run the below command
USE MASTER
GO
ALTER DATABASE AdventureWorks
SET PARTNER = 'TCP://YourMirrorServer:5023'
Common Mirroring errors
How to Configure Mirroring GUI
First take full backup and one Transaction log backup from Principal server and restore it
on Mirror server with NO Recovery Option. Please follow the screen shots to setup
Database mirroring.

1. Right Click on Database <Name> Go to Properties- Click on Mirroring. Click on Configure

Security button.
2. Click on Next Button NB:- Note: If you wish to configure Witness server Click on Yes
radio Button if not Click No button. This configuration is without Witness box.
3. Choose the server’s to configure (Principal & Mirror) Click on Next Button
4. Set your Principal Server with Default settings.
5. Click on Next to Select Mirror Server Instance by using Pull down Menu and hit
Connect Button
6. Verify Server name and Authentication and hit Connect
8. Verify the listener port of Mirror server and hit Next Button.
9. Service Accounts Screen Leave Both Principal and Mirror Fields
Blank
10. Verify the configuration before you hit finish Button
Once you hit Finish Button then you will get the below screen
11. Click on Start Mirroring Button.
DATABASE MIRRORING ROLE CHANGE

❖ Within the context of a database mirroring

session, the principal and mirror roles are
typically interchangeable in a process known
as role switching. 

You can fail over to the mirror server in three ways:

• Automatic failover
• Manual failover
• Forced failover
Manual Failover
• You must run this command on the principal server to successfully
fail over.
ALTER DATABASE AdventureWorks SET PARTNER FAILOVER
• In addition, the mirroring_state must be synchronized for failover to
succeed. If it is not synchronized, you get the following message
when you try to execute the failover command on the principal
Forced Failover
• For forced failover, you must execute the following command on the
mirror server.
ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
• Be cautious about using this command because you risk data loss by
running it.
• When you run this command, the mirror should not be able to
connect to the principal; otherwise, you cannot failover.
• If your principal is up and running and the mirror can connect to it when you try
to run the command, you get the following error message:
 Role Switching During a Database Mirroring Session

High-safety
High-safety mode
Form of failover High performance mode with a
without a witness
witness

Automatic failover No No Yes

Manual failover No Yes Yes

Forced service Yes Yes No

MONITORING USING DATABASE MIRRORING MONITOR

Database Mirroring Monitor will monitor the database mirroring activities.

Mirroring States
• During a database mirroring session, the mirrored database is always
in a specific state (the mirroring state).
• The state of the database reflects the communication status, data
flow, and the difference in data between the partners.
• The database mirroring session adopts the same state as the principal
database.
• The possible mirroring states of the database are as follows:
• SYNCHRONIZING
• SYNCHRONIZED
• SUSPENDED
• PENDING_FAILOVER
• DISCONNECTED
 DATABASE SNAPSHOTS
• A database snapshot is a point-in-time, read-only, static view of a
database (the source database).
• This feature comes in handy for reading the mirror database. Multiple
database snapshots can exist, but they always reside on the same SQL
Server instance as the database.
• Each database snapshot is transactionally consistent with the source
database at the point in time of the snapshot's creation.
• A snapshot persists until it is explicitly dropped by the database
owner.