Database Mirroring in SQL Server is a high-availability solution that increases database

availability by sending the log buffer between a principal server (the primary) and a mirror
server (the secondary).

It works in either synchronous or asynchronous modes.

Key Components

1. Principal Server: The primary server where the database resides.

2. Mirror Server: The secondary server that maintains a copy of the principal database.
3. Witness Server: An optional third server that helps in automatic failover by serving as a
mediator.

Mirroring Modes

1. High-Safety Mode (Synchronous): Transactions are committed on both the principal

and mirror servers simultaneously, ensuring zero data loss. It can include a witness server
for automatic failover.
2. High-Performance Mode (Asynchronous): Transactions are committed on the principal
server first and then sent to the mirror server, leading to potential data loss but better
performance.

Steps to Set Up Database Mirroring

Prerequisites

• Both databases must be in the FULL recovery model.

• Ensure the principal database is fully backed up and restored on the mirror server with
NORECOVERY.
• DB Should be same-
o Sibbi DB in principal
o Sibbi same as principal
• LogShippng: DB should be same or diffrent
• Server should be the same-> Instnace

1. Ensure Full Recovery Mode:

sql

ALTER DATABASE YourDatabaseName SET RECOVERY FULL;

2. Backup and Restore the Database:

 o Take a full backup of the principal database.
o Restore the backup on the mirror server with the NORECOVERY option.

sql

BACKUP DATABASE YourDatabaseName TO DISK =

'C:\Backups\YourDatabaseName.bak';

RESTORE DATABASE YourDatabaseName FROM DISK =

'C:\Backups\YourDatabaseName.bak'
WITH NORECOVERY;

3. Configure Mirroring:
o Use SQL Server Management Studio (SSMS) to configure mirroring.
o Connect to the principal server, right-click the database, select "Tasks," then
"Mirror," and follow the wizard to set up the mirror server and (if desired) the
witness server.
4. Start Mirroring:
o Once configured, start the mirroring session.

Example Script (T-SQL):

1. Set Partner on Principal Server:

sql

ALTER DATABASE YourDatabaseName

SET PARTNER = 'TCP://MirrorServerAddress:Port';

2. Set Partner on Mirror Server:

sql

ALTER DATABASE YourDatabaseName

SET PARTNER = 'TCP://PrincipalServerAddress:Port';

3. Configure Witness Server (Optional):

sql

ALTER DATABASE YourDatabaseName

SET WITNESS = 'TCP://WitnessServerAddress:Port';

Advantages of Database Mirroring:

• High Availability: Quick failover to the mirror server ensures minimal downtime.
• Data Protection: Synchronous mirroring ensures no data loss.
• Automatic Failover: With a witness server, automatic failover is possible.
 Disadvantages:

• Performance Overhead: Synchronous mode may introduce latency.

• Resource Intensive: Requires additional servers and storage.

Mirroring is an effective method for enhancing the availability and reliability of SQL Server
databases

. What are the Database Mirroring states?

• SYNCHRONIZING

• SYNCHRONIZED

• SUSPENDED

• PENDING_FAILOVER

• DISCONNECTED

• SYNCHRONIZING: The mirror database is catching up with the principal database. Log
records are being sent from the principal to the mirror server. This state indicates that the mirror
database is not yet fully synchronized with the principal.

• SYNCHRONIZED: The mirror database is fully synchronized with the principal database.
All transactions are committed on both the principal and mirror databases. This state indicates
that the databases are in sync, and failover can occur without data loss.

• SUSPENDED: The mirroring session has been temporarily paused. This can happen due to
manual intervention or issues such as network problems. In this state, the mirror database is not
receiving transaction log records from the principal database.

• PENDING FAILOVER: A failover is in progress. This state indicates that the principal
database is failing over to the mirror server. Once the failover is complete, the mirror server will
become the new principal server.

• DISCONNECTED: The principal and mirror servers cannot communicate. This state
indicates a network issue or that one of the servers is down. The mirroring session will resume
once the communication is restored.

The principal server is sending log records to the mirror server,

Which is applying the changes to the mirror database to roll it forward. At the start of a database
mirroring session, the database is in the SYNCHRONIZING state.

• SYNCHRONIZING: The contents of the mirror database are lagging behind the contents of the
principal database. The principal server is sending log records to the mirror server, which is applying the
changes to the mirror database to roll it forward.
• SYNCHRONIZED: When the mirror server becomes sufficiently caught up to the principal server, the
mirroring state changes to SYNCHRONIZED. The database remains in this state as long as the principal
server continues to send changes to the mirror server and the mirror server continues to apply changes to
the mirror database.
• SUSPENDED: SUSPENDED is a persistent state that survives partner shutdowns and startups.
• The mirror copy of the database is not available. The principal database is running without sending any
logs to the mirror server, a condition known as running exposed. This is the state after a failover.
• PENDING_FAILOVER: This state is found only on the principal server after a failover has begun, but
the server has not transitioned into the mirror role.
• DISCONNECTED: The partner has lost communication with the other partner.

On the principal server instance, DESKTOP-730HCAU

• Modify the following properties of the mirroring endpoint:
• Name: Mirroring
• Listener Port: 5023
• Encryption: No
• Role: Partner
On the mirror server instance, DESKTOP-730HCAU\TEXAS
• Modify the following properties of the mirroring endpoint:
• Name: Mirroring
• Listener Port: 5022
• Encryption: No
Role: Partner

Q: Database Mirroring comes with which edition?

Ans: SQL Server 2005 SP1. Or SQL Server 2005 RTM with trace flag 1400

Q: How to enable mirroring by Script ?

Ans: – Specify the partner from the mirror server

ALTER DATABASE [AdventureWorks] SET PARTNER =

N‘TCP://A.corp.mycompany.com:5022';

– Specify the partner from the principal server

ALTER DATABASE [AdventureWorks] SET PARTNER =

N‘TCP://B.corp.mycompany.com:5022';
Note: Replace the dbname before using the above script Q: How to
disable mirroring by script? Ans: ALTER DATABASE [AdventureWorks]
SET PARTNER OFF
Note: Replace the dbname before using the above script

Q: How to do manual failover to Mirror when principle is working

fine?
Ans: ALTER DATABASE <DB Name> SET PARTNER FAILOVER

Q: Why I’m getting the below error message while configuring

database mirroring?
Msg 1416, Level 16, State 31, Line 3. Database is not configured for
database mirroring
Ans : You need to restore the Full backup from principal server using With
NoRecovery option and also one transactional log backup from principal
server using With NoRecovery option and then start configuring mirroring.

Q: Can we configure mirroring between Standard Edition &

Enterprise Edition or Vice Versa?
Ans: Nope its not possible, both principal and mirror should have same
edition

Q: Is it possible to take backup of mirrored database in mirror

server?
Ans: No

Q: Is it possible to perform readonly operation at mirrored database

in mirror server?
Ans: Yes, You can create database snapshot for the same

Q: How can I increase Heartbeat time between principal and mirror

server?? By default its 10 sec.

Ans: ALTER DATABASE AdventureWorks SET PARTNER TIMEOUT 30

Q: What status of mirroring has if secondary is down?

Ans: If secondary is down principle or Mirror show status disconnected

Q: What status of mirroring has if principle is down?

Ans: If principle is down mirror will be disconnected with in recovery instead
of synchronized with restoring
Q: What status of mirroring has if mirroring is paused?
Ans: Is mirroring is set to paused from principle then then both principle &
mirror in suspending
Q: System Store Procedure to monitor Mirroring?
Ans: MSDB.SYS.SP_DBMMONITORRESULTS

Q: What are different possible Mirroring Stats?

Ans:
SYNCHRONIZING
SYNCHRONIZED
SUSPENDED
PENDING FAILOVER
DISCONNECTED

Q: Can I create multiple endpoints for configuring different

databases for mirroring and point each database to unique endpoint.
Ans: No

Q: Can we configure mirroring between 32 and 64 bit machine?

Yes, you can configure database mirroring between a 32-bit and a 64-bit machine in SQL Server. The key
requirements are ensuring both systems are running compatible versions of SQL Server, and they are
properly networked and configured for database mirroring

Q: Can Log Shipping and mirroring configure together?

Yes, you can configure Log Shipping and Database Mirroring together in SQL Server. This combination
allows you to leverage the benefits of both high availability and disaster

But it will very complicated, due to lsn mismatch. I have never done but google source I have copied the
above ans

Q: Can we renamed mirrored database?

No, you cannot rename a mirrored database in SQL Server directly while it is part of a mirroring
session. This is because database mirroring relies on the specific naming conventions to maintain
the state and synchronization between the principal and mirror databases.

If you need to rename a mirrored database, you would have to break the mirroring session first,
rename the database, and then reconfigure the mirroring. Here are the steps you could follow:

1. Remove Database Mirroring:

o On the principal server, execute the following command:

sql
 ALTER DATABASE [YourDatabase] SET PARTNER OFF;

o On the mirror server, execute the same command:

sql

ALTER DATABASE [YourDatabase] SET PARTNER OFF;

2. Rename the Database:

o On both the principal and mirror servers, rename the database:

sql

ALTER DATABASE [YourDatabase] MODIFY NAME = [NewDatabaseName];

3. Reconfigure Database Mirroring:

o Configure database mirroring again using the new database name.

Q: Is drive letter required to be same on both the server?

Is drive letter required to be same on both the server?

No, it's not strictly required for the drive letters to be the same on both servers involved in a
database mirroring configuration. However, having the same drive letters can simplify the
configuration and management of the databases. Here are a few considerations:

1. Backup and Restore Paths: If the drive letters are different, you'll need to adjust the
backup and restore file paths accordingly during the initial setup.
2. Script Adjustments: Any scripts or maintenance tasks that refer to specific drive paths
will need to account for the differences.
3. Log Shipping Considerations: If you're using log shipping in conjunction with database
mirroring, consistent drive letters can simplify the configuration.

Q: If drive letter is different on both the server. Then what is the

steps to add a new datafile?

If the drive letters are different on the principal and mirror servers in your database mirroring
setup, you'll need to take a few additional steps to add a new datafile. Here's a step-by-step guide
to help you through the process:

Step-by-Step Guide

1. Add the Datafile on the Principal Server:

o Use the following SQL command to add a new datafile to your database on the
principal server:
 sql

ALTER DATABASE [YourDatabase]

ADD FILE (NAME = [NewDatafileName], FILENAME =
'D:\Path\To\Datafile\NewDatafileName.ndf');

oEnsure that you specify the appropriate path and filename for the new datafile on
the principal server.
2. Backup the Transaction Log on the Principal Server:
o After adding the datafile, take a transaction log backup on the principal server to
capture the changes:

sql

BACKUP LOG [YourDatabase] TO DISK =

'D:\Path\To\Backup\YourDatabase_log.trn';

3. Restore the Transaction Log on the Mirror Server:

o Copy the transaction log backup file from the principal server to the mirror server.
o Restore the transaction log backup on the mirror server, specifying the new path
for the datafile that corresponds to the mirror server's drive configuration:

sql

RESTORE LOG [YourDatabase] FROM DISK =

'E:\Path\To\Backup\YourDatabase_log.trn'
WITH MOVE 'NewDatafileName' TO
'E:\Path\To\Datafile\NewDatafileName.ndf';

4. Resume Mirroring:
o Resume the mirroring session to continue synchronization between the principal
and mirror databases:

sql

ALTER DATABASE [YourDatabase] SET PARTNER RESUME;

Summary

• Principal Server: Add the datafile and take a transaction log backup.
• Mirror Server: Copy and restore the transaction log backup, specifying the appropriate
path for the new datafile.
• Resume Mirroring: Ensure the databases are in sync and mirroring continues as
expected.

Q: Can we have different collation setting on both the database

No, having different collation settings for the principal and mirror databases in a database
mirroring setup is not recommended. Database mirroring requires the principal and mirror
databases to be identical in schema, including collation settings. Different collation settings can
lead to inconsistencies and errors when data is synchronized between the two databases.

If you need to change the collation of a database that is part of a mirroring setup, you will need
to break the mirroring session, change the collation, and then reconfigure the mirroring. Here are
the steps you can follow:

1. Remove Database Mirroring:

o On the principal server, execute the following command:

sql

ALTER DATABASE [YourDatabase] SET PARTNER OFF;

o On the mirror server, execute the same command:

sql

ALTER DATABASE [YourDatabase] SET PARTNER OFF;

2. Change the Collation:

o Change the collation of the database on both the principal and mirror servers:

sql

ALTER DATABASE [YourDatabase]

COLLATE NewCollation;

3. Reconfigure Database Mirroring:

o Reconfigure database mirroring using the new collation settings.

Summary

• Principal and Mirror Databases: Must have the same collation settings.
• Steps: Remove mirroring, change collation, reconfigure mirroring.

Q: What is different role switching is available?

In SQL Server database mirroring, there are three types of role switching available:

1. Automatic Failover
 • Description: In this scenario, the mirror server automatically takes over the principal role
without any manual intervention.
• Requirements:
o High-safety mode with automatic failover: The mirroring session must be
configured in synchronous mode with a witness server.
o Witness Server: A third server (witness) must be involved to monitor the health
of the principal server.
o Availability: Ensures minimal downtime.

2. Manual Failover

• Description: The DBA initiates the failover manually, allowing planned maintenance or
controlled failover.
• Requirements:
o High-safety mode: The mirroring session must be in synchronous mode.
o Command: Execute the following on the principal server to initiate the failover:

sql

ALTER DATABASE [YourDatabase] SET PARTNER FAILOVER;

o Controlled Failover: Useful for planned events or maintenance.

3. Forced Service (With Possible Data Loss)

• Description: This type of failover is used when the principal server is not accessible, and
immediate service is required.
• Requirements:
o High-performance mode: The mirroring session must be in asynchronous mode.
o Risk: There is a risk of data loss since the mirror server might not have all the
latest transactions.
o Command: Execute the following on the mirror server to force service:

sql

ALTER DATABASE [YourDatabase] SET PARTNER

FORCE_SERVICE_ALLOW_DATA_LOSS;

o Emergency: Used in critical situations when the principal server is down.

Summary of Role Switching Options

 Initiated Risk of Data
Role Switching Type Mode Typical Use Case
By Loss

Automatic Failover High-safety Automatic None High Availability

Planned
Manual Failover High-safety DBA None
Maintenance

Forced Service (With High- Emergency

DBA Possible
Data Loss) performance Situations

Q: What is hot standby and warm standby server?

In SQL Server high availability and disaster recovery solutions, "hot standby" and "warm
standby" refer to different configurations and readiness levels of standby servers.

Hot Standby

• Description: A hot standby server is fully operational and synchronized with the primary
server. It can take over immediately in case of a primary server failure, with minimal
downtime.
• Example: Database Mirroring in high-safety mode with automatic failover and Always
On Availability Groups with synchronous-commit mode.
• Characteristics:
o Real-time Synchronization: The standby server receives real-time updates and is
always in sync with the primary server.
o Automatic Failover: The failover process is automatic and quick, ensuring high
availability.
o Immediate Availability: The standby server is ready to take over instantly,
minimizing downtime.

Warm Standby

• Description: A warm standby server is not fully synchronized with the primary server
but can be brought online relatively quickly. It requires some manual intervention and
might have a short period of downtime.
• Example: Log Shipping and Database Mirroring in high-performance mode.
• Characteristics:
 o Periodic Synchronization: The standby server receives periodic updates (e.g.,
transaction log backups) from the primary server.
o Manual Failover: The failover process requires manual intervention to bring the
standby server online.
o Short Downtime: The standby server may require some time to catch up with the
primary server, resulting in a short period of downtime.

Summary of Standby Server Types

Standby Type Synchronization Failover Type Downtime Example

Hot Real-time Automatic Minimal Database Mirroring (High-safety)

Warm Periodic Manual Short Period Log Shipping

Q: Please explain how log transmission and transaction commits

work in high performance mode and in high safety mode?

Sure, let’s dive into how log transmission and transaction commits work in High Performance
Mode and High Safety Mode in SQL Server Database Mirroring.

High Performance Mode (Asynchronous)

• Log Transmission:
o In this mode, transaction log records are sent to the mirror server asynchronously.
o The principal server does not wait for the mirror server to acknowledge receipt of
the log records.
o This reduces the overhead on the principal server and allows transactions to
commit faster, but at the risk of potential data loss.
• Transaction Commits:
o Transactions on the principal server are committed as soon as the transaction log
records are written to the local log file.
o The principal server proceeds without waiting for the mirror server to
acknowledge the log records, resulting in lower transaction latency.

High Safety Mode (Synchronous)

• Log Transmission:
o In this mode, transaction log records are sent to the mirror server synchronously.
o The principal server waits for the mirror server to acknowledge the receipt and
hardening of the log records before committing the transaction.
o This ensures that both the principal and mirror databases are in sync, providing
high data safety.
• Transaction Commits:
 o Transactions on the principal server are committed only after the mirror server has
acknowledged that the transaction log records are written to its local log file.
o This adds some latency to the transaction commit process but guarantees that no
data is lost in case of a failover.

Summary of Differences

Log
Mode Transaction Commits Pros Cons
Transmission

High Committed immediately on the

Asynchronous Low latency Potential data loss
Performance principal server

Committed only after Data safety Higher transaction

High Safety Synchronous
acknowledgment from mirror guaranteed latency

Choosing the appropriate mode depends on your requirements for data safety versus transaction
performance. High Performance Mode is suitable for scenarios where performance is critical and
occasional data loss is acceptable. High Safety Mode is preferred when data integrity and
consistency are paramount.

Q: What is SQL query to set/change operating mode?

To change the operating mode of a mirroring session, you can use the ALTER DATABASE
command with the appropriate options. Here are the SQL queries to set/change the operating
mode to High Performance (Asynchronous) and High Safety (Synchronous) modes:

High Performance Mode (Asynchronous)

sql
ALTER DATABASE [YourDatabase]
SET PARTNER SYNC OFF;

High Safety Mode (Synchronous)

sql
ALTER DATABASE [YourDatabase]
SET PARTNER SYNC ON;

Replace [YourDatabase] with the name of your database.

Example

Here's an example of how to change the operating mode for a database named MyDatabase:
Set to High Performance Mode (Asynchronous)

sql
ALTER DATABASE [MyDatabase]
SET PARTNER SYNC OFF;

Set to High Safety Mode (Synchronous)

sql
ALTER DATABASE [MyDatabase]
SET PARTNER SYNC ON;

These commands should be executed on the principal server.

Q: Can we configure mirroring without setting up endpoints?

No, SQL Server database mirroring requires setting up endpoints for communication between the
principal and mirror servers. Endpoints are necessary to establish a secure and reliable
connection between the servers involved in the mirroring session.

Here's a brief overview of the steps to create and configure mirroring endpoints:

1. Create an Endpoint on the Principal Server:

sql

CREATE ENDPOINT [MirroringEndpoint]

STATE=STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE=ALL, AUTHENTICATION=WINDOWS NEGOTIATE,
ENCRYPTION=REQUIRED ALGORITHM AES);

2. Create an Endpoint on the Mirror Server:

sql

CREATE ENDPOINT [MirroringEndpoint]

STATE=STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE=ALL, AUTHENTICATION=WINDOWS NEGOTIATE,
ENCRYPTION=REQUIRED ALGORITHM AES);

3. Grant CONNECT Permissions:

o On the principal server, grant CONNECT permissions to the mirror server's login:

sql
 GRANT CONNECT ON ENDPOINT::[MirroringEndpoint] TO
[MirrorServerLogin];

o On the mirror server, grant CONNECT permissions to the principal server's login:

sql

GRANT CONNECT ON ENDPOINT::[MirroringEndpoint] TO

[PrincipalServerLogin];

4. Configure Database Mirroring:

o Set up the mirroring session by specifying the endpoints and partners:

sql

ALTER DATABASE [YourDatabase]

SET PARTNER = 'TCP://PrincipalServer:5022';

sql

ALTER DATABASE [YourDatabase]

SET PARTNER = 'TCP://MirrorServer:5022';

Endpoints are essential for establishing the communication channels between the principal and
mirror servers, enabling them to exchange transaction log records and maintain synchronization.

Q: Suppose your table size is of 300 GB and you have to rebuild it.
Tell me Q: what is the precautionary step you will take so that your
mirroring should not be effected?

Rebuilding a large table in a database mirroring setup requires careful planning to ensure that
mirroring is not adversely affected. Here are some precautionary steps you should take:

Precautionary Steps

1. Suspend Database Mirroring:

o Temporarily suspend database mirroring to prevent the mirroring session from
being overwhelmed by the volume of changes:

sql

ALTER DATABASE [YourDatabase] SET PARTNER SUSPEND;

2. Monitor Disk Space:

 o Ensure that there is sufficient disk space on both the principal and mirror servers
to accommodate the operation. Rebuilding a large table can generate significant
transaction log activity.
3. Perform the Rebuild During Low Activity Period:
o Schedule the rebuild operation during off-peak hours to minimize the impact on
the overall system performance and reduce the load on the mirroring session.
4. Use Minimal Logging (If Possible):
o If the database is in simple or bulk-logged recovery mode, consider using minimal
logging options to reduce the size of the transaction log. Note that this might not
always be feasible if you need to maintain point-in-time recovery.
5. Monitor Transaction Log Size:
o Keep an eye on the transaction log size during the rebuild operation. Consider
taking regular transaction log backups to manage log growth.
6. Rebuild the Table:
o Perform the table rebuild operation:

sql

ALTER INDEX [YourIndex] ON [YourTable] REBUILD;

7. Resume Database Mirroring:

o After the rebuild operation is complete, resume the database mirroring session to
synchronize the changes:

sql

ALTER DATABASE [YourDatabase] SET PARTNER RESUME;

Summary

• Suspend Mirroring: Prevent mirroring from being overwhelmed.

• Monitor Resources: Ensure adequate disk space and log management.
• Schedule Wisely: Perform the rebuild during low activity periods.
• Minimal Logging: Reduce transaction log size if possible.
• Resume Mirroring: Synchronize changes after the rebuild.

Q: What is the step to move datafile in mirroring? Please step out

every steps?

Moving a datafile in a database that is part of a mirroring session requires careful planning to
ensure that the mirroring session remains consistent and uninterrupted. Here are the steps to
move a datafile in a mirrored database:

Step-by-Step Guide to Move a Datafile in Mirroring

1. Suspend Database Mirroring:
o Temporarily suspend database mirroring to prevent any changes from occurring
during the move:

sql

ALTER DATABASE [YourDatabase] SET PARTNER SUSPEND;

2. Ensure Sufficient Disk Space:

o Verify that there is enough disk space available on the target location on both the
principal and mirror servers.
3. Backup the Transaction Log:
o Take a transaction log backup to ensure you have a recent backup before starting
the operation:

sql

BACKUP LOG [YourDatabase] TO DISK =

'C:\Backup\YourDatabase_log.trn';

4. Move the Datafile on the Principal Server:

o Use the ALTER DATABASE command to move the datafile to the new location on
the principal server:

sql

ALTER DATABASE [YourDatabase]

MODIFY FILE (NAME = 'LogicalFileName', FILENAME =
'D:\NewPath\NewFileName.ndf');

o Physically move the datafile to the new location using your preferred file
management tool (e.g., Windows Explorer, command line).
5. Bring the Principal Database Offline:
o Temporarily take the database offline to ensure the file move is complete:

sql

ALTER DATABASE [YourDatabase] SET OFFLINE;

6. Bring the Principal Database Online:

o Bring the database back online:

sql

ALTER DATABASE [YourDatabase] SET ONLINE;

7. Move the Datafile on the Mirror Server:

 o Use the same ALTER DATABASE command to specify the new location on the
mirror server:

sql

ALTER DATABASE [YourDatabase]

MODIFY FILE (NAME = 'LogicalFileName', FILENAME =
'E:\NewPath\NewFileName.ndf');

o Physically move the datafile to the new location on the mirror server.
8. Resume Database Mirroring:
o Resume the mirroring session to synchronize the changes:

sql

ALTER DATABASE [YourDatabase] SET PARTNER RESUME;

Summary of Steps

1. Suspend Mirroring: Ensure no changes occur during the move.

2. Verify Disk Space: Ensure sufficient space on both servers.
3. Backup Transaction Log: Take a recent backup.
4. Move Datafile (Principal): Use ALTER DATABASE and move the file.
5. Offline/Online (Principal): Take the database offline and then online.
6. Move Datafile (Mirror): Use ALTER DATABASE and move the file.
7. Resume Mirroring: Synchronize changes.

Q: What will happen if I delete any datafile on principle server? Will

it affect mirroring session?

Yes, deleting a datafile on the principal server will have significant consequences and will affect
the mirroring session. Here's what happens and why it's a critical issue:

Consequences of Deleting a Datafile

1. Database Corruption:
o Deleting a datafile will lead to database corruption because the SQL Server
engine relies on all datafiles to maintain the integrity of the database. The
database will become inconsistent and potentially unusable.
2. Mirroring Session Disruption:
o The mirroring session will be disrupted because the mirror server will no longer
receive a consistent stream of transaction log records. The mirror server will
detect the inconsistency and the mirroring session will be suspended.
3. Error Messages:
 o SQL Server will generate error messages indicating the missing datafile and the
inability to continue operations. You will see errors in the SQL Server error log
and the Windows Event Log.

Recovery Steps

If a datafile is accidentally deleted, here are the steps you should take to attempt recovery:

1. Immediate Action:
o Stop any ongoing operations and prevent any further transactions that might
compound the issue.
2. Restore from Backup:
o Restore the affected database from the most recent full backup, along with any
differential and transaction log backups.
o On the principal server:

sql

RESTORE DATABASE [YourDatabase] FROM DISK =

'C:\Backup\YourDatabase_full.bak' WITH NORECOVERY;
RESTORE LOG [YourDatabase] FROM DISK =
'C:\Backup\YourDatabase_log.trn' WITH NORECOVERY;

3. Reconfigure Mirroring:
o Once the database is restored and consistent, reconfigure the mirroring session.

Summary

• Database Corruption: Deleting a datafile leads to corruption.

• Mirroring Disruption: Mirroring session will be disrupted and suspended.
• Recovery: Immediate action, restore from backup, and reconfigure mirroring

Q: Quorum types in Mirroring?

A Quorum is the relationship between the Witness,Principal and the
Mirror.Depending on the mode of operation it is divided into 3.

Full Quorum —>This is when all 3 Witness,Principal and the Mirror can
communicate with each other.Since witness is present automatic failover
occurs.
Quorum —>This state exist if the Witness and either partner can
communicate with it.
Partner-to-Partner —>When only the Principal and Mirror can
communicate with each other.
Q: What are the requirements for setting up database mirroring?
Additional

To set up database mirroring in SQL Server, you need to meet several requirements and follow
specific steps. Here are the key requirements:

1. SQL Server Edition

• Enterprise, Developer, or Standard Edition: Ensure that you are using one of these
editions as they support database mirroring.

2. SQL Server Instances

• Principal Server: The server that hosts the principal database.

• Mirror Server: The server that hosts the mirror database.
• Witness Server (optional): An optional server that enables automatic failover in high-
safety mode.

3. Network Configuration

• Endpoints: Configure TCP endpoints on both the principal and mirror servers for
mirroring communication.
• Network Ports: Ensure that the network ports used by the endpoints are open and
accessible.

4. Security and Permissions

• Logins and Permissions: Ensure that the principal and mirror servers have appropriate
logins and permissions to connect to each other's endpoints.
• Certificates: If using certificates for authentication, ensure that they are properly
configured.

5. Database Preparation

• Full Backup and Restore: Take a full backup of the principal database and restore it on
the mirror server using the WITH NORECOVERY option.
• Transaction Log Backup: Take a transaction log backup of the principal database and
restore it on the mirror server using the WITH NORECOVERY option.

6. High Availability and Performance Mode

• Operating Modes: Choose the appropriate operating mode (High Safety with or without
automatic failover, or High Performance).
7. Disk Space and Resource Planning

• Sufficient Disk Space: Ensure that there is enough disk space on both the principal and
mirror servers to accommodate the database files and transaction logs.

8. SQL Server Configuration

• SQL Server Configuration: Ensure that SQL Server is properly configured for database
mirroring, including any necessary settings for memory, CPU, and I/O resources.

Steps to Set Up Database Mirroring

1. Create Endpoints:
o On the principal server:

sql

CREATE ENDPOINT [MirroringEndpoint]

STATE=STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE=ALL, AUTHENTICATION=WINDOWS
NEGOTIATE, ENCRYPTION=REQUIRED ALGORITHM AES);

o On the mirror server:

sql

CREATE ENDPOINT [MirroringEndpoint]

STATE=STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE=ALL, AUTHENTICATION=WINDOWS
NEGOTIATE, ENCRYPTION=REQUIRED ALGORITHM AES);

2. Grant CONNECT Permissions:

o On the principal server:

sql

GRANT CONNECT ON ENDPOINT::[MirroringEndpoint] TO

[MirrorServerLogin];

o On the mirror server:

sql

GRANT CONNECT ON ENDPOINT::[MirroringEndpoint] TO

[PrincipalServerLogin];
 3. Configure Mirroring Partners:
o On the principal server:

sql

ALTER DATABASE [YourDatabase]

SET PARTNER = 'TCP://MirrorServer:5022';

o On the mirror server:

sql

ALTER DATABASE [YourDatabase]

SET PARTNER = 'TCP://PrincipalServer:5022';

4. Optional: Configure Witness Server:

o If using a witness server, configure it on both the principal and mirror servers:

sql

ALTER DATABASE [YourDatabase]

SET WITNESS = 'TCP://WitnessServer:5022';

Summary

• SQL Server Edition: Enterprise, Developer, or Standard.

• SQL Server Instances: Principal, Mirror, and optionally Witness.
• Network Configuration: Endpoints and network ports.
• Security and Permissions: Logins, permissions, and certificates.
• Database Preparation: Full and transaction log backups.
• Operating Modes: High Safety or High Performance.
• Resource Planning: Sufficient disk space and resources.

Q: can you mix versions in mirroring (e.g. 2005 and 2000)?

A Requirements for database mirroring:

1. Principal and mirror are running SQL Server 2005 or newer (Standard or
Enterprise Edition).
2. Principal and mirror have enough space for the database.
3. For automatic failover, witness must be running.
4. Principal database must be in FULL recovery model.
5. Mirror database must be prepared prior to mirroring setup - one full backup
and one transaction log backup need to be taken on principal and restored
WITH NORECOVERY on mirror.
A to additional Q: yes, but principal has to be earlier then mirror, for
example 2005 -> 2008. SQL Server 2000 does not support database
mirroring at all.

Q: What is the endpoint in Mirroring?

Endpoint: An endpoint is a SQL Server object that enables SQL Server to
communicate over the network. It encapsulates a transport protocol and a
port number.

An endpoint is a network protocol which is used to communicate Principal,

Mirror and Witness servers over the network.

Creation of an end point:-

Create endpoint <endpoint name> State=started/stopped/disabled

as tcp (listener port=5022/5023) for database_mirroring

(role=partner/witness)

Q: What are the Operating Modes and explain them? a. High

Availability (principle+mirror+witness) :- High-availability mode, runs
synchronously. Requires a Witness Server instance. The Principal server
sends the log buffer to the mirror server, and then waits for a response from
the mirror server.
principle is not available the witness and mirror will decide automatic failover
.mirror becomes online.
b. High Protection (princeiple+mirror):- High-protection mode, runs
synchronously. Always commit changes at both the Principal and Mirror.
automatic failover is not possible.
c. High Performance:- High-performance mode, runs asynchronously and
the transaction safety set to off. The Principal server does not wait for a
response from the mirror server after sending the log buffer. The principal
server running nice and fast, but could lose data on the mirror server.

Q: Mirroring configuration steps?

Configuring Mirroring – Steps

1. Configuring security and communication between instances

a. Configuring endpoint
b. Creating logins for other servers service accounts
c. Grant connect permission to this logins on endpoints

2. Create mirror database

a. Take full and T.Log backup from principle server and restore it in
mirror server with
NORECOVERY.
3. Establish mirroring session using ALTER DATABASE command

Default port no is
5022 is default port number for mirroring in sql server

Q: Monitoring Mirroring?
Using Database Mirroring Monitor

We can monitor the following features

· Unsent Log (at principal)
· Un restored Log (at mirror)
· Transaction Rate
· Commit Overhead (Transactions applied rate at mirror)

Q: How to set Automatic failover timeout?

The default timeout for communication between the principal, mirror, and
witness servers is 10 seconds.

Adjusting the automatic failover time for SQL Server Database

Mirroring

ALTER DATABASE dbName SET PARTNER TIMEOUT 20

Q: How to do manual failover?

To perform a manual failover

ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;

Q: Pausing or Removing Database Mirroring?

To pause the database mirroring session
ALTER DATABASE AdventureWorks SET PARTNER SUSPEND;

To resume the database mirroring session

ALTER DATABASE AdventureWorks SET PARTNER RESUME;

To remove the database mirroring session

ALTER DATABASE AdventureWorks SET PARTNER OFF;

Q: What are the major new features introduced in Mirroring 2008

version?

1. Auto Page Repair.

Select * from sys.dm_db_mirroring_auto_page_repair

2. Transactions are sending to Mirror by compressing.

To view total bytes send from principal and total bytes received at mirror we
can use (run in witness server)

Select * from sys.dm_db_mirroring_connections

Q: Counters required to monitor Mirroring performance?

Monitoring database mirroring performance

To monitor the performance of database mirroring, SQL Server provides a

System Monitor performance object (SQLServer:Database Mirroring) on
each partner (principal and mirror). The Databases performance object
provides some important information as well, such as throughput
information (Transactions/sec counter). Following are the important
counters to watch.

On the principal:
· Log Bytes Sent/sec: Number of bytes of the log sent to the mirror per
second.
· Log Send Queue KB: Total kilobytes of the log that have not yet been
sent to the mirror server.
· Transaction Delay: Delay (in milliseconds) in waiting for commit
acknowledgement from the mirror. This counters reports the total delay for
all the transactions in process at that time. To determine the average delay
per transaction, divide this counter by the Transactions/sec counter. When
running asynchronous mirroring this counter will always be 0.
· Transactions/sec: The transaction throughput of the database.This
counter is in the Databases performance object.
· Log Bytes Flushed/sec: The rate at which log records are written to the
disk. This is the log generation rate of the application. It plays a very
important role in determining database mirroring performance.This counter
is in the Databases performance object.
· Disk Write Bytes/sec: The rate at which the disk is written to. This
counter is in the Logical Disk performance object and represents. Monitor
this counter for the data as well as the log disks.

On the mirror:
· Redo Bytes/sec: Number of bytes of the transaction log applied on the
mirror database per second.
· Redo Queue KB: Total kilobytes of hardened log that remain to be applied
to the mirror database to roll it forward.
 · Disk Write Bytes/sec: The rate at which the disk is written to. This
counter is in the Logical Disk performance object and represents. Monitor
this counter for the data as well as the log disks on the mirror.

Q: Mirroring Requirements?
· SQL Server 2005 with SP1 or SQL Server 2008
· Database should be in FULL recovery model.
· Service Broker should be enabled on the database.
· Both the servers should have either Enterprise or standard editions.
· Both the servers should have same edition.
· Witness server can have any edition.
· Database name should be same
· Collation should be same

· You can’t mirror more than 10 db in 32 bit server, because an instance

can only have one end point which could be a bottle neck if there are lots of
db’s in that instances.

· You cant attach or detach

· Mirroring Ports should be open and functionable
· Service Account should be same for sql and sql agent on Instance
· Cross DB transactions and distributed transactions not permitted.

Q: How many Databases can configure Mirroring?

can't configure more than 10 DB's on 32 bit but we can on 64 Bit. But
not recommended.

Q: Can we configure mirroring on different domain.

Yes. both domain's should be trust each other.

Q: What is cross db transaction and distributed transaction.

Q: can we configure mirroring on difference SQL Service packs.

Yes(build no should be same.

Q: Advantages of Mirroring?
• Hardware or software upgrades can be simplified.
• It increases the data protection(disaster recovery).
• Increases the database availability on syn mode.
• Cost of DB mirroring less compare to clustering.
• It is robust and efficient than log shipping and replication.
• It support the full text.
• Failover is fast compare to cluster.
• Mirror server can be used to host databases for other application
Q: Disadvantages
• Does not support filestream.
• potential loss of data in async mode(high performance).
• Mirror server is not available for read-only purpose.
• It works at the database level, not at the server level.
• Multiple database fail-over.
• Q: Enhancements in 2008
• Automatic page repair(823,824,829 page errors).
• compression of mirroring data stream.
• Log send buffers - efficient use
• Write-ahead event enhanced in 2008
• Page read-ahead during the undo phase
Q: What is the page error's in mirroring
Automatic page repair(823,824,829 page errors).
823 syclic redendancy failure
824 logical errors
825 restore pending
Data page read error in principal then entry in suspect pages table in msdb db for
the particler page. page is marked as restore pending making it in accessible to
application queries. mirror state is suspended till recover the page.
Can check suspect pages:
SELECT * FROM msdb..suspect_pages;
Q: What is the default of end points (port numbers) of principal, mirror and
witness servers? How to find the Port numbers?
The default port numbers of principal, mirror and Witness servers are 5022, 5023
and 5024.
To Find Port Number:- SELECT name, port FROM sys.tcp_endpoints.
Q: Trace flags are used to temporarily set specific server characteristics or
to switch off/on a particular behavior. 1400 Trace flag is used in mirroring.
To set trace flag for Database mirroring:- Configuration Manager > Right click on
server instance > Properties > Advanced tab > Startup parameters > -t1400 (add).
Q: How to monitoring Mirroring?
There are six methods are available for monitoring the Database Mirroring
a) Database Mirroring Monitor:- Database Mirroring Monitor is a GUI tool that
shows update status and to configure warning thresholds.
To open DM Monitor:- Right click on Principal Database > Tasks > Select Launch
Database Mirroring Monitor.
b) SQL Server Management Studio:- A green arrow on the mirror server is indicates
running well. A red arrow indicates problems that need to investigate.
c) SQL Server Log:- It provides information of Mirroring establishment and status.
If any errors occurs it will be logged to SQL Server log and Windows event log.
d) Performance Monitor:- It can provides real-time information about Database
mirroring. We can use performance counters to get status of the database mirroring
such as Bytes received/sec, Bytes sent/sec, Transaction delay etc.
e) Profiler:- Profiler many events are providing the status of the Database mirroring
f) System Stored Procedures:-
⦁ sp_dbmmonitoraddmonitoring
⦁ sp_dbmmonitorchangemonitoring
⦁ sp_dbmmonitorhelpmonitoring
⦁ sp_dbmmonitordropmonitoring
Q: What is Hardening?
As quickly as possible, the log buffer is written to the transaction log on disk, a
process called hardening.
Q: What is Log buffer?
A log buffer is a special location in memory (RAM). SQL Server stores the changes
in the database’s log buffer.
Q: How to Setup Fully Qualified Names for Database Mirroring?
I. FQDN Error
One or more of the server network addresses lacks a fully qualified domain name
(FQDN). Specify the FQDN for each server, and click Start Mirroring again.
The syntax for a fully-qualified TCP address is:
TCP://<computer_name>.<domain_segment>[.<domain_segment>]:<port>
Section 1.01
Section 1.02 II. RECTIFYING FULLY QUALIFYED NAMES
1) To View Endpoints:-SELECT * FROM sys.database_mirroring_endpoints;
2) Remove existing all Endpoints from Principal, Mirror and Witness servers :-
DROP ENDPOINT [ENDPOINT_NAME]
3) Adding "local" as the primary DNS suffix as follows:-
a) Right-click My Computer, and then click Properties. The System Properties dialog
box will appear.
b) Click the Computer Name tab.
c) Click Change. The Computer Name Changes dialog box will appear.
d) Click More. The DNS Suffix and NetBIOS Computer Name dialog box will appear.
e) Enter the appropriate DNS suffix for the domain.
f) Select the Change primary DNS suffix when domain membership changes check
box.
g) Click OK to save the changes, and then click OK to exit the Computer Name
Changes dialog box.
h) Click OK to close the System Properties dialog box, and then restart the
computer for the change to take effect.
4) Reconfigure the Database mirroring either GUI or T-SQL
Q: Database mirroring is disabled by default. Database mirroring is
currently provided for evaluation purposes only and is not to be used in
production environments. To enable database mirroring for evaluation
purposes, use trace flag 1400 during startup. For more information about
trace flags and startup options, see SQL Server Books Online. (Microsoft
SQL Server, Error: 1498)
Answer:
This is a common error & everyone is know to this error. Database mirroring is
officially supported from SQL Server 2005 SP1, hence in the RTM version database
mirroring is disabled by default. You can use TRACE 1400 to enable in RTM version
or else update your SQL Server with latest service pack.
Adding Trace Flag to Startup parameter
• Goto RUN --> Type sqlservermanager.msc
• Right click on SQL Server(instancename) service and click on properties
• Click on Advanced tab
• In the startup parameters enter this ;-T1400 and click on OK
• Restart SQLservices and then try configuring db mirroring
Or
• Update SQL Server to latest service pack.

What are the Mirroring modes

Table 13-11 summarizes the different database mirroring modes and the pros/cons for each
of the modes.
Synchronous Witness
Mode Name Pro/Con
or Async present?
Supports automatic failover and is the most
High- hardened. If mirror disappears but principal and
Synchronous Yes
Availability witness are connected, operations continue.
Mirror catches up when it comes back online.
High- automatic failover and if mirror unavailable,
Synchronous No
Protection principal database goes offline.
High- Fast performance but data not guaranteed on the
Asynchronous Yes
Performance other side and no automatic failover. Useful for
 low-bandwidth connections between mirror and
principal since performance is best.

What are the Mirroring States?

PRINCIPAL MIRROR Discription
RESTORING
IN RECOVERY WHILE CONFIGURING
HIGH SAFETY WITH AUTOMATIC
Principal syncronized Mirror syncronized/restoring
FAILOVER
Principal suspended Mirror suspended/restoring If Paused principal
Mirror syncronized/restoring Principal syncronized Principal Failover

Mirroring States:

SYNCHRONIZING: Indicates that the mirror database is trying to catch up with the principal
database. This is typically seen when you just start database mirroring or in high-performance
mode.

SUSPENDED: Indicates that the mirror database is not available. During this time the
principal is referred to as running exposed, as it is processing transactions but not sending
any transaction log records to the mirror.

PENDING_FAILOVER: Indicates the state that the principal goes through before
transitioning to the mirror role.
DISCONNECTED: Indicates that the partners are unable to communicate with each other.

Operating Modes in Mirroring?

Database Mirroring Operating Modes
Operating Transaction Transfer Quorum Witness Failover
Mode safety mechanism required server Type

High Automatic
FULL Synchronous Y Y
Availability or Manual

High
FULL Synchronous Y N Manual only
Protection
High
OFF Asynchronous N N/A Forced only
Performance
Mirror Monitoring

The following query returns the descriptions for basic database mirroring session information
about either the principal or the mirror.
SELECT
DB_NAME(database_id) AS 'DatabaseName'
, mirroring_role_desc
, mirroring_safety_level_desc
, mirroring_state_desc
, mirroring_safety_sequence
, mirroring_role_sequence
, mirroring_partner_instance
, mirroring_witness_name
, mirroring_witness_state_desc
, mirroring_failover_lsn
FROM sys.database_mirroring
WHERE mirroring_guid IS NOT NULL;

The following is an analogous query returns relevant descriptive session information about the
witness server that you run on the witness.
SELECT
Database_name
, safety_level_desc
, safety_sequence_number
, role_sequence_number
, is_suspended
, is_suspended_sequence_number
, principal_server_name
, mirror_server_name
FROM sys.database_mirroring_witnesses;