Download The Database Mirroring Endpoint (SQL Server)

Database Mirroring (SQL Server)
SQL Server 2014
Other Versions
This topic has not yet been rated - Rate this topic
Note
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 AlwaysOn Availability Groups instead.
Database mirroring is a solution for increasing the availability of a SQL Server database.
Mirroring is implemented on a per-database basis and works only with databases that use the full
recovery model.
Important
For information about support for database mirroring, restrictions, prerequisites,
recommendations for configuring partner servers, and recommendations for deploying database
mirroring, see Prerequisites, Restrictions, and Recommendations for Database Mirroring.
In this Topic:







Benefits of Database Mirroring
Terms and Definitions
Overview of Database Mirroring
Setting Up a Database Mirroring Session
Interoperability and Coexistence with Other Database Engine Features
In This Section
Related Tasks
Benefits of Database Mirroring
Database mirroring is a simple strategy that offers the following benefits:

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). In the other operating
modes, the database administrator has the alternative of forcing service (with possible
data loss) to the standby copy of the database. For more information, see Role Switching,
later in this topic.

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. For more
information, see Operating Modes, later in this topic.
A database mirroring partner running on SQL Server 2008 Enterprise or later versions
automatically tries to resolve certain types of errors that prevent reading a data page. The
partner that is unable to read a page requests a fresh copy from the other partner. If this
request succeeds, the unreadable page is replaced by the copy, which usually resolves the
error. For more information, see Automatic Page Repair (Availability Groups/Database
Mirroring).

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. This will incur the
downtime of only a single failover. This form of upgrade is known as a rolling
upgrade. For more information, see Install a Service Pack on a System with Minimal
Downtime for Mirrored Databases.
[Top]
Database Mirroring Terms and Definitions
automatic failover
The process by which, when the principal server becomes unavailable, the mirror server
to take over the role of principal server and brings its copy of the database online as the
principal database.
failover partners
The two server instances (the principal server or the mirror server) that act as roleswitching partners for a mirrored database.
forced service
A failover initiated by the database owner upon the failure of the principal server that
transfers service to the mirror database while it is in an unknown state.
High-performance mode
The database mirroring session operates asynchronously and uses only the principal
server and mirror server. The only form of role switching is forced service (with possible
data loss).
High-safety mode
The database mirroring session operates synchronously and, optionally, uses a witness, as
well as the principal server and mirror server.
manual failover
A failover initiated by the database owner, while the principal server is still running, that
transfers service from the principal database to the mirror database while they are in a
synchronized state.
mirror database
The copy of the database that is typically fully synchronized with the principal database.
mirror server
In a database mirroring configuration, the server instance on which the mirror database
resides.
mirror server
In a database mirroring configuration, the server instance on which the mirror database
resides.
principal database
In database mirroring, a read-write database whose transaction log records are applied to
a read-only copy of the database (a mirror database).
principal server
In database mirroring, the partner whose database is currently the principal database.
redo queue
Received transaction log records that are waiting on the disk of a mirror server.
role
The principal server and mirror server perform complementary principal and mirror roles.
Optionally, the role of witness is performed by a third server instance.
role switching
The taking over of the principal role by the mirror.
send queue
Unsent transaction log records that have accumulated on the log disk of the principal
server.
session
The relationship that occurs during database mirroring among the principal server, mirror
server, and witness server (if present).
After a mirroring session starts or resumes, the process by which log records of the
principal database that have accumulated on the principal server are sent to the mirror
server, which writes these log records to disk as quickly as possible to catch up with the
principal server.
Transaction safety
A mirroring-specific database property that determines whether a database mirroring
session operates synchronously or asynchronously. There are two safety levels: FULL
and OFF.
Witness
For use only with high-safety mode, an optional instance of SQL Server that enables the
mirror server to recognize when to initiate an automatic failover. Unlike the two failover
partners, the witness does not serve the database. Supporting automatic failover is the
only role of the witness.
[Top]
Overview of Database Mirroring
Database mirroring maintains two copies of a single database that must reside on different server
instances of SQL Server Database Engine. Typically, these server instances reside on computers
in different locations. Starting database mirroring on a database, initiates a relationship, known
as a database mirroring session, between these server instances.
One server instance serves the database to clients (the principal server). The other instance acts
as a hot or warm standby server (the mirror server), depending on the configuration and state of
the mirroring session. When a database mirroring session is synchronized, database mirroring
provides a hot standby server that supports rapid failover without a loss of data from committed
transactions. When the session is not synchronized, the mirror server is typically available as a
warm standby server (with possible data loss).
The principal and mirror servers communicate and cooperate as partners in a database mirroring
session. The two partners perform complementary roles in the session: the principal role and the
mirror role. At any given time, one partner performs the principal role, and the other partner
performs the mirror role. Each partner is described as owning its current role. The partner that
owns the principal role is known as the principal server, and its copy of the database is the
current principal database. The partner that owns the mirror role is known as the mirror server,
and its copy of the database is the current mirror database. When database mirroring is deployed
in a production environment, the principal database is the production database.
Database mirroring involves redoing every insert, update, and delete operation that occurs on the
principal database onto the mirror database as quickly as possible. Redoing is accomplished by
sending a stream of active transaction log records to the mirror server, which applies log records
to the mirror database, in sequence, as quickly as possible. Unlike replication, which works at the
logical level, database mirroring works at the level of the physical log record. Beginning in SQL
Server 2008, the principal server compresses the stream of transaction log records before sending
it to the mirror server. This log compression occurs in all mirroring sessions.
Note
A given server instance can participate in multiple concurrent database mirroring sessions with
the same or different partners. A server instance can be a partner in some sessions and a witness
in other sessions. The mirror server instance must be running the same edition of SQL Server.
In This Section:





Operating Modes
Role Switching
Concurrent Sessions
Client Connections
Impact of Pausing a Session on the Principal Transaction Log
[Top]
Operating Modes
A database mirroring session runs with either synchronous or asynchronous operation. Under
asynchronous operation, the transactions commit without waiting for the mirror server to write
the log to disk, which maximizes performance. Under synchronous operation, a transaction is
committed on both partners, but at the cost of increased transaction latency.
There are two mirroring operating modes. One of them, high-safety mode supports synchronous
operation. Under high-safety mode, when a session starts, the mirror server synchronizes the
mirror database together with the principal database as quickly as possible. As soon as the
databases are synchronized, a transaction is committed on both partners, at the cost of increased
transaction latency.
The second operating mode, high-performance mode, runs asynchronously. The mirror server
tries to keep up with the log records sent by the principal server. The mirror database might lag
somewhat behind the principal database. However, typically, the gap between the databases is
small. However, the gap can become significant if the principal server is under a heavy work
load or the system of the mirror server is overloaded.
In high-performance mode, as soon as the principal server sends a log record to the mirror server,
the principal server sends a confirmation to the client. It does not wait for an acknowledgement
from the mirror server. This means that transactions commit without waiting for the mirror
server to write the log to disk. Such asynchronous operation enables the principal server to run
with minimum transaction latency, at the potential risk of some data loss.
All database mirroring sessions support only one principal server and one mirror server. This
configuration is shown in the following illustration.
High-safety mode with automatic failover requires a third server instance, known as a witness.
Unlike the two partners, the witness does not serve the database. The witness 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.
The following illustration shows a configuration that includes a witness.
For more information, see Role Switching, later in this topic.
Note
Establishing a new mirroring session or adding a witness to an existing mirroring configuration
requires that all involved server instances run the same version of SQL Server. However, when
you are upgrading to SQL Server 2008 or a later version, the versions of the involved instances
can vary. For more information, see Minimize Downtime for Mirrored Databases When
Upgrading Server Instances.
[Top]
Transaction Safety and Operating Modes
Whether an operating mode is asynchronous or synchronous depends on the transaction safety
setting. If you exclusively use SQL Server Management Studio to configure database mirroring,
transaction safety settings are configured automatically when you select the operation mode.
If you use Transact-SQL to configure database mirroring, you must understand how to set
transaction safety. Transaction safety is controlled by the SAFETY property of the ALTER
DATABASE statement. On a database that is being mirrored, SAFETY is either FULL or OFF.


If the SAFETY option is set to FULL, database mirroring operation is synchronous, after
the initial synchronizing phase. If a witness is set in high-safety mode, the session
supports automatic failover.
If the SAFETY option is set to OFF, database mirroring operation is asynchronous. The
session runs in high-performance mode, and the WITNESS option should also be OFF.
For more information, see Database Mirroring Operating Modes.
[Top]
Role Switching
Within the context of a database mirroring session, the principal and mirror roles are typically
interchangeable in a process known as role switching. Role switching involves transferring the
principal role to the mirror server. In role switching, the mirror server acts as the failover partner
for the principal server. When a role switch occurs, the mirror server takes over the principal role
and brings its copy of the database online as the new principal database. The former principal
server, if available, assumes the mirror role, and its database becomes the new mirror database.
Potentially, the roles can switch back and forth repeatedly.
The following three forms of role switching exist.

Automatic failover
This requires high-safety mode and the presence of the mirror server and a witness. The
database must already be synchronized, and the witness must be connected to the mirror
server.
The role of the witness is to verify whether a given partner server is up and functioning.
If the mirror server loses its connection to the principal server but the witness is still
connected to the principal server, the mirror server does not initiate a failover. For more
information, see Database Mirroring Witness.

Manual failover
This requires high-safety mode. The partners must be connected to each other, and the
database must already be synchronized.

Forced service (with possible data loss)
Under high-performance mode and high-safety mode without automatic failover, forcing
service is possible if the principal server has failed and the mirror server is available.
Important
High-performance mode is intended to run without a witness. But if a witness exists,
forcing service requires that the witness is connected to the mirror server.
In any role-switching scenario, as soon as the new principal database comes online, the client
applications can recover quickly by reconnecting to the database.
[Top]
Concurrent Sessions
A given server instance can participate in multiple, concurrent database mirroring sessions (once
per mirrored database) with the same or different server instances. Often, a server instance serves
exclusively as a partner or a witness in all of its database mirroring sessions. However, because
each session is independent of the other sessions, a server instance can act as a partner in some
sessions and as a witness in other sessions. For example, consider the following four sessions
among three server instances (SSInstance_1, SSInstance_2, and SSInstance_3). Each server
instance serves as a partner in some sessions and as a witness in others:
Server
instance
SSInstance_1
SSInstance_2
SSInstance_3
Session for
database A
Witness
Partner
Partner
Session for
database B
Partner
Witness
Partner
Session for
database C
Partner
Partner
Witness
Session for
database D
Partner
Partner
Witness
The following figure illustrates two server instances that are participating as partners together in
two mirroring sessions. One session is for a database named Db_1, and the other session is for a
database named Db_2.
Each of the databases is independent of the others. For example, a server instance might initially
be the mirror server for two databases. If one of those databases fails over, the server instance
becomes the principal server for the failed-over database while remaining the mirror server for
the other database.
As another example, consider a server instance that is the principal server for two or more
databases running in high-safety mode with automatic failover, If the server instance fails, all of
the databases automatically failover to their respective mirror databases.
When setting up a server instance to operate both as a partner and a witness, be sure that the
database mirroring endpoint supports both roles (for more information, see The Database
Mirroring Endpoint (SQL Server)). Also, ensure that the system has sufficient resources to
reduce resource contention.
Note
Because mirrored databases are independent of each other, databases cannot fail over as a group.
Client Connections
Client-connection support for database mirroring sessions is provided by the Microsoft .NET
Data Provider for SQL Server. For more information, see Connect Clients to a Database
Mirroring Session (SQL Server).
[Top]
Impact of Pausing a Session on the Principal Transaction Log
At any time, the database owner can pause a session. Pausing preserves the session state while
removing mirroring. When a session is paused, the principal server does not send any new log
records to the mirror server. All of these records remain active and accumulate in the transaction
log of the principal database. As long as a database mirroring session remains paused, the
transaction log cannot be truncated. Therefore, if the database mirroring session is paused for too
long, the log can fill up.
For more information, see Pausing and Resuming Database Mirroring (SQL Server).
Setting Up Database Mirroring Session
Before a mirroring session can begin, the database owner or system administrator must create the
mirror database, set up endpoints and logins, and, in some cases, create and set up certificates.
For more information, see Setting Up Database Mirroring (SQL Server).
Interoperability and Coexistence with Other Database
Engine Features
Database mirroring can be used with the following features or components of SQL Server.




Log shipping
Full-text catalogs
Database snapshots
Replication
In This Section
Prerequisites, Restrictions, and Recommendations for Database Mirroring
Describes the prerequisites and recommendations for setting up database mirroring.
Database Mirroring Operating Modes
Contains information about the synchronous and asynchronous operating modes for
database mirroring sessions, and about switching partner roles during a database
mirroring session.
Database Mirroring Witness
Describes the role of a witness in database mirroring, how to use a single witness in
multiple mirroring sessions, software and hardware recommendations for witnesses, and
the role of the witness in automatic failover. It also contains information about adding or
removing a witness.
Role Switching During a Database Mirroring Session (SQL Server)
Contains information about switching partner roles during a database mirroring session,
including automatic failover, manual failover, and forced service (with possible data
loss). Also, contains information about estimating the interruption of service during role
switching.
Possible Failures During Database Mirroring
Discusses physical, operating system, and SQL Server problems, including hard errors
and soft errors, that can cause a failure in a database mirroring session. Discusses how the
mirroring time-out mechanism responds to soft errors.
The Database Mirroring Endpoint (SQL Server)
Discusses how the database mirroring endpoint functions.
Setting Up Database Mirroring (SQL Server)
Contains topics about the prerequisites, recommendations, and steps for setting up
database mirroring.
Connect Clients to a Database Mirroring Session (SQL Server)
Contains topics covering client connection-string attributes and the algorithms for
connecting and reconnecting a client to a mirrored database.
Pausing and Resuming Database Mirroring (SQL Server)
Discusses what happens while database mirroring is paused, including the impact on
transaction log truncation, and contains descriptions about how to pause and resume
database mirroring.
Removing Database Mirroring (SQL Server)
Discusses the impact of removing mirroring and contains descriptions about how to end a
session
Monitoring Database Mirroring (SQL Server)
Contains information about using Database Mirroring Monitor or the dbmmonitor stored
procedures to monitor database mirroring or sessions.
[Top]
Related Tasks
Configuration Tasks
Using SQL Server Management Studio


Start the Configuring Database Mirroring Security Wizard (SQL Server Management
Studio)
Establish a Database Mirroring Session Using Windows Authentication (SQL Server
Management Studio)
Using Transact-SQL







Allow Network Access to a Database Mirroring Endpoint Using Windows Authentication
(SQL Server)
Allow a Database Mirroring Endpoint to Use Certificates for Outbound Connections
(Transact-SQL)
Allow a Database Mirroring Endpoint to Use Certificates for Inbound Connections
(Transact-SQL)
Create a Database Mirroring Endpoint for Windows Authentication (Transact-SQL)
Establish a Database Mirroring Session Using Windows Authentication (Transact-SQL)
Add a Database Mirroring Witness Using Windows Authentication (Transact-SQL)
Set Up a Mirror Database to Use the Trustworthy Property (Transact-SQL)
Using Transact-SQL or SQL Server Management Studio


[Top]
Minimize Downtime for Mirrored Databases When Upgrading Server Instances
Prepare a Mirror Database for Mirroring (SQL Server)
Administrative Tasks
Transact-SQL






Change Transaction Safety in a Database Mirroring Session (Transact-SQL)
Manually Fail Over a Database Mirroring Session (Transact-SQL)
Force Service in a Database Mirroring Session (Transact-SQL)
Pause or Resume a Database Mirroring Session (SQL Server)
Remove the Witness from a Database Mirroring Session (SQL Server)
Remove Database Mirroring (SQL Server)
SQL Server Management Studio





Add or Replace a Database Mirroring Witness (SQL Server Management Studio)
Manually Fail Over a Database Mirroring Session (SQL Server Management Studio)
Pause or Resume a Database Mirroring Session (SQL Server)
Remove the Witness from a Database Mirroring Session (SQL Server)
Remove Database Mirroring (SQL Server)
Setting Up Database Mirroring (SQL Server)
SQL Server 2014
Other Versions
This topic has not yet been rated - Rate this topic
This section describes the prerequisites, recommendations, and steps for setting up database
mirroring. For an introduction to database mirroring, see Database Mirroring (SQL Server).
Important
We recommend that you configure database mirroring during off-peak hours because
configuration can impact performance.
In this Topic:




Preparing Server Instances to Participate in Database Mirroring
Overview: Establishing a Database Mirroring
In This Section
Related Tasks
Preparing a Server Instance to Host a Mirror Server
For each database mirroring session:
1. The principal server, mirror server, and witness, if any, must be hosted by separate server
instances, which should be on separate host systems. Each of the server instances requires
a database mirroring endpoint. If you need to create a database mirroring endpoint,
ensure that it is accessible to the other server instances.
The form of authentication used for database mirroring by a server instance is a property
of its database mirroring endpoint. Two types of transport security are available for
database mirroring: Windows Authentication or certificate-based authentication. For
more information, see Transport Security for Database Mirroring and AlwaysOn
Availability Groups (SQL Server).
The requirements for network access are specific to the form of authentication, as
follows:
o
If using Windows Authentication
If server instances are running under different domain user accounts, each
requires a login in the master database of the others. If the login does not exist,
you must create it. For more information, see Allow Network Access to a
Database Mirroring Endpoint Using Windows Authentication (SQL Server).
o
If using certificates
To enable certificate authentication for database mirroring on a given server
instance, the system administrator must configure each server instance to use
certificates on both outbound and inbound connections. Outbound connections
must be configured first. For more information, see Use Certificates for a
Database Mirroring Endpoint (Transact-SQL).
2. Make sure that logins exist on the mirror server for all the database users. For more
information, see Set Up Login Accounts for Database Mirroring or AlwaysOn
Availability Groups (SQL Server).
3. On the server instance that will host the mirror database, set up the rest of the
environment that is required for the mirrored database. For more information, see
Manage Metadata When Making a Database Available on Another Server Instance (SQL
Server).
Overview: Establishing a Database Mirroring Session
The basic steps for establishing a mirroring session are as follows:
1. Create the mirror database by restoring the following backups, using RESTORE WITH
NORECOVERY on every restore operation:
1. Restore a recent full database backup of the principal database, after making sure
that the principal database was already using the full recovery model when the
backup was taken. The mirror database must have the same name as the principal
database.
2. If you have taken any differential backups of the database since the restored full
backup, restore your most recent differential backup.
3. Restore all the log backups done since the full or differential database backup.
For more information, see Prepare a Mirror Database for Mirroring (SQL Server).
Important
Complete the remaining setup steps as soon as you can after taking the backup of the
principal database. Before you can start mirroring on the partners, you should create a
current log backup on the original database and restore it to the future mirror database.
2. You can set up mirroring by using either Transact-SQL or the Database Mirroring
Wizard. For more information, see one of the following:
o Establish a Database Mirroring Session Using Windows Authentication
(Transact-SQL)
o Establish a Database Mirroring Session Using Windows Authentication (SQL
Server Management Studio)
3. By default a session is set to full transaction safety (SAFETY is set to FULL), which
starts the session in synchronous, high-safety mode without automatic failover. You can
reconfigure the session to run in high-safety mode with automatic failover or in
asynchronous, high-performance mode, as follows:
o High-safety mode with automatic failover
If you want a high-safety mode session to support automatic failover, add a
witness server instance.
To add a witness


Add a Database Mirroring Witness Using Windows Authentication
(Transact-SQL)
Establish a Database Mirroring Session Using Windows Authentication
(SQL Server Management Studio)
Note
The database owner can turn off the witness for a database at any time. Turning
off the witness is equivalent to having no witness, and automatic failover cannot
occur.
o
High-performance mode
Alternatively, if you do not want automatic failover and you prefer to emphasize
performance over availability, turn off transaction safety. For more information,
see Change Transaction Safety in a Database Mirroring Session (Transact-SQL).
Note
In high-performance mode, WITNESS needs to be set to OFF. For more
information, see Quorum: How a Witness Affects Database Availability
(Database Mirroring).
Note
For an example of using Transact-SQL to set up database mirroring using
Microsoft Windows Authentication, see Example: Setting Up Database Mirroring
Using Windows Authentication (Transact-SQL).
For an example of using Transact-SQL to set up database mirroring using
certificate-based security, see Example: Setting Up Database Mirroring Using
Certificates (Transact-SQL).
[Top]
In This Section
Prepare a Mirror Database for Mirroring (SQL Server)
Summarizes the steps for creating a mirror database or preparing a mirror database before
resuming a suspended session. Also provides links to how-to topics.
Specify a Server Network Address (Database Mirroring)
Describes the syntax of a server network address, how the address identifies the database
mirroring endpoint of the server instance, and how to find the fully-qualified domain
name of a system.
Establish a Database Mirroring Session Using Windows Authentication (SQL Server
Management Studio)
Describes how to use the Configure Database Mirroring Security Wizard to start database
mirroring on a database.
Establish a Database Mirroring Session Using Windows Authentication (Transact-SQL)
Describes the Transact-SQL steps for setting up database mirroring.
Example: Setting Up Database Mirroring Using Windows Authentication (Transact-SQL)
Contains an example of all the stages required to create a database mirroring session with
a witness, using Windows Authentication.
Example: Setting Up Database Mirroring Using Certificates (Transact-SQL)
Contains an example of all the stages required to create a database mirroring session with
a witness, using certificate-based authentication.
Set Up Login Accounts for Database Mirroring or AlwaysOn Availability Groups (SQL Server)
Describes creating a login for a remote server instance that is using a different account
than the local server instance.
Database Mirroring (SQL Server)
SQL Server 2012
Other Versions
12 out of 17 rated this helpful - Rate this topic
Note
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 AlwaysOn Availability Groups instead.
Database mirroring is a solution for increasing the availability of a SQL Server database.
Mirroring is implemented on a per-database basis and works only with databases that use the full
recovery model.
Important
For information about support for database mirroring, restrictions, prerequisites,
recommendations for configuring partner servers, and recommendations for deploying database
mirroring, see Prerequisites, Restrictions, and Recommendations for Database Mirroring.
In this Topic:







Benefits of Database Mirroring
Terms and Definitions
Overview of Database Mirroring
Setting Up a Database Mirroring Session
Interoperability and Coexistence with Other Database Engine Features
In This Section
Related Tasks
Benefits of Database Mirroring
Database mirroring is a simple strategy that offers the following benefits:

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). In the other operating
modes, the database administrator has the alternative of forcing service (with possible
data loss) to the standby copy of the database. For more information, see Role Switching,
later in this topic.

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. For more
information, see Operating Modes, later in this topic.
A database mirroring partner running on SQL Server 2008 Enterprise or later versions
automatically tries to resolve certain types of errors that prevent reading a data page. The
partner that is unable to read a page requests a fresh copy from the other partner. If this
request succeeds, the unreadable page is replaced by the copy, which usually resolves the
error. For more information, see Automatic Page Repair (Availability Groups/Database
Mirroring).

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. This will incur the
downtime of only a single failover. This form of upgrade is known as a rolling
upgrade. For more information, see Install a Service Pack on a System with Minimal
Downtime for Mirrored Databases.
[Top]
Database Mirroring Terms and Definitions
automatic failover
The process by which, when the principal server becomes unavailable, the mirror server
to take over the role of principal server and brings its copy of the database online as the
principal database.
failover partners
The two server instances (the principal server or the mirror server) that act as roleswitching partners for a mirrored database.
forced service
A failover initiated by the database owner upon the failure of the principal server that
transfers service to the mirror database while it is in an unknown state.
High-performance mode
The database mirroring session operates asynchronously and uses only the principal
server and mirror server. The only form of role switching is forced service (with possible
data loss).
High-safety mode
The database mirroring session operates synchronously and, optionally, uses a witness, as
well as the principal server and mirror server.
manual failover
A failover initiated by the database owner, while the principal server is still running, that
transfers service from the principal database to the mirror database while they are in a
synchronized state.
mirror database
The copy of the database that is typically fully synchronized with the principal database.
mirror server
In a database mirroring configuration, the server instance on which the mirror database
resides.
mirror server
In a database mirroring configuration, the server instance on which the mirror database
resides.
principal database
In database mirroring, a read-write database whose transaction log records are applied to
a read-only copy of the database (a mirror database).
principal server
In database mirroring, the partner whose database is currently the principal database.
redo queue
Received transaction log records that are waiting on the disk of a mirror server.
role
The principal server and mirror server perform complementary principal and mirror roles.
Optionally, the role of witness is performed by a third server instance.
role switching
The taking over of the principal role by the mirror.
send queue
Unsent transaction log records that have accumulated on the log disk of the principal
server.
session
The relationship that occurs during database mirroring among the principal server, mirror
server, and witness server (if present).
After a mirroring session starts or resumes, the process by which log records of the
principal database that have accumulated on the principal server are sent to the mirror
server, which writes these log records to disk as quickly as possible to catch up with the
principal server.
Transaction safety
A mirroring-specific database property that determines whether a database mirroring
session operates synchronously or asynchronously. There are two safety levels: FULL
and OFF.
Witness
For use only with high-safety mode, an optional instance of SQL Server that enables the
mirror server to recognize when to initiate an automatic failover. Unlike the two failover
partners, the witness does not serve the database. Supporting automatic failover is the
only role of the witness.
[Top]
Overview of Database Mirroring
Database mirroring maintains two copies of a single database that must reside on different server
instances of SQL Server Database Engine. Typically, these server instances reside on computers
in different locations. Starting database mirroring on a database, initiates a relationship, known
as a database mirroring session, between these server instances.
One server instance serves the database to clients (the principal server). The other instance acts
as a hot or warm standby server (the mirror server), depending on the configuration and state of
the mirroring session. When a database mirroring session is synchronized, database mirroring
provides a hot standby server that supports rapid failover without a loss of data from committed
transactions. When the session is not synchronized, the mirror server is typically available as a
warm standby server (with possible data loss).
The principal and mirror servers communicate and cooperate as partners in a database mirroring
session. The two partners perform complementary roles in the session: the principal role and the
mirror role. At any given time, one partner performs the principal role, and the other partner
performs the mirror role. Each partner is described as owning its current role. The partner that
owns the principal role is known as the principal server, and its copy of the database is the
current principal database. The partner that owns the mirror role is known as the mirror server,
and its copy of the database is the current mirror database. When database mirroring is deployed
in a production environment, the principal database is the production database.
Database mirroring involves redoing every insert, update, and delete operation that occurs on the
principal database onto the mirror database as quickly as possible. Redoing is accomplished by
sending a stream of active transaction log records to the mirror server, which applies log records
to the mirror database, in sequence, as quickly as possible. Unlike replication, which works at the
logical level, database mirroring works at the level of the physical log record. Beginning in SQL
Server 2008, the principal server compresses the stream of transaction log records before sending
it to the mirror server. This log compression occurs in all mirroring sessions.
Note
A given server instance can participate in multiple concurrent database mirroring sessions with
the same or different partners. A server instance can be a partner in some sessions and a witness
in other sessions. The mirror server instance must be running the same edition of SQL Server.
In This Section:





Operating Modes
Role Switching
Concurrent Sessions
Client Connections
Impact of Pausing a Session on the Principal Transaction Log
[Top]
Operating Modes
A database mirroring session runs with either synchronous or asynchronous operation. Under
asynchronous operation, the transactions commit without waiting for the mirror server to write
the log to disk, which maximizes performance. Under synchronous operation, a transaction is
committed on both partners, but at the cost of increased transaction latency.
There are two mirroring operating modes. One of them, high-safety mode supports synchronous
operation. Under high-safety mode, when a session starts, the mirror server synchronizes the
mirror database together with the principal database as quickly as possible. As soon as the
databases are synchronized, a transaction is committed on both partners, at the cost of increased
transaction latency.
The second operating mode, high-performance mode, runs asynchronously. The mirror server
tries to keep up with the log records sent by the principal server. The mirror database might lag
somewhat behind the principal database. However, typically, the gap between the databases is
small. However, the gap can become significant if the principal server is under a heavy work
load or the system of the mirror server is overloaded.
In high-performance mode, as soon as the principal server sends a log record to the mirror server,
the principal server sends a confirmation to the client. It does not wait for an acknowledgement
from the mirror server. This means that transactions commit without waiting for the mirror
server to write the log to disk. Such asynchronous operation enables the principal server to run
with minimum transaction latency, at the potential risk of some data loss.
All database mirroring sessions support only one principal server and one mirror server. This
configuration is shown in the following illustration.
High-safety mode with automatic failover requires a third server instance, known as a witness.
Unlike the two partners, the witness does not serve the database. The witness 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.
The following illustration shows a configuration that includes a witness.
For more information, see Role Switching, later in this topic.
Note
Establishing a new mirroring session or adding a witness to an existing mirroring configuration
requires that all involved server instances run the same version of SQL Server. However, when
you are upgrading to SQL Server 2008 or a later version, the versions of the involved instances
can vary. For more information, see Minimize Downtime for Mirrored Databases When
Upgrading Server Instances.
[Top]
Transaction Safety and Operating Modes
Whether an operating mode is asynchronous or synchronous depends on the transaction safety
setting. If you exclusively use SQL Server Management Studio to configure database mirroring,
transaction safety settings are configured automatically when you select the operation mode.
If you use Transact-SQL to configure database mirroring, you must understand how to set
transaction safety. Transaction safety is controlled by the SAFETY property of the ALTER
DATABASE statement. On a database that is being mirrored, SAFETY is either FULL or OFF.


If the SAFETY option is set to FULL, database mirroring operation is synchronous, after
the initial synchronizing phase. If a witness is set in high-safety mode, the session
supports automatic failover.
If the SAFETY option is set to OFF, database mirroring operation is asynchronous. The
session runs in high-performance mode, and the WITNESS option should also be OFF.
For more information, see Database Mirroring Operating Modes.
[Top]
Role Switching
Within the context of a database mirroring session, the principal and mirror roles are typically
interchangeable in a process known as role switching. Role switching involves transferring the
principal role to the mirror server. In role switching, the mirror server acts as the failover partner
for the principal server. When a role switch occurs, the mirror server takes over the principal role
and brings its copy of the database online as the new principal database. The former principal
server, if available, assumes the mirror role, and its database becomes the new mirror database.
Potentially, the roles can switch back and forth repeatedly.
The following three forms of role switching exist.

Automatic failover
This requires high-safety mode and the presence of the mirror server and a witness. The
database must already be synchronized, and the witness must be connected to the mirror
server.
The role of the witness is to verify whether a given partner server is up and functioning.
If the mirror server loses its connection to the principal server but the witness is still
connected to the principal server, the mirror server does not initiate a failover. For more
information, see Database Mirroring Witness.

Manual failover
This requires high-safety mode. The partners must be connected to each other, and the
database must already be synchronized.

Forced service (with possible data loss)
Under high-performance mode and high-safety mode without automatic failover, forcing
service is possible if the principal server has failed and the mirror server is available.
Important
High-performance mode is intended to run without a witness. But if a witness exists,
forcing service requires that the witness is connected to the mirror server.
In any role-switching scenario, as soon as the new principal database comes online, the client
applications can recover quickly by reconnecting to the database.
[Top]
Concurrent Sessions
A given server instance can participate in multiple, concurrent database mirroring sessions (once
per mirrored database) with the same or different server instances. Often, a server instance serves
exclusively as a partner or a witness in all of its database mirroring sessions. However, because
each session is independent of the other sessions, a server instance can act as a partner in some
sessions and as a witness in other sessions. For example, consider the following four sessions
among three server instances (SSInstance_1, SSInstance_2, and SSInstance_3). Each server
instance serves as a partner in some sessions and as a witness in others:
Server
instance
SSInstance_1
SSInstance_2
SSInstance_3
Session for
database A
Witness
Partner
Partner
Session for
database B
Partner
Witness
Partner
Session for
database C
Partner
Partner
Witness
Session for
database D
Partner
Partner
Witness
The following figure illustrates two server instances that are participating as partners together in
two mirroring sessions. One session is for a database named Db_1, and the other session is for a
database named Db_2.
Each of the databases is independent of the others. For example, a server instance might initially
be the mirror server for two databases. If one of those databases fails over, the server instance
becomes the principal server for the failed-over database while remaining the mirror server for
the other database.
As another example, consider a server instance that is the principal server for two or more
databases running in high-safety mode with automatic failover, If the server instance fails, all of
the databases automatically failover to their respective mirror databases.
When setting up a server instance to operate both as a partner and a witness, be sure that the
database mirroring endpoint supports both roles (for more information, see The Database
Mirroring Endpoint (SQL Server)). Also, ensure that the system has sufficient resources to
reduce resource contention.
Note
Because mirrored databases are independent of each other, databases cannot fail over as a group.
Client Connections
Client-connection support for database mirroring sessions is provided by the Microsoft .NET
Data Provider for SQL Server. For more information, see Connect Clients to a Database
Mirroring Session (SQL Server).
[Top]
Impact of Pausing a Session on the Principal Transaction Log
At any time, the database owner can pause a session. Pausing preserves the session state while
removing mirroring. When a session is paused, the principal server does not send any new log
records to the mirror server. All of these records remain active and accumulate in the transaction
log of the principal database. As long as a database mirroring session remains paused, the
transaction log cannot be truncated. Therefore, if the database mirroring session is paused for too
long, the log can fill up.
For more information, see Pausing and Resuming Database Mirroring (SQL Server).
Setting Up Database Mirroring Session
Before a mirroring session can begin, the database owner or system administrator must create the
mirror database, set up endpoints and logins, and, in some cases, create and set up certificates.
For more information, see Setting Up Database Mirroring (SQL Server).
Interoperability and Coexistence with Other Database
Engine Features
Database mirroring can be used with the following features or components of SQL Server.




Log shipping
Full-text catalogs
Database snapshots
Replication
In This Section
Prerequisites, Restrictions, and Recommendations for Database Mirroring
Describes the prerequisites and recommendations for setting up database mirroring.
Database Mirroring Operating Modes
Contains information about the synchronous and asynchronous operating modes for
database mirroring sessions, and about switching partner roles during a database
mirroring session.
Database Mirroring Witness
Describes the role of a witness in database mirroring, how to use a single witness in
multiple mirroring sessions, software and hardware recommendations for witnesses, and
the role of the witness in automatic failover. It also contains information about adding or
removing a witness.
Role Switching During a Database Mirroring Session (SQL Server)
Contains information about switching partner roles during a database mirroring session,
including automatic failover, manual failover, and forced service (with possible data
loss). Also, contains information about estimating the interruption of service during role
switching.
Possible Failures During Database Mirroring
Discusses physical, operating system, and SQL Server problems, including hard errors
and soft errors, that can cause a failure in a database mirroring session. Discusses how the
mirroring time-out mechanism responds to soft errors.
The Database Mirroring Endpoint (SQL Server)
Discusses how the database mirroring endpoint functions.
Setting Up Database Mirroring (SQL Server)
Contains topics about the prerequisites, recommendations, and steps for setting up
database mirroring.
Connect Clients to a Database Mirroring Session (SQL Server)
Contains topics covering client connection-string attributes and the algorithms for
connecting and reconnecting a client to a mirrored database.
Pausing and Resuming Database Mirroring (SQL Server)
Discusses what happens while database mirroring is paused, including the impact on
transaction log truncation, and contains descriptions about how to pause and resume
database mirroring.
Removing Database Mirroring (SQL Server)
Discusses the impact of removing mirroring and contains descriptions about how to end a
session
Monitoring Database Mirroring (SQL Server)
Contains information about using Database Mirroring Monitor or the dbmmonitor stored
procedures to monitor database mirroring or sessions.
[Top]
Introduction to Database Mirroring in SQL Server
Database mirroring was introduced with Microsoft SQL Server 2005 technology that can be
used to design high-availability and high-performance solutions for database redundancy. It
is designed to maintain a hot standby server with a transitionally consistent copy of the
database. Mirroring is cost-effective, speedy, requires no special hardware, and ensures
transactional consistency. This article will describe the different modes of database
mirroring and how it is different from other technologies. Here will not get into the specifics
of the SQL Server 2008 enhancements but will take a high level tour of SQL Server
Mirroring concepts.
How it works in a Nutshell
In database mirroring, transaction log records are sent directly from the principal database
to the mirror database. This helps to keep the mirror database up to date with the principal
database, with no loss of committed data. If the principal server fails, the mirror server
automatically becomes the new principal server and recovers the principal database using a
witness server under high-availability mode. We will discuss these modes later.
Fundamentally to summarize there are three jargons to understand – Principal database is
the active live database that supports all the commands, Mirror is the hot standby and
witness which allows for a quorum in case of automatic switchover.
In database mirroring, the transaction log records for a database are directly transferred
from one server to another, thereby maintaining a hot standby server. As the principal
server writes the database's log buffer to disk, it simultaneously sends that block of log
records to the mirror instance. The mirror server continuously applies the log records to its
copy of the database. Mirroring is implemented on a per-database basis, and the scope of
protection that it provides is restricted to a single-user database. Database mirroring works
only with databases that use the full recovery model. The simple and bulk-logged recovery
models do not support database mirroring. As with log shipping, in database mirroring you
must ensure that all database dependencies exist on the standby server so that the system
is able to operate correctly in the event of a failover to the mirror server.
Transactional Consistency
The transactional consistency provided by database mirroring depends upon the safety
setting you apply to the mirroring configuration. If transaction safety is set to FULL, the
principal and mirror servers operate in a synchronous transfer mode. As the principal server
hardens, its principal database logs records to disk and the principal server then sends them
to the mirror server. The principal server waits for a response from the mirror server. The
mirror server then responds when it has hardened these records to its log disk. This ensures
transactional consistency. However, when transaction safety is set to OFF, the principal
server does not wait for acknowledgment from the mirror server. As a result, the principal
and mirror servers may not be fully synchronized and transactions may be lost in the event
of failure of the principal server.
When transaction safety is set to FULL, the principal server waits for an acknowledgment
from the mirror server. This process may generate additional latency and may increase your
system’s response time. If you need to operate the mirror server in a synchronous transfer
mode, you must consider the effects of the latency generated by this process on your
system and ensure that it conforms to your service level agreement (SLA). If transactional
safety is set to OFF, the principal server does not wait for an acknowledgment from the
mirror server and no additional latency is generated. This process is also known as
operating in a high-performance mode. When selecting the safety setting and operating
mode for database mirroring, you must balance your requirement for transactional
consistency with your performance requirement. Before we get into the specific modes, let
us look at another technology that is very much mis-understood with DB Mirroring.
DB Mirroring Vs Log Shipping?
Log shipping and database mirroring are two different technologies that provide protection
for individual databases. Both technologies rely on the restore and recovery capabilities of
SQL Server databases, but implement it in different ways. Log shipping is based on
scheduling frequent backups for the transaction log files and storing the backup files in the
database of a secondary server. Both committed and rolled-back transactions are logged in
the transaction log file on the primary server. This transaction data is then sent to the
backup log file on the secondary server.
Database mirroring is based on TCP endpoints. In database mirroring, only committed
transaction data is sent from the principal to the mirror server; rolled-back transaction data
is not sent to the mirror server. In log shipping, both committed and rolled-back transaction
data are backed up. Database mirroring cannot transfer bulk-logged data, and you can use
only one mirror server. Log shipping, on the other hand, can transfer bulk-logged data, and
you can use multiple secondary servers.
Unlike log shipping, database mirroring facilitates failover. If there is a witness server,
failover occurs automatically; otherwise, failover needs to be performed manually. A failover
takes less than 3 seconds, and the database downtime during a failover is less than 10
seconds. During a failover, the mirror server performs the role of the principal server.
Failover preserves only committed transaction data.
DB Mirroring Modes
Database mirroring operates in three different modes: high-availability mode, highprotection mode, and high-performance mode.
In high-availability mode, you need all the three server roles: principal, mirror, and witness.
In this mode, the transaction safety level is set to FULL. As a result, the data transfer
mechanism between the principal and mirror servers is synchronous. That is, the principal
server waits for an acknowledgement from the mirror server that the transaction log record
has been recorded on the mirror server. Then, the client application gets confirmation that
the transaction is committed. If the principal server becomes unavailable, the witness
server and the mirror server will form a quorum and perform automatic failover. In addition
to automatic failover, you can manually perform the failover. Because the transaction safety
level is set to FULL, you do not lose any committed transactions in the event of a failover.
In high-protection mode, you need only the principal server and the mirror server; you do
not need a witness server. In this mode, the transaction safety level is set to FULL. As a
result, the data transfer mechanism between the principal and mirror servers is
synchronous. That is, the principal server waits for an acknowledgement from the mirror
server that the transaction log record has been recorded on the mirror server. Then, the
client application gets confirmation that the transaction is committed. If the principal server
becomes unavailable, you need to manually perform the failover because there is no
witness server in this mode. Because the transaction safety level is set to FULL, you do not
lose any committed transactions in the event of a failover.
In high-performance mode, as in high-protection mode, you need only the principal server
and the mirror server; you do not need a witness server. In this mode, the transaction
safety level is set to OFF. As a result, the data transfer mechanism between the principal
and mirror servers is asynchronous. That is, the principal server does not wait for an
acknowledgement from the mirror server that all transaction log records have been
recorded on the mirror server. As a result, the client application gets confirmation that a
transaction is committed as soon as the principal server has written the transaction to the
log. If the principal server becomes unavailable, you need to manually perform the failover
because there is no witness server in this mode. Because the transaction safety level is set
to OFF, you might lose some transactions in the event of a failover.
Conclusion
In this article we tooka simple tour of the basics that surround Database mirroring, in the
subsequent articles I will write about the factors that potentially affect the use of DB
Mirroring and some tips involving the enhancements of DBM in SQL Server 2008. There are
aspects aorund compressed backups and automatic page recovery which makes use of DBM
really worthwile. Do drop your comments if any.
SQL Server 2005 Part 5 - High Availability
and Scalability Enhancements
By Marcin Policht
In this article, we continue our discussion on high availability and scalability enhancements in
SQL Server 2005 Beta 2 release. Features such as clustering, database mirroring, online
indexing, fast recovery, database snapshots, and snapshot isolation transaction level have already
been covered earlier in this series - now we will concentrate on the remaining features, such as a
new method of table and index partitioning, backup and restore improvements, and new
hardware support options.

table and index partitioning - intended to improve performance of operations performed
on large tables. The basic concept is straightforward and involves splitting a table into
several units (called partitions), which can be accessed independently of each other,
limiting impact of I/O intensive activities performed on the table's data (queries, data
loads, backups and restores, maintenance tasks - such as index rebuilds and
defragmentations, as well as operations that would result in lock escalation to the table
level). The most common method of splitting data is horizontal partitioning, in which
rows of a table matching mutually exclusive criteria (such as, range of dates or letters in
alphabet, for datetime and character data, respectively) are placed in designated
partitions.
SQL Server 2000 implementation of horizontal partitioning of tables, known as
Updateable Distributed Partitioned Views (supporting Data Modification statements,
unlike its SQL Server 7.0 predecessor, capable of querying data only), was based on
creating identically structured tables across separate databases. Separation of data loaded
into tables was based on a CHECK constraint associated with one of their columns. The
same partitioned view was then defined on each of the servers hosting partitioned data
(this required creating linked server entries for each participant). Once the view was
created, users could access underlying data transparently, without being required to know
its physical location. Updateable Distributed Partitioned Views were a subject of several
limitations (outlined in more details in the SQL Server 2000 Books Online), however the
most relevant one was resulting from the fact that partitions had to be spread out across
multiple SQL Server instances.
SQL Server 2005 extended the horizontal partitioning concept, by allowing placing
partitions of the same table within a single database. In order to fully realize performance
and scalability advantages, such partitions should be assigned to separate filegroups
based on appropriately defined criteria, which are established by partitioning functions
and associated partitioning schemes. The partition function determines the distribution of
rows of a table or index across partitions and is applied by comparing its formula against
values in a designated column (called the partitioning column). While the partitioning
column will typically contain numeric or date/time values, others are also permitted with exception of timestamp, text, image, XML, varchar(max), varbinary(max), CLR
user-defined, and alias data types. A partitioning scheme assigns each of the partitions to
a specific filegroup. Note that in order to maximize performance and scalability benefits
it is important to both properly select the partitioning column and define the partitioning
function associated with it. The choice should depend on data distribution and the type of
activities that are typically performed against the target table. For example, if data is used
to produce monthly reports, then partitioning based on the date column using monthly
intervals as partition boundaries would be a very likely candidate.
The process of partitioning involves four main steps. The first, preliminary step consists
of creating filegroups and their corresponding files. During the second step, you define a
partition function using the CREATE PARTITION FUNCTION T-SQL statement, with
ranges of values (set by the FOR VALUES clause) that determine the beginning and end
of each partition (and subsequently, their number). For example, the following statement:
CREATE PARTITION FUNCTION pfIncome (money)
AS RANGE LEFT FOR VALUES ('$30,000', '$90,000')
is intended to create three partitions - the first one, containing values less then or equal to
$30,000 (inclusive, based on the LEFT element of the AS RANGE clause), the second
one between $30,000 (exclusive) and $90,000 (inclusive), and the third one
encompassing values of $90,000 and higher.
In the third step, you create a partition scheme using the CREATE PARTITION
SCHEME T-SQL statement, which associates partition function to filegroups,
determining physical layout of data. The association between partitions and filegroups is
typically one to one, although other arrangements are also possible (including specifying
extra unassigned partitions for future growth). Following our earlier example, we could
use the following statement to create a partitioning scheme:
CREATE PARTITION SCHEME psIncome
AS PARTITION pfIncome
TO ('fgIncome1', 'fgIncome2', 'fgIncome3')
This would result in rows within each range being redirected into their respective
filegroups. By specifying a different sequence of (already existing) filegroups - e.g. by
specifying TO ('fgIncome1', 'fgIncome1', 'fgIncome2') - you could alter the
mapping, allocating the first two partitions to the first filegroup.
Once partitions are associated with their respective filegroups, you can proceed with the
fourth step, in which you create a partitioned table or index using CREATE TABLE or
CREATE INDEX statements. The ON clause within these statements identifies the target
partition scheme and partitioning column, whose values are compared against the
definition of the partitioning function.
For example, the following statement would result in the creation of a table with the
second column designated as the partitioning one:
CREATE TABLE tbIncome (cSSN char(9), mIncome money)
ON psIncome(mIncome)
Once you start performing operations on the target table (such as data additions,
modifications, or queries), the database engine will transparently redirect them to
appropriate partitions. For more information on the procedure required to set up or
modify data partitioning (including converting existing non-partitioned tables to
partitioned ones and vice versa), refer to the relevant topics in the Books Online. You
will also find there, a more elaborate partitioning example, illustrating this process with
the AdventureWorks sample database included with the installation of SQL Server 2005.

backup media set mirroring - increases the reliability of backups by performing a
concurrent dump of a database to multiple (up to four) backup devices, without
significant impact on performance. This greatly increases the chances for avoiding
backup failures due to a faulty tape media or device. Note, however, that for mirrored
media sets, equivalent backup devices are needed (in the case of tape drives, it is
recommended to use the same hardware models from the same manufacturer). In order to
perform mirrored backup of a database, you need to add the MIRROR TO clause to the
BACKUP DATABASE T-SQL statement, followed by the paths of the DISK or TAPE
backup devices. In case of a backup media error detected during the restore, you can
replace the faulty one with its mirror.
Another method increasing the reliability of backups involves checksum generation when
running BACKUP, which can be enabled by including the CHECKSUM clause (backup
is also capable of verifying existing checksums and detecting torn pages, assuming that
the PAGE_VERIFY CHECKSUM and TORN_PAGE_DETECTION database options
are enabled). With this clause present, the generated checksum is recorded on the backup
media that can be subsequently used to verify the restore operation. Keep in mind,
though, that this feature introduces negative performance implications (and hence it is
disabled by default), so you should evaluate its impact before implementing it. You can
confirm successful completion of backups and media set readability (including
checksum, if applicable) by executing RESTORE VERIFYONLY against a media or
backup set. This statement, enhanced in SQL Server 2005, emulates the restore procedure
without actually performing it. Furthermore, providing that the checksum information has
been recorded during backup, you can take advantage of it by using the CHECKSUM
clause when running RESTORE. However, a potential problem with this approach is the
fact that even a single error encountered during restore will result in its failure. If such
behavior is not desired, you can prevent it by applying the
CONTINUE_AFTER_ERROR option, allowing the restore to complete (while this is
likely to leave a database in inconsistent state, you can follow it with a manual repair).
Another backup reliability enhancement introduced in SQL Server 2005 is integration of
full-text catalogs into your database backups. Full-text catalogs contain full-text indexes,
which are used to speed up keyword-based queries of text data stored in SQL Server
databases in char, varchar, nvarchar, and formatted binary columns. While full-text
search catalogs are stored outside of SQL Server (as part of the file system), they are
managed by one of SQL Server 2005 components (Microsoft Full-Text for SQL Server
service) and administered with SQL Server utilities. Integrating full-text search catalogs
into SQL Server backups and restores resolves the synchronization issues present in SQL
Server 2000, where each of these procedures had to be performed separately. You can
also include full-text catalogs when transferring databases by combining DETACH and
ATTACH operations (this was not the case in SQL Server 2000).

online restore - increases availability by allowing the target database to remain online
for its duration. Online restore functionality is available only in the case of Enterprise and
Developer editions of SQL Server 2005 (at the Beta 2 stage) and applies only to
configurations where the database consists of multiple filegroups. It can be used when



restoring files, pages, or when running piecemeal restore (performed in stages, by
filegroups, starting with the restore of the primary one). Specifics of this process depend
on a number of circumstances, such as, recovery mode, availability of transaction logs
necessary to bring database to consistent state, and read-only status of filegroups that are
to be restored. The online restore feature is useful in situations following a failure of a
drive hosting an individual filegroup. Database administrators might be able to maintain a
database on-line, while restoring this filegroup only, without impacting access to data
residing in other filegroups.
support for highly available and scalable hardware (since SQL Server 2005 relies here
on functionality built into the Windows 2003 Server and specialized server hardware, you
need to have both in place in order to take advantage of the features listed below):
o
64-bit version availability - on both Intel (64-bit Itanium and Xeon EM64T) and
AMD (Opteron with Direct Connect Architecture) platforms, when running 64-bit
version of Windows 2003 Server - increases considerably the amount of
supportable memory (up to the theoretical limit of 32TB), eliminating 4 GB limit
inherent to 32-bit platform (although it is possible to push this limit to 32GB of
RAM by taking advantage of Advanced Windowing Extensions in 32-bit versions
of Windows 2000 and Windows 2003 Servers) and makes it comparable with
other database management systems operating in 64-bit computing environments.
The new version includes 64-bit versions of Analysis Services and Integration
Services, according to the recently released Community Technology Preview.
SQL Server 2005 has also been designed to operate more efficiently in the NonUniform Memory Architecture (NUMA) systems.
o
hot-plug memory - takes advantage of the functionality present in Windows
2003 Server Enterprise and Datacenter Editions (providing that underlying
hardware supports it as well) which makes it possible to add (but not remove)
physical memory while the operating system is running. SQL Server 2005 is
capable of detecting the change dynamically (previous versions of SQL Server
could only recognize the amount of memory present at the startup). In order for
this feature to be available, the SQL Server 2005 needs to have Address
Windowing Extensions activated (using the awe enabled server configuration
option) and -h option specified at the startup.
increased number of instances supported on a per server basis - the number has been
raised to 50 with the Enterprise Edition of SQL Server 2005 (from 16 in SQL Server
2000).
reduced number of restarts required for changing configuration options - it is no longer
necessary to restart SQL server to perform such modifications as adjusting CPU affinity
or to perform changes to the AWE configuration (including, as described earlier,
recognizing newly added memory).
This concludes our review of high availability and scalability enhancements in SQL Server 2005
Beta 2. In our next article, we will look into new security related features.
QL Server 2005 Part 2 - High Availability
and Scalability Enhancements - Database
Mirroring
By Marcin Policht
In the first article of this series, we presented a high-level overview of SQL Server 2005
functionality, based on its most recent Beta 2 implementation. Our goal, going forward, will be
to discuss each of new or improved features in more details, focusing on engineering and
administrative issues. We will start by covering the high availability and scalability
enhancements, such as database mirroring (introduced in this version) and failover clustering,
which is improved in SQL Server 2005, compared to earlier editions. Note, that while SQL
Server 2005 continues to offer other, currently available technologies in this category, such as
replication and log shipping (providing warm standby capabilities), as well as standard
backup/restore (which can be used for cold standby solutions), in more or less unchanged form,
their effectiveness is positively impacted by the introduction of database snapshots, new isolation
levels, or online restore and index operations (which we will also be presenting later).
The primary goal of database mirroring is to increase data availability and allow failover in case
a server hosting the database becomes unavailable (e.g as the result of hardware or network
failure). As a primarily software based solution, in principle, it is similar to the log shipping,
available in SQL Server 2000. As in log shipping, entries from a transaction log in one database
are transferred and applied from its instance on a primary server (in the new terminology,
referred to as the principal) to its copy on a secondary server (known as the mirror), which, by
the way, implies that a mirrored database must be in full recovery mode, so its transaction logs
are not overwritten. However, this basic process is modified by introducing a number of
additional enhancements.
Maintaining synchronized copies of a database on two separate servers allows switching between
them on an as needed basis, reversing roles of partners participating in the mirroring session, (the
former principal becomes the mirror and vice versa). With database mirroring, this process can
be automated, which requires the presence of another instance of SQL Server 2005, although this
functionality is not available in the SQL Server 2005 Express edition, running on a separate
server, referred to as witness. This server monitors operations of mirroring partners, triggering
failover in case of a lack of heartbeat response from the principal (after the timeout period, which
is set in Beta 2 to 10 seconds but is expected to be configurable in Beta 3) and ensuring that at
any given time there is only one principal within each mirroring session. The decision is
coordinated between the witness and at least one other operational server. This protects against
the "split brain" scenario, which could occur if direct connectivity between the principal and the
mirror is lost. As long as the synchronization between the two is maintained, the mirror can take
over processing client requests without noticeable delay (no more than a few seconds) and
without any data loss (once the principal comes back on line, it automatically assumes the role of
the mirror and catches up with changes on the new principal). Automatic failover is further
supplemented by the new MDAC client software (based on .NET provider), smart enough to
redirect client applications transparently to the operational server.
Even though database mirroring involves three distinct servers, any one of them can serve
multiple roles in distinct database mirroring sessions. For example, a single witness can monitor
multiple mirrored sessions (performance impact of a single monitored session is negligible) or a
particular server can function as principal and mirror for two distinct database mirroring
sessions. The solution does not place any special hardware demands on participating servers,
beyond the ones expected for typical SQL Server 2005 installation (this eliminates distance
limitations inherent to clustered, shared storage-based solutions), although it is recommended
that all servers run the same version of the operating system.
Database mirroring introduces the issue intrinsic to every type of data replication mechanism,
which results from the conflict between application response time on one hand, and data
synchronization on the other. In order to ensure that the database on the mirror is synchronized
with its source on the principal, the latter should wait for confirmation of each transaction being
written to the transaction log of its partner's database, which in turn, affects how soon transaction
completion can be reported back to the client application that triggered it. Decision on how
synchronization is handled also affects automatic failover capability and the impact that mirror
failure has on operations of the principal.
To provide flexibility when dealing with different requirements, SQL Server 2005 offers three
operating modes, which are determined by presence of the witness and transaction safety level,
configurable on per mirroring session basis. The safety level can be turned either on or off. With
the safety level set to ON, committed transactions are guaranteed to be synchronized between
mirrored partners, with the safety turned OFF, synchronization is performed on a continuous
basis, but without assurance of full consistency between transaction logs of both databases.


high availability operating mode - synchronous with a witness (with transaction safety
set to ON) - In this case, transactions written to the transaction log of the database on the
principal are automatically transferred to the transaction log of its mirrored copy. The
principal waits for the confirmation of each successful write from its mirror before
committing the corresponding transaction locally, which guarantees consistency between
the two (following the initial synchronization). This type of synchronous operation is the
primary prerequisite for the automatic failover - the other is the presence and proper
functioning of the witness server (which means that only the synchronous mode with a
witness offers such capability). Additionally, availability of the witness also impacts
operations in cases when the mirror server fails. In such a scenario, if the principal can
still communicate with the witness, it will continue running (once the witness detects that
the mirror is back online, it will automatically trigger its resynchronization), otherwise (if
both mirror and witness are not reachable from the principal), the mirrored database is
placed in the OFFLINE mode.
high protection operating mode - synchronous without a witness (with transaction
safety set to ON) - uses the same synchronization mechanism as the first mode, however,
the lack of the witness precludes automatic failover capability. The owner of the database
can perform manual failover as long as the principal is present, by running ALTER

DATABASE statement with SET PARTNER FAILOVER option from the principal).
Alternately, the owner can force the service to the mirror the database by running the
ALTER DATABASE statement with the SET PARTNER
FORCE_SERVICE_ALLOW_DATA_LOSS option from the mirror, with potential data
loss (if databases are not in synchronized state). Unavailability of the mirror (due to
server or network link failure) causes the primary to place the mirrored database in
OFFLINE mode (in order to prevent the possibility of having two mirroring partners
operating simultaneously as principals).
high performance operating mode - asynchronous without a witness (with transaction
safety set to OFF) - In this case, a transaction is committed on the principal before it is
sent to its partner, which means that it is not uncommon for the source database and its
mirror to be out of synch. However, since the process of transferring transaction log
entries to the mirror is continuous, the difference is minor. In the case of principle failure,
the database owner can force service to the mirror database, resulting in the former mirror
taking on the role of the principal. Forcing the service can result in data loss
(encompassing all transaction log entries that constituted the difference between the
mirror and the principal at the time of its failure), so it should be used only if such impact
can be tolerated. Another choice when dealing with the principal failure in this mode
(which reduces possibility of data loss) is terminating the mirroring session and
recovering the database on the principal. Unlike in the synchronous mode with a witness,
unavailability of the mirror leaves the principal operational.
Client application redirection is automatic and transparent to users. This can be accomplished
either by specifying names of both principal and mirror in the application connection string or by
using a new .NET provider-based MDAC client software with its inherent redirection
capabilities. This results in caching the reference to a mirror server when the connection to a
principal is established. After a disconnect, (which can happen as the result of the principal
failure), the client library attempts first to reestablish the primary connection and, if this fails,
automatically redirect the application to the mirror database.
Unlike in log shipping situation, a mirrored database is not available for access (which might be
desired in order to offload the live database for read-only activities, such as reporting), since it is
in "recovering" state (which implies that system databases can not be mirrored and is not
intended as the replacement for replication). You can, however, get around this limitation by
creating a database snapshot of the mirror and use it instead. It is also not possible to create
separate mirrors of the same database. In addition, it is still your responsibility (as in log
shipping) to ensure that the metadata stored outside of the database (such as SQL Server logins)
remains synchronized, since this activity is not built into the database mirroring mechanism.
The security of mirroring sessions can be controlled by configuring the listener ports used for
communication between mirrored partners. This is set on a per server basis with the CREATE
ENDPOINT T-SQL statement (this statement must be executed before mirroring session can be
established). The permissions to use endpoints must be explicitly granted to the login used by the
mirroring partner (with the GRANT CONNECT ON ENDPOINT T-SQL statement), which
corresponds to the account used by its SQL Server Service. Note that this places additional
restrictions on the environment in which mirroring sessions can be established (servers
participating in mirroring must be members of the same or trusted Windows domain).
In the next article of our series, we will continue discussion on high availability and scalability
enhancements in SQL Server 2005 (Beta 2).
Database Mirroring in SQL Server 2005
176 out of 212 rated this helpful - Rate this topic
Published: April 1, 2005
By Ron Talmage, Solid Quality Learning
On This Page
Important:
Introduction
Database Mirroring Overview
Database Mirroring Dynamics
Database Mirroring Availability Scenarios
Implementing Database Mirroring
Database Mirroring and High Availability Technologies
Conclusion
Important:
Microsoft support policies only apply to the database mirroring feature as delivered with SQL
Server 2005 Service Pack 1 (SP1) onwards. If you are not running SQL Server 2005 with SP1 or
later, database mirroring should not be used in production environments. Microsoft support
services will not support databases or applications that use database mirroring from the RTM
release.
Top Of Page
Introduction
Database mirroring is a new SQL Server 2005 technology available for review for increasing
database availability. Database mirroring transfers transaction log records directly from one
server to another and can quickly fail over to the standby server. You can code client
applications to automatically redirect their connection information, and in the event of a failover,
automatically connect to the standby server and database. Fast failover with minimal data loss
has traditionally involved higher hardware cost and greater software complexity. Database
mirroring, however, can fail over quickly with no loss of committed data, does not require
proprietary hardware, and is easy to set up and manage.
Top Of Page
Database Mirroring Overview
In database mirroring, an originating SQL Server 2005 instance continuously sends a database's
transaction log records to a copy of the database on another standby SQL Server instance. The
originating database and server have the role of principal, and the receiving database and server
have the role of mirror. The principal and mirror servers must be separate instances of SQL
Server 2005.
In all SQL Server databases, data changes are recorded in the transaction log before any changes
to actual data pages are made. The transaction log records are placed first in a database's log
buffer in memory, and then flushed to disk (or 'hardened') as quickly as possible. In database
mirroring, as the principal server writes the principal database's log buffer to disk, it
simultaneously sends that block of log records to the mirror instance.
When the mirror server receives a block of log records, it places the log records first into the
mirror database's log buffer and then hardens them to disk as quickly as possible. Those
transaction log records are later replayed on the mirror. Because the mirror database replays the
principal's transaction log records, it duplicates the database changes on the principal database.
The principal and mirror servers are each considered a partner in the database mirroring session.
A database mirroring session consists of a relationship between the partner servers when they
mirror a database from one partner to another. A given partner server may have the principal role
for one database and a mirror role for a different database.
In addition to the two partner servers (principal and mirror) a database mirroring session may
have an optional third server, called the witness. The witness server's role is to enable automatic
failover. When database mirroring is used for high availability, if a principal server suddenly
fails, if the mirror server has confirmation from the witness, it can automatically take on the role
of principal and make its database available within a few seconds.
Some important items to note about database mirroring:




The principal database must be in the FULL recovery model. Log records that result from
bulk-logged operations cannot be sent to the mirror 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.
The mirror database must have the same name as the principal database.
Because the mirror database is in a recovering state, it cannot be accessed directly. You
can create database snapshots on the mirror to indirectly read the mirror database at a
point in time. (See 'Database Mirroring and Database Snapshots' later in this paper.)
Note: For more information about the terms related to database mirroring, see "Overview of
Database Mirroring" in SQL Server 2005 Books Online.
Operating Modes
There are three possible operating modes for a database mirroring session. The exact mode is
based on the setting of transaction safety and whether a witness server is part of the mirroring
session.
Table 1: Database Mirroring Operating Modes
Operating
Mode
High
Availability
High
Protection
High
Performance
Transaction
safety
Transfer
mechanism
Quorum
required
Witness
server
Failover Type
FULL
Synchronous
Y
Y
Automatic or
Manual
FULL
Synchronous
Y
N
Manual only
OFF
Asynchronous
N
N/A
Forced only
If safety is FULL and a witness is set, synchronous data transfer will occur, and a quorum is
required for database service. A quorum vote requires at least two servers to decide which role,
principal or mirror, each of the two partner servers should play.
In order to explore the three operating modes in more detail, let's first take a closer look at
transaction safety and the role of a quorum.
Transaction Safety
If transaction safety (or just 'safety') is set to FULL, the principal and mirror servers operate in a
synchronous transfer mode. As the principal server hardens its principal database log records to
disk, it also sends them to the mirror. The principal then waits for a response from the mirror
server. The mirror responds when it has hardened those same log records to the mirror's log disk.
When safety is set OFF, the principal does not wait for acknowledgment from the mirror, and so
the principal and mirror may not be fully synchronized (that is, the mirror may not quite keep up
with the principal).
Synchronous transfer guarantees that all transactions in the mirror database's transaction log will
be synchronized with the principal database's transaction log, and so the transactions are
considered safely transferred. You set safety to FULL using
ALTER DATABASE [<dbname>] SET SAFETY FULL;
When safety is set to OFF, the communication between the principal and the mirror is
asynchronous. The principal server will not wait for an acknowledgment from the mirror that the
mirror has hardened a block of transaction records. The mirror will attempt to keep up with the
principal, by recording transactions as quickly as possible, but some transactions may be lost if
the principal suddenly fails and you force the mirror into service. (See the topic 'Forced Service'
in SQL Server Books Online.)
The Quorum and the Witness Server
When the witness server is set, a database mirroring session requires a quorum to keep a
database in service. A quorum is the minimal relationship among all the connected servers
required by a synchronous database mirroring session. Because at least two servers are required
for a quorum, when the witness is set the principal server must form a quorum with at least one
other server to keep the database in service, regardless of the safety setting. Normally, if a
witness is set, then the safety level is set to FULL as well.
The witness server assists the principal or mirror in forming a quorum. If a witness server is
present, a loss of either the principal database or the mirror database leaves two servers to form a
quorum. If the principal cannot see the mirror server, but it can form a quorum with the witness,
it can keep its database in service. Similarly, if the mirror and witness servers cannot see the
principal server, and the mirror server can form a quorum with the witness, the mirror can take
on the role of a new principal server.
The witness is not considered a single point of failure in a database mirroring session, because if
the witness server fails, the principal and mirror continue to form a quorum. (For further
information, see the topic "Quorum in Database Mirroring Sessions" in SQL Server Books
Online.)
High Availability Operating Mode
The High Availability operating mode supports maximum database availability with automatic
failover to the mirror database if the principal database fails. It requires that you set safety to
FULL and define a witness server as part of the database mirroring session.
The High Availability mode is best used where you have fast and very reliable communication
paths between the servers and you require automatic failover for a single database. When safety
is FULL, the principal server must wait briefly for responses from the mirror server, and
therefore the performance of the principal server may be affected by the capability of the mirror
server. Because a single database failure will cause an automatic failover, if you have multidatabase applications you want to consider other operating modes. (See "Multi-Database Issues"
in the Implementation section later in this paper.)
In the High Availability mode, database mirroring is self-monitoring. If the principal database
suddenly becomes unavailable, or the principal's server is down, then the witness and the mirror
will form a quorum of two and the mirror SQL Server will perform an automatic failover. At that
point, the mirror server instance will change its role to become the new principal and recover the
database. The mirror server can become available quickly because the mirror has been replaying
the principal's transaction logs and its transaction log has been synchronized with the principal's.
Also, SQL Server 2005 can make a database available to users earlier in the recovery process.
SQL Server database recovery consists of three phases: the analysis phase, the redo phase, and
finally the undo phase. In SQL Server 2005, a newly recovered database can become available
for use as soon as the redo phase is finished. Therefore if a database mirroring failover occurs,
the recovered new principal database can become available for use as soon as it finishes the redo
phase. Because the mirror database has been replaying transaction log records all along, all the
mirror serves has to do is finish the redo process, which normally can be accomplished in
seconds.
High Protection Operating Mode
The High Protection operating mode also has transactional safety FULL, but has no witness
server as part of the mirroring session. The principal database does not need to form a quorum to
serve the database. In this mode only a manual failover is possible, because there is no witness to
fill the tie-breaker role. An automatic failover is not possible, because if the principal server fails,
the mirror server has no witness server with which to form a quorum.
Since there is no witness server defined, automatic failover cannot occur and a principal server
which suddenly loses its quorum with the mirror does not take its database out of service.
High Performance Operating Mode
In the High Performance operating mode, transactional safety is OFF, and the transfer of log
records is asynchronous. The principal server does not wait for an acknowledgement from the
mirror that all transaction log records have been recorded on the mirror. The mirror does its best
to keep up with the principal, but it is not guaranteed at any point in time that all the most recent
transactions from the principal will have been hardened in the mirror's transaction log.
Since the safety is OFF, automatic failover is not possible, because of possible data loss;
therefore, a witness server is not recommended to be configured for this scenario. If the witness
is set, a quorum is required. If the witness is not set, then a quorum is not required. Manual
failover is not enabled for the High Performance mode. The only type of failover allowed is
forced service failover, which is also a manual operation:
ALTER DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
The forced service failover causes an immediate recovery of the mirror database. It may involve
potential data loss on the mirror when it is recovered, if some of the transaction log blocks from
the principal have not yet been received by the mirror. The High Performance mode is best used
for transferring data over long distances (that is, for disaster recovery to a remote site), or for
mirroring very active databases where some potential data loss is acceptable.
Database Snapshots and the Mirror Database
Because the mirror database is in a recovering state, it is not accessible and not readable. With
SQL Server 2005 Enterprise Edition and Developer Edition, you can create database snapshots to
read the mirror database at a point in time. Database snapshots provide a read-only view of a
database, exposing data that is consistent at the point of the snapshot creation.
You access the database snapshot just as though it were another database. When you query a
database snapshot, you read original versions of any database data that has been changed after
the snapshot's creation from the database snapshot's file, and you read unchanged data from the
original database. The end effect is that you see database data current at the point in time that
you created the snapshot. (See the topic "Using Database Snapshots with Database Mirroring" in
SQL Server Books Online for more information.)
Because database snapshots do require some overhead on the mirror server, you need to be
careful about how they might impact database mirroring performance. You can only mirror to
one database, so if you need to scale out to many read-only reporting servers, transactional
replication is a better choice. (For more information, see "Database Mirroring and Replication"
in the Implementation section later.)
Client-side Redirect
In SQL Server 2005, if you connect to a database that is being mirrored with ADO.NET or the
SQL Native Client, your application can take advantage of the drivers' ability to automatically
redirect connections when a database mirroring failover occurs. You must specify the initial
principal server and database in the connection string, and optionally the failover partner server.
There are many ways to write the connection string, but here is one example, specifying server A
as the principal, server B as the mirror, and AdventureWorks as the database name:
"Data Source=A;Failover Partner=B;Initial Catalog=AdventureWorks;Integrated
Security=True;"
The failover partner in the connection string is used as an alternate server name if the connection
to the initial principal server fails. If the connection to the initial principal server succeeds, then
the failover partner name will not be used, but the driver will store the failover partner name that
it retrieves from the principal server on the client-side cache.
Assume a client is successfully connected to the principal, and a database mirroring failover
(automatic, manual, or forced) occurs. The next time the application attempts to use the
connection, the ADO.NET or SQL Native Client driver will detect that the connection to the old
principal has failed, and will automatically retry connecting to the new principal as specified in
the failover partner name. If successful, and there is a new mirror server specified for the
database mirroring session by the new principal, the driver will retrieve the new partner failover
server name and place it in its client cache. If the client cannot connect to the alternate server, the
driver will try each server alternately until the login timeout period is reached.
The great advantage of using the database mirroring support built into ADO.NET and the SQL
Native Client driver is that you do not need to recode the application, or place special code in the
application, to handle a database mirroring failover.
If you do not use the ADO.NET or SQL Native Client automatic redirection, you can use other
techniques that will enable your application to fail over. For example, you could use Network
Load Balancing to manually redirect connections from one server to another, while the client just
connects to a virtual server name. You might also write your own redirection code and retry
logic.
However, all these techniques for coordinating client redirection with a database mirroring have
an important limitation. Database mirroring occurs only at the database level, not the server
level. Be careful if your application relies on querying several databases on a server, or uses
multi-part object names to query across several databases. When several databases reside on one
server, and they are mirrored to a standby server, it is possible that one of several databases
might fail over to the standby but the others remain on the original server. In that case, you might
need one connection per database that you are querying, so that you do not attempt crossdatabase queries on a standby server where only one database is a principal and the remaining
are mirrors.
Database Mirroring and SQL Server 2005 Editions
The following table shows what database mirroring features are supported by the various
editions of SQL Server 2005.
Table 2: Database Mirroring and SQL Server 2005 Editions
A few database mirroring features require SQL Server 2005 Enterprise or Developer Editions:



High Performance mode with safety OFF (asynchronous data transfer);
database snapshots
Use of multiple threads for replaying the transaction log on the mirror database (parallel
REDO).
SQL Express and the Workgroup Edition can be used as a witness server, but they cannot be
used as a partner server in database mirroring.
Top Of Page
Database Mirroring Dynamics
To gain a deeper understanding of SQL Server 2005 database mirroring, it is helpful to see how a
database mirroring session can change over time. This section will cover the different database
states in a database mirroring session, the mechanisms of synchronous and asynchronous log
record transfer, and failover sequences.
Setup and Security
Once you have identified the principal, mirror, and, optionally, the witness servers, setting up
Database Mirroring consists of essentially three steps.
1. You must make a backup of the database and restore it to the intended mirror server
without recovery.
Note: The principal database must be in the FULL recovery model before you make the
database backup to restore to the mirror server. Database mirroring will not work if it
must transfer Bulk-logged records in the transaction log. The mirror server must have
sufficient free space for file growth as does the principal database. If you want to create
database snapshots on the mirror, you must provision additional free space for them as
well.
If your backup, copy, and restore takes a relatively long time, you may need to take
transaction log backups on the originating database in order to keep the log size under
control. However, database mirroring will not be able to initialize if transaction log
records have been truncated from the log by log backups. Therefore you must restore
those transaction log backups in sequence to the intended mirror database with
norecovery before database mirroring will be able to initialize.
2. The servers involved in the database mirroring session must trust each other. For local
communication such as a domain, trusting means that each SQL Server instance login
must have rights to connect to the other mirroring server, and do its endpoints. You
establish this first by using the CREATE LOGIN command on each server, followed by
the GRANT CONNECT ON ENDPOINT command. (See "Example of Setting Up
Database Mirroring Using Windows Authentication" in SQL Server Books Online.)
For communication across non-trusted domains, you must use certificates. If you use the
CREATE CERTIFICATE statement to create a self-signed certificate, most of the
database mirroring certificate requirements will be met. You must also make sure that the
certificate is marked ACTIVE FOR BEGIN_DIALOG in the CREATE CERTIFICATE
statement.
3. The next step is to establish database mirroring endpoints. Establishing endpoints
requires that you have system administrator rights to the SQL Server instance. You must
set up endpoints on each server that are specifically created as database mirroring
endpoints. The easiest way to set up endpoints is to use the Configure Database Mirroring
Security Wizard, which you can invoke by clicking the Configure Security button on the
Mirroring page of the Database Properties dialog. The Configure Security dialogs will
prompt you for computer names and port numbers, and optionally logins, before
constructing and executing the CREATE ENDPOINT commands. You can also execute
the CREATE ENDPOINT command using Transact-SQL. (See "How to: Create a
Mirroring Endpoint (Transact-SQL)" in SQL Server Books Online.)
If you are setting up database mirroring on a domain, and all SQL Server instances use
the same service login and password, you do not need to create logins on each server.
Similarly, on a workgroup, if all SQL Server instances use the same service login and
password, you do not need to create logins on the servers. Just leave the logins blank on
the Configure Database Mirroring Security Wizard when setting up endpoints.
Each database endpoint must specify a unique port on the server. When working with
SQL Server instances on separate machines, these port numbers can all be the same and
the Configure Database Mirroring Security Wizard will automatically suggest port 5022
as the port. If any of the SQL Server instances are on the same machine, each instance
must have a distinct port and the port numbers must be unique.
Suppose you want to have three servers in a High Availability mirroring session. Server
A will be the principal, server B the mirror, and server W the witness. For server A, the
following command will create an endpoint on port 5022:
CREATE ENDPOINT [Mirroring]
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = ENABLED);
Note that the role has been specified as PARTNER, so that this server may take on the
role of principal or mirror for any given database mirroring database. The same command
is issued on server B. Since server B is a SQL Server instance on a distinct physical
machine, the port number is the same. Then for server W, you can issue
CREATE ENDPOINT [Mirroring]
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = ENABLED);
Note that for server W, the role is specified as WITNESS.
By default, the endpoint is not started. You can next start each endpoint using the
following query on each server:
ALTER ENDPOINT [Mirroring] STATE = STARTED;
Optionally, you can insert the STATE option in the CREATE ENDPOINT command.
This process is repeated on each server.
When you create an endpoint using CREATE ENDPOINT, you can restrict access by IP
address using the protocol specific arguments. You can restrict access to a particular set
of IP addresses by combining the RESTRICT_IP with ALL option, and the EXCEPT_IP
with the list of just those special IP addresses you want. (See "CREATE ENDPOINT" in
SQL Server Books Online.)
You can inspect the database mirroring endpoints on a server by querying the
sys.database_mirroring_endpoints catalog view:
SELECT *
FROM sys.database_mirroring_endpoints;
4. To start database mirroring, you next specify the partners and witness. You need database
owner permissions to start and administer a given database mirroring session. On server
A, the intended principal server, you tell SQL Server to give a particular database the
principal role and what its partner (mirror) server is:
5. -- Specify the partner from the principal server
6. ALTER DATABASE [AdventureWorks] SET PARTNER =
7. N'TCP://B.corp.mycompany.com:5022';
The partner name must be the fully qualified computer name of the partner. Finding fully
qualified names can be a challenge, but the Configure Database Mirroring Security
Wizard will find them automatically when establishing endpoints.
The fully qualified computer name of each server can also be found running the
following from the command prompt:
IPCONFIG /ALL
Concatenate the "Host Name" and "Primary DNS Suffix". If you see something like:
Host Name . . . . . . . . . . . . : A
Primary Dns Suffix . . . . . . . : corp.mycompany.com
Then the computer name is just A.corp.mycompany.com. Prefix 'TCP://' and append
':<port number>' and you then have the partner name.
On the mirror server, you would just repeat the same command, but with the principal
server named:
-- Specify the partner from the mirror server
ALTER DATABASE [AdventureWorks] SET PARTNER =
N'TCP://A.corp.mycompany.com:5022';
On the principal server, you next specify the witness server:
-- Specify the witness from the principal server
ALTER DATABASE [AdventureWorks] SET WITNESS =
N'TCP://W.corp.mycompany.com:5026';
You do not need to execute any additional commands on the witness server after the
initial CREATE ENDPOINT.
Finally, you specify the safety level of the session, on the principal server:
-- Set the safety level from the principal server
ALTER DATABASE [AdventureWorks] SET SAFETY FULL;
At this point, mirroring will start automatically, and the principal and mirror servers will
synchronize.You can adjust the timeout value for determining partner outage, using the
TIMEOUT parameter to ALTER DATABASE. For example, to change the TIMEOUT
value to 20 seconds (the default is 10), on the principal server issue:
-- Issue from the principal server
ALTER DATABASE [AdventureWorks] SET PARTNER TIMEOUT 20;
Finally, you can adjust the size of the redo queue on the mirror by issuing the ALTER
DATABASE with the REDO_QUEUE option on the principal server. The following
query will set the redo queue to 100 megabytes on the mirror:
-- Issue from the principal server
ALTER DATABASE [AdventureWorks] SET PARTNER REDO_QUEUE 100MB;
Once you have specified the partners, mirroring will start immediately.
Database Mirroring Catalog Views
A database mirroring session consists of the relationship formed between the partner serves and
potentially the witness server. Each of the participating servers keeps some metadata about the
session and the current state of the databases. You can inspect the session on the principal or
mirror server by querying the sys.database_mirroring catalog view. The witness server metadata
is returned using a different catalog view: sys.database_mirroring_witnesses. (For a fuller
description of all the columns available in both catalog views, see "sys.database_mirroring" and
"sys.database_mirrroing_witnesses" in SQL Server Books Online.)
A good way to get started in understanding how a database mirroring session works, and the
states the databases can be in, is by inspecting the data from the catalog views. Let's start with a
High Availability session (safety is FULL and there is a witness server). 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;
,
,
,
,
,
,
,
Now let's compare the output of both queries in a typical database mirroring session. Assume
you've just set up mirroring from server A to server B with safety as FULL. (For sample code to
set up the following configuration, see "Setup and Security" in Implementing Database
Mirroring, later.) The witness server is server W and you're mirroring the AdventureWorks
database. Table 3 shows the possible output of the above queries for the two partners.
Table 3: The output of sys.database_mirroring on a sample High Availability session for
both partners.
Partnermetadatacolumn
db_name(database_id)
mirroring_role_desc
mirroring_safety_level_de
sc
mirroring_state_desc
mirroring_safety_sequence
mirroring_role_sequence
mirroring_partner_instanc
e
mirroring_witness_name
Principalvalues:Server A
AdventureWorks
PRINCIPAL
Mirrorvalues:Server B
AdventureWorks
MIRROR
FULL
FULL
SYNCHRONIZED
1
1
TCP://B.corp.mycompany.com:5
022
TCP://W.corp.mycompany.com:5
022
SYNCHRONIZED
1
1
TCP://A.
.corp.mycompany.com:5022
TCP://W.corp.mycompany.com:5
022
mirroring_witness_state_d
CONNECTED
esc
CONNECTED
mirroring_failover_lsn
95000000007300001
95000000007300001
Note that each partner in the database mirroring session keeps all the same metadata, from that
partner's perspective. Each partner keeps its own database name, the safety setting of the entire
session, the mirroring state of the database, and two sequence counters.


The mirroring_safety_sequence counter is kept on both partners and is incremented
whenever the safety setting changes.
The mirroring_role_sequence counter is kept on both partners and the witness and is
incremented whenever a failover occurs.
Both partner database states and the witness state are kept by each partner server:


The mirroring_state_desc shows the state that the partner database has in the session.
The mirroring_witness_state_desc shows the state of the witness in the session.
Last, each partner contains the mirroring_failover_lsn. An LSN is a log sequence number, a
number which uniquely identifies each transaction log record. The mirroring partners store the
highest LSN +1 from the last set of log records that were hardened for the session. In the table
above, because there was little activity in the principal database, the mirroring failover lsn was
the same at both principal and witness. When a lot of data is being transferred, you may notice
that the principal's value will be ahead of the mirror's value, because the mirror will be running
somewhat behind.
Now let's compare the metadata found on the witness. The following table shows comparable
information from the witness server metadata:
Table 4: The output of sys.database_mirroring_witnesses on the Witness server, correlated
with partner metadata.
Witnessmetadatacolumn
Witnessvalues
database_name
AdventureWorks
safety_level_desc
FULL
safety_sequence_number
role_sequence_number
1
1
is_suspended
0
is_suspended_sequence_numbe
1
r
Corresponding
partnermetadatacolumn
db_name(database_id)
mirroring_safety_level_des
c
mirroring_safety_sequence
mirroring_role_sequence
principal_server_name
TCP://A.
.corp.mycompany.com:5022
mirror_server_name
TCP://B.corp.mycompany.com:502
2
Note that the witness server's metadata contains the safety description, the safety sequence
number, and the role sequence number, though under slightly different names. The witness also
keeps data about whether the session is suspended, and keeps the principal and mirror server
names. Note that the witness sever catalog view does not report the mirroring failover lsn, and it
does not keep the database states.
All the metadata required for database mirroring (in particular the mirroring failover lsn and
partner server names) are kept by the mirroring partners. The witness only keeps data necessary
for its role as a witness in a High Availability mode, in particular the role sequence number,
which tracks the number of role changes in the session. This counter is used to help decide when
a principal server can make a role change, as you'll learn in the scenarios in the next section.
Database Mirroring States and Transitions
Database states for each server are kept during the database mirroring session, recorded on each
partner server, and reported by the sys.database_mirroring catalog view. The mirroring_state
column returns a number for the state, and the mirroring_state_desc column returns the
descriptive name for the state. (For a complete list of database state numbers and descriptive
names, see "sys.database_mirroring" in SQL Server Books Online.) State information about the
witness is also reported from the same catalog view.
In addition to the states reported for each database, there are three phrases that are useful in
describing the servers and databases involved in database mirroring.



The data on the principal is exposed when it is processing transactions but no log data is
being sent to the mirror.
Cannot serve the database - When a principal server does not allow any user
connections to the database and any transactions to be processed.
A server is isolated when it cannot contact any of the other servers in the database
mirroring session, and they cannot contact it.
When a principal database is exposed, it is active with user connections and processing
transactions. However, no log records are being sent to the mirror database, and if the principal
should fail, the mirror will not have any of the transactions from the principal from the point the
principal entered the exposed state. Also, the principal's transaction log cannot be truncated, so
the log file will be growing indefinitely.
When a witness has been set, if the principal server cannot form a quorum with another server, it
will stop serving the database. It will not allow user connections and transactions on the
principal database, and will disconnect all current users. As soon as it can form a quorum again,
it will return to serving the database.
A server may be operational but communication lines are down between it and both other servers
in the database mirroring session. In that case, we'll call the server isolated. If a witness has been
set, then, if the principal server becomes isolated., it will no longer be able to serve the database,
because there is no server in the session with which it can form a quorum.
Now let's focus on the database mirroring states, starting with the principal server and database.
Principal Server Database States
When safety is FULL, the normal operating state for the principal database is the
SYNCHRONIZED state.
When safety is OFF, the normal operating state for the principal database starts as the
SYNCHRONZING state. Once the mirror has caught up, the state goes to SYNCHRONIZED
and stays there regardless of how far behind it is.


If safety is FULL, the principal database always starts off in the SYNCHRONIZING
state, and transitions to the SYNCHRONIZED state when the principal and mirror
transactions logs are synchronized.
If safety is FULL and the principal server is disconnected from the witness server but can
still process transactions, the database is exposed.
The following table shows the states that a principal database can be in, and some of the events
that can cause a transition to another state.
Table 5: Principal Database states with a witness set and with safety FULL and safety OFF.
Safety
Principal Initial
State
Event
Resulting State
Able to
Quorum Exposed serve
db
Synchronization
SYNCHRONIZED Y
occurs
FULL SYNCHRONIZED Session is paused SUSPENDED
Y
Redo errors on
FULL SYNCHRONIZED
SUSPENDED
Y
the mirror
Y, with
witness
Mirror
FULL SYNCHRONIZED
DISCONNECTED
unavailable
N, no
witness
OFF SYNCHRONIZING Session is paused SUSPENDED
Redo errors on
OFF SYNCHRONIZING
SUSPENDED
the mirror
FULL SYNCHRONIZING
N
Y
Y
Y
Y
Y
Y
Y
-
N
Y
Y
Y
Y
OFF
SYNCHRONIZING
Mirror
unavailable
Y, with
witness
Y
Y
-
N
DISCONNECTED
N, no
witness
Table 6 Principal Database states with no witness set and with safety FULL and safety
OFF.
Safety
Principal Initial
State
Event
Synchronization
occurs
FULL SYNCHRONIZED Session is paused
Redo errors on the
FULL SYNCHRONIZED
mirror
FULL SYNCHRONIZED Mirror unavailable
OFF SYNCHRONIZING Session is paused
Redo errors on the
OFF SYNCHRONIZING
mirror
OFF SYNCHRONIZING Mirror unavailable
FULL SYNCHRONIZING
Resulting State Exposed
Able to serve
db
SYNCHRONIZED N
Y
SUSPENDED
Y
Y
SUSPENDED
Y
Y
DISCONNECTED Y
SUSPENDED
Y
Y
Y
SUSPENDED
Y
Y
DISCONNECTED Y
Y
When safety is FULL, the principal first enters the SYNCHRONIZING state and as soon as it
synchronizes with the mirror, both partners enter the SYNCHRONIZED state. When safety is
OFF, the partner databases start with the SYNCHRONIZING state. Once the mirror has caught
up, the state goes to SYNCHRONIZED and stays there regardless of how far behind it is.
For both safety settings, if the session is paused or there are redo errors on the mirror, the
principal enters the SUSPENDED state. If the mirror becomes unavailable, the principal will
enter the DISCONNECTED state.
In the DISCONNECTED and SUSPENDED states:


When a witness has been set, if the principal can form a quorum with the witness or
mirror server, the principal database is considered exposed. That means the principal
database is active with user connections and processing transactions. However, no log
records are being sent to the mirror database, and if the principal should fail, the mirror
will not have any of the transactions from the principal from the point the principal
entered that state. Also, the principal's transaction log cannot be truncated, so the log file
will be growing indefinitely.
When a witness has been set, if the principal cannot form a quorum with another server, it
cannot serve the database. All users will be disconnected and no new transactions will be
processed.

When safety is OFF, the principal database is considered exposed, because no transaction
log records are being sent to the mirror.
Note: Management Studio's Object Explorer will report the principal database states next to the
database name in the Server tree graph. It will report a principal's SYNCHRONIZED state as
'Principal, Synchronizing' and the DISCONNECTED state as 'Principal, Disconnected.'
Mirror Server Database States
The mirror database has the same database states as the principal database, but because the
mirror is always in a nonrecovered state, it never serves the database while in the mirror role.
The following table shows the most common events that can cause a database state change for
the mirror server and database.
Table 7: Mirror database mirroring states with safety FULL and safety OFF.
Safety Mirror Server State
Event
Resulting State
FULL SYNCHRONIZING Synchronization occurs
SYNCHRONIZED
FULL SYNCHRONIZED Session is paused
SUSPENDED
FULL SYNCHRONIZED Redo errors on the mirror
SUSPENDED
FULL SYNCHRONIZED Principal database unavailable DISCONNECTED
OFF SYNCHRONIZING Session is paused
SUSPENDED
OFF SYNCHRONIZING Redo errors on the mirror
SUSPENDED
Just as with the principal, Management Studio's Object Explorer will report some of the mirror
database states next to the database name in the Server tree. It will report a mirror's
SYNCHRONIZED state as 'Mirror, Synchronizing' and the DISCONNECTED state as 'Mirror,
Disconnected.'
Witness Server States
The witness server has three states in the sys.database_mirroring catalog view, CONNECTED,
DISCONNECTED, and UNKNOWN.
Table 8: Witness server states (as recorded on the partner servers).
Witness Server State
Event
CONNECTED
Witness server unavailable
Resulting State
DISCONNECTED
Principal unable to initialize the mirror UNKNOWN
Since the state of the witness server is actually recorded in the partner servers, and not on the
witness server, these states are set from the vantage point of the partners. So seeing a
DISCONNECTED status for the witness server implies that the partners are disconnected from
the witness. When database mirroring starts up, if the mirror cannot initialize with the principal,
the witness will enter an UNKNOWN state.
Transferring Transaction Log Records
The sequence of operations that a principal and mirror SQL Server use in transferring messages
and blocks of log records varies depending upon the safety setting. First we examine the
synchronous transfer, then asynchronous.
When SQL Server records transaction events in the transaction log, the log records are briefly
put into a log buffer before being written to disk. In database mirroring, each time a log buffer is
written to disk (hardened), the principal sends the same block of log records to the mirror.

When safety is FULL, as the principal SQL Server hardens its block of log records, it
sends the same block to the mirror and treats both the local I/O to the log and the remote
mirror server's I/O to its log as essentially the same. The transfer is called synchronous
because the principal will wait for both its local I/O (hardening) and for the mirror's
response that it has completed its I/O (hardening) before the transaction is considered
completed.
Each time the principal or mirror hardens its log buffer, it records the highest log
sequence number (LSN) + 1 of the buffer in metadata as the mirroring_failover_lsn. The
mirroring_failover_lsn is used to negotiate the latest guaranteed point in the transaction
log, so that the two partner databases can synchronize initially and synchronize after a
failover.
The mirroring failover lsn will usually be ahead on the principal when the principal is
sending log records to the mirror. The mirror, as it hardens log records, will record its
mirroring_failover_lsn and respond back to the principal, but by the time the principal
receives acknowledgement from the mirror, the principal may have hardened a new set of
log records.
Table 9 shows a sample sequence of events between the principal and the mirror with
safety FULL.
Table 9: A Safety FULL (Synchronous transfer) example sequence of events.
Server A
Principal, Synchronized
A multi-statement transaction begins
containing data modifications
Transaction log records for the principal
database are inserted into a transaction log
Server B
Mirror, Synchronized
buffer
The transaction log buffer is written to
disk (hardened),
the block of log records is sent to the
mirror
and
the principal records the log block's
mirroring_failover_lsn
and
the principal waits for confirmation from
the mirror
The mirror server receives the block of log
records into a transaction log buffer
The mirror writes the log buffer to disk,
records the mirroring_failover_lsn,
and
notifies the principal that the log block has
been hardened
The principal receives notification that the
Mirror continues to replay transaction log
block of log records was written to disk by
records in its REDO queue
the mirror
A COMMIT for the transaction is entered
into the transaction log buffer
The transaction log buffer is written to
disk (hardened),
the block of log records containing the
COMMIT is sent to the mirror,
the principal records the block's
mirroring_failover_lsn
and
the principal waits for confirmation from
the mirror
The mirror server receives the block of log
records into a transaction log buffer
The mirror writes the log buffer to disk,
records the mirroring_failover_lsn,
and
notifies the principal that the log block has
been hardened
The principal receives notification that the Mirror replays transaction log records
block of log records was written to disk by including the COMMIT, from its REDO
the mirror
and
the transaction is considered committed
queue, changing data pages
New transactions are written to the
principal's log buffer.
The key point in the sequence above is that when safety is FULL, the principal server
hardens its log buffer and sends a copy of the log records from the buffer to the mirror,
both at the same time. It then waits for the completion of its own I/O and the I/O of the
mirror before considering the transaction complete. When the principal receives its
response from the mirror, the principal can then proceed to the next hardening.
Despite the close coordination between principal and mirror when safety is FULL,
database mirroring is not a distributed transaction and does not use a two-phase commit.
o

In database mirroring, you have two transactions being played out on two servers,
not one transaction distributed across them.
o Database mirroring does not use the partner servers as resource managers in a
distributed transaction
o Database mirroring transactions do not go through prepare and commit phases.
o Most importantly, unlike a distributed transaction, failures to commit on the
mirror will not cause a transaction rollback on the principal.
When safety is OFF, the principal does not wait for acknowledgment from the mirror
server, so the number of committed transactions on the principal can get ahead of the
mirror, as shown in Table 10.
Table 10: A Safety OFF (Asynchronous transfer) example sequence of events.
Server A
Principal, Synchronizing
Server B
Mirror, Synchronizing
A multi-statement transaction begins containing
data modifications
Transaction log records for data modifications
are written to a transaction log buffer
The transaction log buffer is flushed to disk
(hardened),
the block of log records is sent to the mirror
and
the principal records the block's
mirroring_failover_lsn
A COMMIT for the transaction is entered into a The mirror server receives the block of
transaction log buffer, along with other
transaction activity
log records into a transaction log buffer
The mirror writes the log buffer to disk,
The transaction log buffer is hardened to disk
records the mirroring_failover_lsn,
and
and
the log block containing the COMMIT is sent to
notifies the principal that the log block
the mirror
has been hardened
Mirror continues to replay transaction
The transaction is considered committed
log records in its REDO queue
The mirror server receives the block of
log records into a transaction log buffer
The mirror hardens the log block by
writing it do disk
and
records the mirroring_failover_lsn
and
notifies the principal that the log block
has been hardened
Database Mirroring Role Change
Database mirroring failover is an issue that can be considered from the standpoint of the database
mirroring servers or the application. From the standpoint of the database mirroring servers,
failover is the conversion of the mirror server into a principal server and the use of the newly
recovered database as the principal database in the session. The failover may be automatic,
manual, or forced.



Automatic - occurs only in the High Availability mode (safety is FULL and a witness is
part of the session
Manual - occurs in the High Availability and High Protection operating modes (safety is
FULL) and the partner databases are both SYNCHRONIZED.
Forced service (allow data loss) - used primarily in the High Performance (safety OFF)
mode to immediately and manually recover the mirror database.
When safety is FULL, the best way to reverse the roles of the servers is to use manual failover,
not forced service.
Automatic Failover
Automatic failover is a feature of database mirroring in the High Availability operating mode
(safety FULL with a witness). In most cases, SQL Server can accomplish an automatic database
mirroring failover in a few seconds. It can do this in part because the SQL Servers involved in a
database mirroring session all test each other's presence. This process is called a 'ping', though it
involves much more than an ordinary IP address ping. The mirror and witness servers contact the
principal server for the presence of the physical server, for the presence of the SQL Server
instance, and the availability of the principal database. Similarly, the principal and the witness
each ping the mirror server for availability of the physical server, the SQL Server instance, and
the recovering state of the mirror database.
Suppose the database mirroring session has been set up with safety FULL and with a witness
server. The mirror server, Server B, finds through its ping that the principal Server A is
unavailable. Server B communicates with the witness server and receives confirmation that the
witness also cannot see Server A. Then Server B will form a quorum with the witness server and
promote itself into the principal role. It will recover its database and notify the witness that it is
now has the principal role (though the database will be in a disconnected state, and the new
principal database's transaction log cannot be truncated)
Server B's new principal database continues to replay transaction log activity, but it has been in a
redo state continuously and in most cases there will be little left to do. In database mirroring for
all SQL Server editions, the new principal database becomes available as soon as it finishes its
redo state. When the database enters the undo state, it becomes available for user connections.
Finishing the redo state occurs normally in a few seconds, although the remaining undo phase
could be much longer. In database mirroring, the new principal database becomes available for
serving user connections as soon as the redo process is finished. The new principal server B's
database is in a DISCONNECTED state and is exposed, but it can place its database into service
just as soon as the redo phase is completed.
Usually it will take more time to redirect an entire application from the old principal to the new
principal than a database mirroring automatic failover will take. The application must detect and
retry connections, which may add some time to the process. In addition, if new logins using SQL
Server authentication have been added to the servers, you may need to map those logins to the
new principal using the system stored procedure sp_change_users_login. Complete application
failover may also be delayed if any critical objects on the old principal, such as SQL Agent jobs,
have not also been copied to the new principal server. (For more information, see "Preparing the
Mirror server for Failover" in the Implementation section later.)
Now suppose the old principal server comes online. There is a negotiation process that must
occur between the two servers if they are reversing roles, as in a manual failover, or an automatic
failover where the old principal is repaired fairly quickly. Before mirroring can restart, the two
partner servers need to find out how they can synchronize with each other. The mirroring
failover lsn plays a critical role in this process.
Server A (the new mirror) is behind, but it is not clear how much. Server A reports to server B
(the new principal) the last mirroring failover lsn that it received from server B. Server B, on the
other hand, has had committed work which has brought its mirroring failover lsn to a more
recent state. Both servers then agree that server B has the correct failover lsn, and that server A
must catch up to it. Server B sends a sufficient number of transaction records to server A that it
can replay in order to become synchronized.
Manual Failover
A manual failover is a way of causing the two partner servers to reverse their roles in an orderly
way and without any errors. It requires that safety be set to FULL, and that the principal and
mirror databases are in the SYNCHRONIZED state.
You cause a manual failover by invoking the ALTER DATABASE command on the principal
server:
ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;
or by clicking the Failover button in the Database Properties/Mirroring dialog in Management
Studio. A manual failover causes current users to be disconnected and rolls back any unfinished
transactions from the old principal database. It will recover the mirror database by finishing all
completed transactions in the redo queue, and rolling back (in the undo phase) unfinished
transaction. The old mirror is assigned the principal role, and the old principal database takes on
the new role of mirror. The two servers will negotiate a new starting point for mirroring based on
their mirroring failover lsns, and proceed with their roles reversed.
You can use a manual failover as a way of accomplishing a 'rolling upgrade' to the server
operating systems or SQL Server instances, provided you upgrade the mirror server first before
initializing mirroring. For more information, see 'Manual Failover' in SQL Server Books Online.
Forced Service
You can cause a forced service on the mirror by invoking the ALTER DATABASE command:
ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;
Normally this is only useful if you have safety OFF, and if the principal is no longer operating.
You can also use this command with safety FULL but if the recovered mirror server cannot form
a quorum, it cannot serve the database. Therefore it's better to use this command only with safety
OFF (the High Performance mode). Some data may be lost because the asynchronous data
transfer may not have kept the mirror fully up to date with committed transactions from the
principal.
Top Of Page
Database Mirroring Availability Scenarios
In this section you'll explore the expected availability outcomes of database mirroring scenarios
based on the following two types of events:


One or more servers or databases are down
One or more communication lines between server are broken
A server loss could occur when either one of the partner databases, or one of the SQL Server
instances, become unavailable. Alternately, the lines of communication between the database
mirroring partner servers may be interrupted, even though the servers themselves continue to
operate.
The following scenarios consider simultaneous failures of two components as a sequential
failure of one component followed by another. For example, if Servers A and B appear to fail
simultaneously, the mirroring system will treat that event as a sequence: Server A followed by
Server B, or vice versa.
You can use the following rules to determine the expected results of an unavailability event:
1. When a witness has been set, the principal server requires a quorum with at least
one other server to keep its database in service.
If a principal cannot form a quorum, it can no longer serve the database.
2. When safety is FULL, if neither the mirror nor the witness can see the principal, the
mirror server can form a quorum with the witness and change its role to become a
new principal server, assuming a the mirroring session was SYNCHRONIZED
when the principal went away.
This is an automatic failover.
3. When safety is FULL, if the principal has done work while in quorum with the
witness but disconnected from the mirror, a principal failure will not allow the
mirror to form a quorum with the witness and take on the role of a new principal
server.
This prevents work being lost by the session.
4. When safety is FULL, if a failed principal server rejoins a session after being down
or isolated, and the old mirror has previously taken on the role of new principal (in
quorum with the witness), the old principal will take on the role of new mirror in
the session.
During the failover event, the mirror and the witness incremented the mirroring role
sequence counter. Because the old principal's mirroring role sequence counter is less than
that on the other partner server and the witness server, those two servers have formed a
quorum before the old principal rejoined the session, and new work may have occurred
on the new principal. The old principal takes on the mirror role in the session.
5. When a witness has been set, the principal requires a quorum to serve the database.
If the witness has not been set (the status of the sys.database_mirroring column
“mirroring_witness_name” is NULL), then a quorum is not required by the
principal to serve the database.
No witness means that no automatic failover can occur. If there is no automatic failover,
there is never a problem with “split brain,” and the principal does not need to contact
another server to form a quorum.
High Availability Scenarios with Server Loss
The purpose of database mirroring in High Availability operating mode is to keep the database as
available as possible. In this mode, database mirroring will bring the mirror database into service
quickly if the principal database becomes unavailable. In the following set of scenarios, we begin
with a High Availability configuration with three independent servers.
In the following High Availability scenarios, Server A starts out as the principal, Server B is the
mirror, and Server W is the witness, as illustrated in Figure 1.
Figure 1: The sample database mirroring session starts in the High Availability operating mode.
Physically, all three servers may be on the same site and connected through a local network, or
they may be at independent sites connected through a WAN. Server A and Server B may change
roles, but Server W always remains the witness server.
Now consider what would happen if one of the servers goes down.
Scenario HASL1.1: Principal Server Loss
The following scenario considers what happens when the principal server is lost in a High
Availability scenario. Figure 2 shows the various roles and how they can change among the
partners.
Figure 2: In High Availability mode, when the principal Server A fails, a failover occurs.
After the principal server A is lost, the mirror and the witness servers form a quorum and an
automatic failover occurs. If you are able to bring back the original principal server, then it will
take on the mirror role.
Note: To cause a failover in High Availability mode, a failure could occur at many levels: the
physical server could be down, the SQL Server instance on the principal could be stopped or
failed, or the principal database on the server could be unavailable or suspect. When a principal
server is lost in the following scenarios, it could be cause by any of these events.
Because Servers B and W can form a quorum, and neither can see server A, Server B can
promote itself as the new principal. However, without a mirror server, the mirroring session is
considered exposed.
When you bring back Server A, it becomes the new principal and the mirroring session is no
longer exposed
A single server failure may be a rare event. An even rarer event would be to have two servers
fail. Even though rare, it is useful to inspect the results.
Two servers might fail simultaneously or nearly at the same time, but from the database
mirroring standpoint, the result will be as if one server failed followed by another. Therefore
these scenarios only consider what happens when servers fail in sequence.
The next two scenarios consider what occurs when the principal Server A failure is followed by
two alternate server failures:


a failure of the new principal Server B;
a failure of the witness Server W.
Scenario HASL1.2: Principal Server Loss followed by New Principal Loss
As you saw in the previous scenario, in the High Availability mode, if the principal server is lost
first, a failover occurs. Figure 3 shows that if the new principal server fails next, no matter how
you restore the servers, the new principal (Server B) keeps its principal role.
Figure 3: Role changes due to principal server loss followed by new principal loss.
After Server A fails, Server B becomes the new principal, but it cannot send data to a mirror, so
the principal is exposed, even though it can still serve the database. When a Server A failure is
followed by Server B failing, there is no mirroring because Server B is down.
If you bring back Server A first, it detects from the mirroring_role_sequence number at the
Witness W that the witness has since formed a new quorum. Server A adopts the role of mirror
and waits for Server B to come back. As soon as Server B is brought back, it will begin the
process of mirroring to Server A. If you bring back Server B first, then you are back to the
original scenario shown in HASL1.1.
Note: if Server W is lost after Server A and then Server B is lost, bringing all three servers
down, the switched roles for Server A and Server B will persist independently of the server
restoration sequence.
Scenario HASL1.3. Principal Server Loss followed by Witness Loss
When the principal server is lost, failover occurs. The witness server may fail next, as shown in
Figure 4.
Figure 4: When a witness server loss follows an initial principal server loss, the new principal cannot
serve the database.
When the witness server W is lost after the principal Server A is lost, the new principal Server B
is still the principal but it is isolated, cannot form a quorum, and cannot serve the database.
If you bring back Server A first, Server B's mirroring_role_sequence number will be one greater
than Server A's, because a failover has occurred. This indicates to Server A that Server B now
has the principal role after Server A did. Server A forms a quorum with server B and becomes
the mirror, and then both servers synchronize. Until Server W is brought back, no automatic
failover can occur.
Note: if Server B is lost after Server A and then Server W is lost, the new roles for Server A and
Server B will persist independently of the server restoration sequence.
Scenario HASL2.1 Mirror Server Loss
If the mirror server is lost first, the principal server is considered exposed because it cannot
send data to the mirror. Figure 5 shows how the roles behave when Server B, the mirror, is
lost.
Figure 5: In High Availability mode, when the mirror Server B fails, no failover occurs.
No automatic failover will occur and the partners will not exchange roles. When Server B is
restored, all three servers return to their original roles and states.
The following tables show the database states and quorum during the loss and recovery of the
mirror Server B.
Note that the session is exposed without a mirror, because the data is not being placed in
redundant databases.
As soon as you can restore Server B, it will resume its mirror role and when the two partners are
synchronized, the mirroring session is no longer considered exposed.
The next two scenarios consider what occurs when the mirror server B failure is followed by a
failure of the principal Server A or witness Server W.
Scenario HASL2.2: Mirror Server Loss followed by Principal Loss
When the mirror server is followed by a loss of the principal server, the roles of the partner
servers remain unchanged. Figure 6 shows how the roles change as you take various paths to
bring back the servers.
Figure 6: If a mirror server loss is followed by principal loss, the witness is isolated.
After Server B and then Server A are lost, the state is that shown in the upper-right corner of the
diagram.
If you bring back Server B first, it detects from the witness Server W that Server A is still the
principal and that a failover has not occurred - the mirroring_failover_lsn has not increased. As a
result, Server B remains the mirror. Then bringing back Server W restores the session to its
original state.
Note: if Server W is lost after Server B and then Server A are lost, bringing back the servers in
any order has the same result.
Scenario HASL2.3: Mirror Server Loss followed by Witness Loss
When a mirror server loss is followed by a witness server loss, the principal server is isolated and
cannot form a quorum with either other server. Therefore it must take its database out of service,
as shown in Figure 7 in the upper-right corner.
Figure 7: A mirror server loss followed by a witness loss leaves the principal server unable to serve the
database.
During the server outages of mirror followed by the witness, the principal Server A retains its
principal role, but because it cannot form a quorum with any other server, and safety is FULL, it
cannot serve the database, and disconnects all users.
If Server B is restored first, mirroring resumes, although no automatic failover is possible
without a witness.
If Server W is restored first, the scenario is the same as shown in Figure 5.
Note: if Server A is lost after Server B and then Server W were lost, bringing back the servers in
any order preserves the same final results.
Scenario HASL3.1: Witness Server Loss
When the witness server fails, mirroring continues but no automatic failover is possible. Loss of
just one more server will mean there is no quorum, and the principal database will no longer be
able to serve the database.
Figure 8: In High Availability mode, when the witness Server W fails first, mirroring continues.
When you restore Server W, the partner servers Server A and Server B keep their original roles.
The following tables show the changes of database state and quorum during the failure and
restoration of the witness server.
The next two scenarios consider what occurs when the witness server W failure is followed by a
failure of the principal Server A or mirror Server B.
Scenario HASL3.2: Witness Server Loss followed by Principal Loss
When the witness server fails first, mirroring continues, but no automatic failover is possible. If
just one of the remaining two servers fails, no quorum is possible and the remaining servers will
be isolated.
Figure 9: The partner roles remain the same after an initial witness server loss followed by a principal
server loss.
If you bring back server W first, Server B detects from the witness that the last good principal
was server A and so Server B remains the mirror. When you finally bring back Server A it keeps
the principal role.
Note: if Server B is lost after Server W and then Server A were lost, bringing back the servers in
any order will not affect the end results
Scenario HASL3.3: Witness Server Loss followed by Mirror Loss
If the Witness server fails, and then the Mirror server fails, the principal server becomes isolated.
Since safety is FULL and the principal is unable to form a quorum, it can no longer serve the
database, as shown in Figure 10.
Figure 10: When the Witness server fails, followed by the Mirror server, the principal must take its
database out of service.
Note: if Server A is lost after first Server W and then Server B are lost, bringing back the servers
in any order will not affect the final results.
Summary: High Availability Scenarios with Server Loss
There are a number of conclusions to draw from these scenarios. In the High Availability
operating mode:
1. If the principal server becomes unavailable first, an automatic failover will occur and the
former mirror server will take on the principal role and make its database available for
user activity. Subsequent server failures and restores will not affect the overall
configuration of the mirroring with the new principal. Mirroring will continue in the
reverse direction.
2. If the mirror server becomes unavailable first, an automatic failover will not occur.
Subsequent server unavailability, and the restoration sequence, will not affect the
mirroring partner roles.
3. If the witness becomes unavailable first, no automatic failover is possible, and the partner
servers will keep their original roles. Subsequent server unavailability and restoration will
not affect the partner roles.
The following table summarizes the results for High Availability scenarios where one or two
servers are lost. The conditions assumed in the table are that safety is FULL and that the
mirroring session servers have the following conditions:
A: Principal, SYNCHRONIZED
B: Mirror, SYNCHRONIZED
W: Witness, CONNECTED
The table shows the failover scenario highlighted in grey.
Table 11: A summary of single and dual server failures, showing partner server roles and
database states.
High Availability Scenarios with Communication Loss
The High Availability operating mode requires three SQL Sever instances. If the servers are at
two or three independent sites with significant distance between them, it is quite possible that
there may be communication problems between the sites. In other words, the servers may stay
available but the communication lines may be interrupted. These scenarios are a little more
complex than the previous set but the principles to apply are the same.
The following High Available operating mode scenarios with communication loss are covered in
two sets. The first set is based on three SQL Server instances on independent sites, and therefore
with three independent communications lines. The second set is based the servers being on two
independent sites, with one communication line between a pair of servers and a third.
Starting with the first set, assume you have three independent communication lines between all
the servers in a database mirroring session. For example, the principal, mirror, and witness could
be located at three independent co-location sites. (It is also possible that the three servers could
be on one site but be connected by private networks.)
The initial conditions are that Server A houses the principal database and has synchronized with
Server B as its partner, which has the mirrored database. Safety is set to FULL, and a witness
server (Server W) is part of the database mirroring session. Figure 11 shows this initial
configuration.
Figure 11: The initial High Availability configuration for three independent servers has three
independent communication lines
Note: for an explanation of the diagrams on the following pages, see "High Availability Mode
with Server Loss" above.
Based on Figure 11, there are three different lines that could break first: A/B, A/W, and B/W.
Note that when a single communication line is down all three servers still operate. Only the line
between the principal and the mirror has any effect, as shown in Table 12.
Table 12: Summary of single-line communication line breaks.
Initial condition
Event
A: Principal,
A/B link
SYNCHRONIZED
broken
Quorum
A and W
Result
Database on A in service,
exposed
Condition
A: Principal,
DISCONNECTED
B: Mirror,
SYNCHRONIZED
B: Mirror,
DISCONNECTED
W: Witness,
CONNECTED
W: Witness,
CONNECTED
A: Principal,
SYNCHRONIZED
A/W
A and B Database on A in service
B: Mirror,
SYNCHRONIZED
W: Witness,
CONNECTED
A: Principal,
SYNCHRONIZED
B/W
A and B Database on A in service
B: Mirror,
SYNCHRONIZED
W: Witness,
CONNECTED
Only the break in the principal/mirror connection has an effect. The other breaks of
principal/witness or mirror/witness do not change the database mirroring session's behavior.
In summary, what Table HACL1 shows is:

Only a principal/mirror break, among single-line communication breaks, affects database
mirroring. The principal runs exposed, because no log records are sent to the mirror.
Now consider what happens if a second line breaks. The two lines could break simultaneously,
or in sequence.
If two line breaks occur simultaneously, the end result will the same as one line breaking
followed by the other. However, the exact sequence is unpredictable beforehand; only the
subsequent behavior will indicate the sequence to which the simultaneous break will be
equivalent.
For our purposes, therefore, we will only consider sequential line breaks. Table 13 shows the
basic scenarios, as named in this section, for communication line breaks in the High Availability
Mode.
Table 13: Most of the communication line breaks at the two-line level become equivalent to
the server-down scenario of one server down.
First line
Second line
Scenario
Result
break
break
Server
HACL1.1 A and W HACL1.2 A/W
A
isolated
Server
HACL1.3 B/W
B
isolated
Server
HASL2.1 A/W
HASL2.1 A/B
A
isolated
Server
HASL2.2 B/W
W
isolated
Server
HACL3.1 B/W
HACL3.1 A/W
W
isolated
Server
HACL3.2 A/B
B
isolated
Scenario
Equivalent scenario for
remaining servers
See
scenario
Server A
down
(none)
Server B
down
HASL2.1
Server A
down
HASL1.1
Server W
down
HASL3.1
Server W
down
HASL3.1
Server B
down
HASL2.1
What Table HACL2 shows is that all sequential two-line communication breaks are equivalent to
the single-server-down scenarios of the previous section, so we won't repeat any analysis of them
here.
What is important to note is that:

Only one scenario with two communication breaks leads to a failover: the
principal/witness line break followed by the principal/mirror line break.
When the principal/mirror line breaks, followed by the principal/witness, no failover results,
even though the principal server is isolated, and the mirror and witness cannot see it.
Let's examine scenario HACL1.2 more carefully
Scenario HACL1.2: Principal/mirror link broken followed by principal/witness link broken
If the principal/mirror link is broken, followed by a break in the link between the principal and
the witness, then the principal becomes isolated. It cannot see the other servers and loses its
quorum. In the meantime, the mirror and witness do not know whether the principal server is still
up, so server B takes on the role of principal and an automatic failover occurs. Figure 12
illustrates these events.
Figure 12: In High Availability mode, when the principal/mirror link is broken and followed by a break
in the principal/witness line, no failover occurs
After the principal/mirror link is broken, followed by the principal/witness break, Server A is
isolated and takes its database out of service. Server B and W do not form a quorum because
Server A may have done work that is not on Server B.
If the principal/witness (A/W) line break is repaired first, Server A will resume its principal role,
in a DISCONNECTED state. However, no mirroring will be occurring because there the line
between the principal and the mirror is still not repaired.
If the principal/mirror (A/B) line break is repaired first, Server A will resume its mirroring to
Server B although without a witness, so the session is exposed. However, no automatic failover
is possible until the principal/witness line is finally repaired.
Summary: High Availability Scenarios with Communication Loss: Three Sites
The following table summarizes the behavior of one and two-line breaks with three independent
servers. The initial conditions for the table are that the Safety level is FULL and the servers are:
A: Principal, SYNCHRONIZED
B: Mirror, SYNCHRONIZED
W: Witness, CONNECTED
The failover scenario path is highlighted in grey.
Table 14: Summary of one-line and two-line breaks for Safety FULL and three
independent servers in the High Availability mode.
Scenario HACL4: Two sites with the witness on the mirror site
When there is only one line of communication between the sets of servers, you must choose
where to put the witness server. To start with, assume you put the witness with the mirror
database server. There will be just one line of communication between the two sets of servers,
and it line may be interrupted, as shown in Figure 13.
Figure 13: The communication line between the principal and the mirror/witness site is interrupted.
Server A cannot see the witness Server W or the mirror database's Server B, and therefore cannot
form a quorum. Server B and Server W can form a quorum, but neither can see the principal on
Server A. The result of the line break is illustrated in Figure 14.
Figure 14: Failover occurs when communication is interrupted and the witness is on the mirror site.
Because Server A cannot see the witness Server W or its former mirror partner Server B, it must
enter a disconnected state and make its database unavailable.
Server B and Server W can form a quorum. Server B cannot see Server A, and Server W Server
B attempts to become the principal and bring its database online. Because Server W cannot see
Server A, it agrees with Server B. Server B now has a quorum, takes on the principal role in this
session, and recovers its database.
If you restore the communication line, Server A will see that Server B is a principal, and it will
also detect that the witness Server W views Server B as the principal. Server A will change its
role to that of mirror, and attempt to synchronize with new principal. When done, the resulting
configuration is illustrated in Figure 15.
Figure 15: The restored version of this scenario has mirroring in the reverse direction.
To summarize: When the witness resides on a remote site with the mirror, automatic failover will
occur if the communication line between sites is interrupted.
Scenario HACL5: Two sites with the witness on the principal site
In this High Availability scenario, assume you put the witness server on the same site as the
principal database's server, as shown in Figure 16, and the communication between the two sites
is interrupted.
Figure 16: Communication between the principal/witness and mirror is interrupted.
In this case, Server B that houses the mirror database is isolated from the principal and the
witness. Server A and Server W continue to form a quorum, so Server A keeps its database as the
principal. However, Server A also puts the database into a disconnected state, because it cannot
see Server B and no data transfer is possible. Server B also cannot see Server A, so it goes into a
disconnected state as well. The resulting configuration is shown in Figure 17.
Figure 17: Loss of communication in this scenario results in both partners disconnected.
Server A continues to accept transactions but its transaction log cannot be truncated. If you
restore the line quickly, the mirroring session will be able to resynchronize and return to the
original operating state.
To summarize: with the witness server on the same site as the principal, and the mirror on a
remote site, communication interruption between sites will not cause an automatic failover.
Summary: High Availability Scenarios with Communication Links Broken
In a High Availability configuration with three independent servers, there are three independent
lines of communication.



When a principal/mirror communication loss occurs, no automatic failover will occur.
When a principal/witness communication loss occurs first, and is then followed by a
principal/mirror communication break, automatic failover will occur. Restoring the lines
will preserve the reverse direction of the mirroring.
When a mirror/witness communication loss occurs, no automatic failover will occur.
In a High Availability configuration with only one line of communication, the witness server
resides either with the principal or the mirror.


When the witness resides on a remote site with the mirror, automatic failover will occur if
the communication line between sites is interrupted.
When the witness server is on the same site as the principal, and the mirror on a remote
site, communication interruption between sites will not cause an automatic failover.
High Protection Scenarios
The High Protection operating mode works with safety FULL, but with no witness. Because only
a server with a principal database and a server with a mirror database are involved, there is only
one line of communication between them. This dramatically reduces the number of scenarios.
Case 1. In the High Protection operating mode, only two SQL Server instances are involved, the
principal and the mirror. Because there is no witness, automatic failover is not possible. There is
only one communication line between the servers, and it can be interrupted, resulting in the
configuration illustrated in Figure 18.
Figure 18. When communication is interrupted in a High Protection scenario, both partners become
disconnected but the principal still serves the database.
Because a witness has not been set, the principal does not need a quorum with the mirror, the
principal serves the database as normal.
Case 2. If the mirror database becomes unavailable in a High Protection scenario, the principal is
the same as in the above scenario, as shown in Figure 19.
Figure 19: If the mirror server is unavailable in a High Protection scenario, the principal database is
unaffected.
Case 3. If the principal database becomes unavailable in a High Protection scenario, the mirror
database must remain a mirror, but it will be in a disconnected state, as shown in Figure 20.
Figure 20: If the principal becomes unavailable in High Protection, the mirror database will enter a
disconnected state.
Because the High Protection operating mode does not have a witness set, disruptions do not
cause the principal database to become unavailable, and the mirror database remains in a
recovering state.
High Performance Scenarios
The High Performance operating mode works with safety OFF. No role is played by a witness
server. Only a server with a principal database and a server with a mirror database are involved,
and there is only one line of communication between them.
Case 1. In the High Performance operating mode, two SQL Server instances are involved. One
houses the principal database and the other contains the mirror database. Therefore there is only
one communication line between the servers, and it can be interrupted, resulting in the
configuration illustrated in Figure 21.
Figure 21: When communication is interrupted in a High Performance scenario, both partners become
disconnected but the principal database remains available.
Because no witness has been set, Server A does not require a quorum to keep its database
available. Therefore the principal, though disconnected, continues to accept user activity. If you
restore communication, the mirror database will attempt to catch up but may not be able to, or
may be subject to redo errors if it cannot retrieve all the missing transactions.
Case 2. If the mirror database becomes unavailable in a High Performance scenario, the result for
the principal is shown in Figure 22.
Figure 22: If the mirror server is unavailable in a High Performance scenario, the principal database is
unaffected.
The principal database remains available because safety is OFF.
Case 3. If the principal database becomes unavailable in a High Protection scenario, the mirror
database remains a mirror, but it will be disconnected, as shown above in Figure 23.
Figure 23: If the principal becomes unavailable, Server B is unaffected but enters a disconnected state.
In the High Performance operating mode, just as in High Protection, no automatic failover is
possible. Because no witness has been set, the principal server keeps its database available when
the mirror becomes unavailable. Also because safety is OFF, transactions are not guaranteed to
reach the mirror. Some transactions may be lost if you force a failover to the mirror.
It is not recommended to run with the safety OFF and a witness set. The witness cannot provide
automatic failover, because the safety is not FULL. Furthermore, if the witness and the mirror
are unavailable, then the principal has lost quorum and brings its copy of the database offline.
Top Of Page
Implementing Database Mirroring
Basic information about implementing database mirroring can be found in the SQL Server 2005
Books Online, under "How To" topics for database mirroring. In this section of this white paper,
we'll look at a particular example of a database mirroring implementation, along with some best
practices.
Monitoring Database Mirroring
You can detect the state of each database mirroring partner by examining the principal or mirror
databases in SQL Server 2005 Management Studio's Object Explorer. If the principal is
synchronized with the mirror, Object Explorer will append a (Principal, Synchronized) message
next to the principal database name, and (Mirror, Synchronized) next to the mirror server's name.
You can also inspect the status of a database mirroring session by observing the Status box of the
Mirroring page of the Database Properties dialog when invoked from the principal server. (The
Database Properties dialog will not open on the mirror database.)
You can also query the database mirroring catalog views, sys.database_mirroring and
sys.database_mirroring_witnesses. (For more information about using the catalog views to
inspect the database states in a mirroring session, see "Database Mirroring Catalog View
Metadata" in the Database Dynamics section previously in this paper. The catalog views are also
fully documented in SQL Server Books Online.)
Database Mirroring Perfmon Counters
You can use Perfmon counters to monitor traffic between the partners in a database mirroring
session. The SQL Server Database Mirroring object contains a number of useful Perfmon
counters for the principal and witness servers. (See "Monitoring Database Mirroring" in SQL
Server Books Online.)
Each counter in the Database Mirroring object can be set per database. If you are mirroring more
than one database on a server, you can measure the activity of each database individually as well
as the total mirroring activity across all the databases.
For the principal server, the Log Bytes Sent/sec counter will tell you the rate at which the
principal is sending transaction log data to the mirror, while the Log Send Queue shows you how
many bytes in the transaction log buffer are yet to be sent to the mirror at any given point in
time. As transaction log data is sent from the principal to the mirror, the principal's Send Queue
will be depleted, but it will also grow as new log records are entered into the log buffer. The
Transaction Delay counter on the principal will show the delay the principal is experiencing due
to waits for acknowledgment of log records received by the mirror database. The Pages Sent/sec
relates to the principal sending data pages to the mirror to assist in synchronization.
On the mirror server, the Log Bytes Received/sec shows how well the mirror is keeping up with
the principal (see the Log Bytes Sent/sec counter above). The Redo Queue counter shows the
size of the redo queue that the mirror uses to replay transactions from the principal during its
ongoing redo phase. The Redo Bytes/sec shows you the rate at which the mirror is able to replay
those transactions from its redo queue.
For each partner, the Sends/sec and Receives/sec counters show the number of discrete send and
receive actions, giving gives you a sense of the rate at which the servers are communicating. The
Bytes Sent/sec and Bytes Received/sec counters show the total number of bytes sent and received
on each partner server for those sends and receives.
Estimating Redo and Catch-up Time
You can use values from the Redo Queue and Redo Bytes/sec to estimate the time it should take
the mirror database to finish a redo and become available, should a failover occur. The estimate
consists of the following simple formula:
Estimated time to redo (in seconds) =
(Redo Queue)/(Redo Bytes/sec)
Similarly, you can use the Log Send Queue and Log Bytes Received/sec counters to estimate the
time it should take the mirror to catch up with the principal, if activity on the principal has gotten
ahead and has since quieted down. The estimate is given by the following formula:
Estimated time to catch up (in seconds) =
(Log Send Queue)/( Log Bytes Received /sec)
Profiler Events
SQL Server 2005 Profiler contains one event class for database mirroring. The
Database:Database Mirroring State Change event will record whether the server being monitored
undergoes a state change. (See the topic "Database Mirroring State Change Event Class" in SQL
Server Books Online.) It is helpful to include the Database Name and the State columns when
using this event class. You can use this event to alert you to any state change in the database
mirroring session.
Troubleshooting Database Mirroring
Two areas where errors are most likely to occur are during setup and during run-time.
Troubleshooting Setup
If you've installed database mirroring but it won't start, retrace the steps that you took during
setup.
1. Make sure that the mirror server has caught up close enough in time to the principal. If
you see the following message when you attempt to start mirroring,
The remote copy of database "AdventureWorks" has not been rolled forward to a point in
time that is encompassed in the local copy of the database log. (Microsoft SQL Server,
Error: 1412)
you know that the mirror is not caught up. You need to apply transaction log backups
from the principal to the mirror (with NORECOVERY) in order to catch the mirror up to
a point where it can start receiving log records from the principal.
2. Make sure that the SQL Server Windows service accounts on each server are trusted on
each other server. If the servers are on non-trusted domains, make sure the certificates are
correct.
3. Make sure that the endpoints are not just defined, but also started, by querying the
sys.database_mirroring_endpoints catalog view:
4. SELECT * FROM sys.database_mirroring_endpoints;
Also make sure that the fully qualified computer names are correct, and the port numbers
are correct. If you are mirroring among instances that are on a single physical server, the
port numbers must be unique. Each SQL Server service login should have CONNECT
permission to the endpoint.
Finally, make sure that each endpoint role has been defined properly for the server as you
intended their roles.
5. Make sure you have identified the correct partner names in the ALTER DATABASE
commands. You can inspect the partner names in the sys.database_mirroring catalog
view on the principal and mirror (and sys.database_mirroring_witnesses witness if in
High Availability mode).
Troubleshooting Runtime Errors
If database mirroring has been set up correctly, and running, and then an error occurs, check the
current status of the session. If was put in a SUSPENDED state due to the error, redo errors may
have occurred on the mirror. Check to make sure there is sufficient disk space on the mirror for
both redo (free space on the data drives) and for log hardening (free space on the log drive).
When you are ready to restart the session, use ALTER DATABASE to RESUME the session.
If you cannot connect to the principal database, it is most likely because safety is FULL and the
principal server cannot form a quorum. This can happen, for example, if your system is in High
Protection mode (safety is FULL, but there is no witness), and the mirror has become
disconnected from the old principal. You force the mirror server to recover, using the following
command on the mirror:
ALTER DATABASE [AdventureWorks] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
The problem is that once you've recovered the mirror database, it becomes a principal server but
cannot form a quorum, and so it cannot serve the database. In that case, just set safety OFF to
allow it to serve the database.
Safety vs. Performance
Database mirroring performance is a function of the type of activity and the transactional safety
setting.
The performance of the principal server is affected by the transfer of log records to the mirror.
The overhead that database mirroring places on a principal server is a function of the type of
activity. Database mirroring will perform best with many long transactions by many users,
because the normal transactional activity of the database server will mask the overhead of
transferring log records to the mirror. When a single user is issuing a large number of small
transactions in sequence, the overhead of database mirroring for each transaction will become
more prominent.
Performance of the principal server will also be affected by the Safety setting. When safety is
FULL, the principal must wait for an acknowledgment by the mirror that it has received log
records before it can issue a transaction commit message back to the client. With many users and
long transactions, that overhead will be inconsequential. Systems with single threads and many
small transactions may operate better with safety OFF.
Because the mirror server is continuously replaying data modification transactions that it
receives from the principal, the data cache on the mirror server will be 'hot'. In other words, the
data cache will be populated with data and index pages based on the same kinds of changes made
on the principal. To make the mirror cache even more like the principal's cache, database
mirroring also passes SELECT hints to the mirror so that the cache used for querying data also is
reproduced on the mirror server. This will aid in making the mirror more like the principal and
will reduce the remaining redo time in the case of a failover. Obviously, any additional activity
on the mirror server, including queries against database snapshots, will affect the state of the
cache and could increase the duration of time to finish the redo phase in the event of a failover.
Testing Database Mirroring
When setting up your own systems to test database mirroring, you have a number of options
available. All mirroring requires is that the servers in the database mirroring session must be
distinct SQL Server instances. Therefore you can learn about and test database mirroring on a
single physical server, if you install multiple instances of SQL Server 2005's relational engine.
You can also test multiple instances in a single virtual server, but your tests will be more reliable
if done on a physical server.
When testing database mirroring for load or stress purposes, you will need distinct physical
servers. Two or three instances on a single server may consume an unrealistic share of the
physical server's resources. Equally important is good connectivity between servers. The better
the network connection between the principal and the mirror, the better the transfer rates for log
records and messages will be.
The most realistic testing will be on the actual target servers or on a test bed that has the same
physical properties as your final system. When you test with multiple instances on a single
server, you can only simulate the effects of server loss on database mirroring, by stopping one of
the instances or shutting down a machine. With multiple physical servers, you can also test the
loss of connectivity by disconnecting a network cable.
The following practices may assist you in creating test conditions:







To test a server failure, just shut down the SQL Server instance, either through SQL
Configuration Manager or using SHUTDOWN WITH NOWAIT.
To test a communication failure, remove a network cable from the server.
To test a database failure, stop the SQL Server service and rename the underlying .mdf
file, and then restart the SQL Server.
To cause a redo error on the mirror, add a file to the principal database on a driver
volume that does not exist on the mirror server.
Another way to cause a redo error on the mirror is to force the mirror server data file to
run out of disk space.
To force a database shutdown on the principal, force the principal's data file to run out
disk space.
To cause a log buffer hardening to fail on the principal or mirror, force the log file to run
out of disk space.
Preparing the Mirror server for Failover
Database mirroring is strictly a database-to-database relationship. Only database data is sent
using the log records from the principal to the mirror. Just as with log shipping and replication,
you must prepare the standby server with the mirror database to fully take over in the event of a
failover. There are several levels to consider when preparing the mirror server.
At the physical server level, you should make sure that the standby server has the same physical
CPU and memory configuration, or as close as possible, or else the standby will under perform
after a failover. You may also have supporting applications, monitors, or other executables that
support the database applications and must be configured on the mirror server
At the SQL Server level, you should also ensure that the standby has the same SQL Server
configurations (for example, AWE, max degree of parallelism). But most fundamental will be
the logins and their permissions. All active SQL Server logins on the principal server must also
be present on the mirror server or the application will not be able to use it as the new principal
server in the event of a failover. SQL Server Integration Services has a Transfer Logins task that
you can use to copy logins and passwords from one server to another, but you may still need to
set database permissions for those logins. If you transfer logins to a server in a different domain,
the SIDs may not match and you will need to match them.
There are numerous support objects that may exist on the principal SQL Server that you will
need to migrate to the standby server: SQL Agent jobs and alerts, SQL Server Integration
Services packages, support databases, linked server definitions, backup devices, maintenance
plans, SQL Mail or Database Mail settings, and possibly Distributed Transaction Coordinator
settings, to name a few.
When SQL Agent jobs are transferred to the standby server, most will have to remain disabled.
In the event of a failover, you will need to enable those jobs.
After a failover, if your application is using SQL Server authentication, you will need to resolve
the logins on the new principal SQL Server with the users on the new principal database. The
best tool for this is the stored procedure sp_change_users_login.
Multi-Database Issues
Many applications make use of multiple databases on a single server. One application may
reference multiple databases, or perhaps many applications all make use of several databases.
However, database mirroring works with a single database at a time. You need to take this into
account when designing mirroring into your database architecture.
If you desire the High Availability mode, your best fit will be when one application matches up
with one database. Then if an automatic failover occurs, the application no longer requires any
databases on the principal server. Consider what might happen if you have multiple databases on
a single server and operate in the High Availability mode. If there is a physical server outage, a
SQL Server instance failure, or a communication failure, all the databases would automatically
fail over to the standby server, and their mirrors would then become new principal databases. If
the witness is visible, the application could connect to the new principal databases. But what
would happen if one of the databases incurred a torn page from a disk fault, so that only the one
database failed over? In that case, it might be impossible to get the application to connect to all
the right databases.
Therefore applications that rely on multiple databases will not be good candidates for the High
Availability mode of database mirroring. You may be able to use safety OFF, with the realization
that you will not have automatic failover, but you will have a high-performance method of
keeping another database server in sync.
Top Of Page
Database Mirroring and High Availability Technologies
SQL Server 2005 now has at least four high availability technologies, and while there is some
overlap, each technology has its own relative advantages and disadvantages. Those technologies
are




Database Mirroring - For this discussion, we will be considering the High Availability
operating mode with safety FULL and a witness.
Failover Clustering - The most typical configuration is a two-node Windows failover
cluster with one SQL Server instance.
Log Shipping - Assume SQL Server built-in log shipping with a separate monitoring.
Transactional Replication - Consider a configuration with a separate distribution server
and one subscriber which serves as the standby server if the publisher server fails.
In this section we'll compare the basic features of those four technologies, and drill down into
areas where database mirroring may complement or prove a better solution.
The following table shows a number of availability features for all four technologies.
Table 15: Comparing SQL Server 2005 High Availability technologies.
The above table summarizes many of the characteristics of all four high availability technologies.
The next sections make some more detailed comparisons.
Database Mirroring and Clustering
The most important contrast between database mirroring and failover clustering is the level at
which each provides its redundancy. Database mirroring provides protection at the database
level, whereas clustering provides protection at the server instance level. Another important
difference is that in database mirroring, the principal and mirror servers are separate SQL Server
instances with distinct names, whereas a SQL Server instance on a cluster gets one virtual server
name and IP address that remains the same no matter what node of the cluster is hosting the
instance.
If you need database protection at the server level (for example, your application requires access
to many databases on the same database server simultaneously), failover clustering may be a
more appropriate choice. However, if you are concerned to provide availability for one database
at a time, database mirroring has a number of advantages.
Unlike clustering, database mirroring does not require proprietary hardware and does not have a
potential failure point with shared storage. Database mirroring brings the standby database into
service much faster than any other high availability technology, and works well with new
capabilities in ADO.NET and SQL Native Access Client for client-side failover.
You cannot use database mirroring within a cluster, but you may consider using database
mirroring as a method for creating a hot standby for a cluster instance database. If you do, be
forewarned that because a cluster failover is longer than the timeout value on database mirroring,
a High Availability mode mirroring session will react to a cluster failover as a failure of the
principal server. It would then put the cluster node into a mirroring state.
Database Mirroring and Transactional Replication
Database mirroring and transactional replication are both based upon reading the transaction log
of an originating server, but after that their technologies diverge considerably. (For more details
about transactional replication, see the associated topics in SQL Server Books Online.)
Transactional replication is often used for high availability because it can deliver user
transactions from a publisher database to a subscriber in matters of seconds. Database mirroring
has the advantage that it is as fast as or faster than replication, but delivers all of a database's
transactions, not just those related to user tables.
Transactional replication is an appropriate technology for scaling out data to multiple subscribers
for reporting. Transactional replication subscriber databases are normally considered read-only
anyway, so they are ideal candidates when access to near-real-time data is required.
Database mirroring is compatible with transactional replication, and is most useful as method of
keeping a hot standby of a publisher database. Other methods of protecting a replication
publisher, such as log shipping, cannot keep a standby server for the publisher ahead of the
publisher's own subscribers. In other words, transactional replication can deliver transactions to
its subscribers much faster than a transaction log backup scheme. Because database mirroring is
so fast, it is much more suitable for keeping a hot standby of a publisher database.
If the publisher should fail, however, you will have to manually re-establish the recovered
standby database as the publisher, and reconnect it to the distribution server, just as you must
currently do if using log shipping to maintain a publisher server standby.
Database Mirroring and Log Shipping
Database mirroring and log shipping both rely on the restore and recovery capabilities of SQL
Server databases. A database mirroring mirror database is in a constantly recovering state, more
or less continuously replaying transactions from the principal. A log shipping secondary replays
transactions applied to it periodically from transaction log backups. Because bulk-logged data is
appended to a transaction log backup, log shipping can work in the bulk-logged recovery model.
Database mirroring, on the other hand, transfers log records directly from the principal to the
mirror and cannot deliver bulk-logged data.
In many cases database mirroring can provide the same kind of data redundancy as log shipping
with higher availability and automatic failover. However, if your application relies on multiple
databases on one server, log shipping may be an equally valid approach (see "Multi-Database
Considerations" in the previous section).
Additionally, there are database mirroring scenarios where log shipping may supplement
availability. For example, you could have a High Availability database mirroring configuration
in-house, and log ship the principal server to a remote site for disaster recovery purposes. Figure
24 illustrates how such a configuration might take place.
Figure 24: You may log ship a principal database to a remote location.
The advantage here is that in the event of a loss of the entire site, the data is available on the
secondary site. However, in the event of a database mirroring failover, log shipping from Server
B to the remote standby will normally have to be reinitialized.
Another scenario for using log shipping to complement database mirroring would be as a local
standby for the principal server where the database mirroring session is being used for disaster
recovery. In this case, the mirroring session is in the High Performance mode, with the mirror on
a remote site as the remote standby.
Figure 25: You can log ship a principal database as a method of preserving all transactions.
In the High Performance mode, there is a potential for data loss if the principal fails and the
mirror is recovered using a forced service recovery. If you are log shipping the old principal, and
if the transaction log file of the old principal is undamaged, you can make a 'tail of the log'
backup of the principal to get the last set of log records from the transaction log. If the standby
log shipping database has had every other transaction log backup applied to it, you can then
apply the tail of the log backup to the standby server and not lose any of the old principal's data.
You can then compare the data in the log shipping standby server with the remote database and
potentially copy missing data to the remote server.
In any case, comparing log shipping to database mirroring should make it clear that it is
important to keep database and transaction log backups of the principal database. Applying
these log backups to a log shipping server can supplement your database mirroring configuration.
Top Of Page
Conclusion
Database mirroring is a new SQL Server 2005 technology that can deliver high availability and
high performance solutions for database redundancy. In database mirroring, transaction log
records are sent directly from a principal to a mirror database whenever the principal's
transaction log buffer is written to disk (hardened). This technique can keep the mirror database
nearly up to date with the principal, and with no loss of committed data. In the High Availability
operating mode, if the principal fails, the mirror server will automatically become a new
principal and recover its database. Using the new ADO.NET or SQL Native Access Client
drivers, applications can also perform an automatic failover from the client servers as well.
Database mirroring becomes an important new option in the array of high availability
technologies supported by SQL Server 2005.
The motive for backing up SQL Server data and systems hasn't changed much over the years:
Protect the assets. The threats to those assets have diversified, as have specific recovery
requirements. Today, the assets you're protecting often include application availability, not just
data.While physical loss of data is always a concern, theft or other misappropriation is climbing
up the list. Needs to maintain application availability, to stash copies of data in safe, remote
locations, and to be able to readily recover data have given rise to new SQL Server 2005
features, as well as new backup and recovery strategies. Let's take a look at some of these.
Old and New Backup Options
As you might expect, enhancements to SQL Server 2005 are driving updates to SQL Server
backup software—and driving users to look at new ways to address their varying requirements
for data protection and rapid restoration. Database mirroring is new to SQL Server 2005. The
feature streams SQL Server transaction logs to a mirror server, maintaining a second database
and allowing connections to the mirror server when the principal server fails. Native encryption
of both database storage and client-server communications is also new to SQL Server 2005.
There are several ways to back up SQL Server data. Traditional backup software vendors have
always supported backing up to tape. For a number of reasons, backing up to disk has become a
viable, popular option both as a primary storage medium and as a means of staging data for
backup to offline or near-line media.
Several vendors of continuous data protection (CDP) products now offer specific support for
SQL Server. (See below for more information about CDP.) Backup appliances and data
mirroring appliances are other niche markets. Small businesses and users with desktop database
applications can opt for one of the online Web-based backup services.With so many technologies
available to support SQL Server data protection and recovery, you can mix and match
technologies to achieve the level of data and application protection and recoverability that meets
your business needs.
Backup Appliances
Tandberg Data's InteliStor is an example of a NAS appliance with integrated tape backup. The
various InteliStor models are configured with Microsoft Windows Storage Server 2003,
Symantec Backup Exec Quick Start, varying amounts of storage, and tape cartridge backup
capabilities sufficient to back up the storage. Appliance solutions are intended to reduce the
technical skill level required to implement and manage a particular IT function. However, as
Adam Carheden indicated in his review of backup appliances, these aren't install-and-forget
solutions.Although backup appliances simplify acquisition and installation, configuring backups
and restoring data still takes a knowledgeable person. Add SQL Server to the mix ( supported by
the SQL Server module for the appliance's backup software), and backup appliances aren't that
easy to use.
Online Backup Services
A growing number of services allow you to back up files over the Internet to their storage
farms—a convenient way to safeguard relatively small volumes of data—and some now support
SQL Server databases. Small businesses and desktop database users should consider using one of
these Webbased backup services.
NovaStor offers an online service called NovaNet-WEB. Enhancements are planned for July to
specifically support SQL Server 2005 and SQL Server 2000 backup in two ways: using
Microsoft Volume Shadow Copy Service (VSS) for open file backup and using the SQL Server
backup API.VSS quiesces SQL Server activity long enough to map a snapshot of current
database file structures, after which the snapshot data is encrypted for transmission to NovaStor.
The SQL Server backup API allows the NovaNet-WEB agent on the server to obtain updates to
protected tables. The agent compresses changed data, encrypts it, and sends it to NovaNet-WEB
backup servers, where it's stored in an encrypted format. This type of backup archives changed
data in a way that allows point-in-time recovery.
Restoring normal SQL Server backups requires that you understand the correct full, incremental,
and log backups to apply.With NovaNet-WEB, you need not be concerned with the physical
structure of the backups in order to restore a table. "Being able to restore from a synthesized full
backup—simply selecting a database without worrying about reassembling the correct full and
incremental backups—saves administrators both time and potentially their jobs," according to
Chris Harvey, NovaStor CTO.
Traditional Backup Software
Traditional backup software vendors continue to dominate the backup market.(See Buyer's
Guide: "Business Backup and Recovery," January 2005). Key feature differentiators relevant to
SQL Server users include:








Support for SQL Server clusters
Support for SQL Server 2005's updated backup Virtual Device Interface (VDI)
Support for SQL Server VSS snapshot backups
Support for 64-bit versions of Windows Server 2003,Windows XP, and SQL Server 2005
Speed and ease of recovering system and user data structures backed up in different ways
The ability to encrypt backup copies of data to protect them from unauthorized use, and
the means for long-term management of the encryption keys vital to your use of the
backup
Compression capabilities and strategies to reduce the amount of disk and tape needed to
store backup data
Support for CDP
The ability to encrypt data as it's transmitted to the target backup device and as it resides on that
device is often an option—an important one, especially if you contract for safe offsite storage of
sensitive private or corporate information.
Earlier versions of SQL Server supported three primary backup types. A full backup allows you
to restore a complete database to the point in time of the backup. Differential backups build on
previous backups by copying only data pages that have changed since the last full or differential
backup. Transaction log backups copy transaction log data and in the case of a bulk log backup,
data pages changed by bulk operations. To these standard full, differential, and transaction log
backup types, SQL Server 2005 adds some new twists.All data and differential backups now
include log records.A new partial backup option that allows you to skip backing up read-only file
groups is available.
Continuing the trend toward 64-bit support, many backup software vendors have added x64
support to their products. However, if you plan to run under an x64 OS, don't assume your
backup solution vendor has x64 support—ask. While the list of x64-supporting vendors is
growing rapidly, support isn't yet a given.
CDP
SQL Server–ware CDP is available from several vendors, although at this writing, Microsoft
System Center Data Protection Manager (DPM) lacks this feature. CDP technology fully
replicates a database, then monitors the database for changes and writes them to storage media as
they occur. This creates a log of changes and allows point-in-time recovery of files and tables.
One CDP vendor, XOsoft, offers products that bridge the gap between data backup and high
availability, with some unique capabilities thrown in. XOsoft's core functions for SQL Server are
found in Enterprise Rewinder SQL. Rewinder is a file replication product that operates at the
level of the file system stack rather than using SQL Server's backup VDI. Rewinder can
recognize the various kinds of SQL database activity, including checkpoints, in order to maintain
an accurate consistent replica. Because Rewinder also logs all database change activity, it can
"unapply" changes (i.e., restore a database to an earlier point in time before some kind of
corruption occurred). Rewinder supports x64 OSs.
A separate XOsoft module, Assured Recovery, makes a replica available for normal use—for
example, for testing recovery plans or to create a VSS snapshot for a traditional point-in-time
backup. While the replica is open for use, Assured Recovery maintains two activity logs: one
that logs all the activity against the open replica and another that logs the activity for the primary
production copy of the database.These two logs allow you to test your recovery procedures
against the replica, then return the replica to a state consistent with the primary production copy
of the database. XOsoft's WANSyncHA adds monitoring and application failover to the replica
server.
SAN vendors also offer snapshot backup features with support for SQL Server. While each SAN
vendor has its own proprietary technology to implement snapshot backup, the solutions often
combine the following features and capabilities:



SAN firmware to quickly capture a map of the volume's data blocks that are in use at the
moment of the snapshot and preserve the data as further updates occur.
Server applications to ensure logically complete and consistent snapshots for applications
such as SQL Server.
Other server applications to make a snapshot copy of data available for use.
Trends
I uncovered three key backup and recovery trends while writing this article.The first is the move
away from tape in favor of disk as a primary backup medium. Driving this trend is a perfect
storm in the form of reduced cost of disk storage, reduced cost of the bandwidth needed to
transmit copies of data to a remote site, and software improvements to more easily create,
manage, and work with disk-based backups and replicas. Disk backup is a most welcome trend
for anyone who has worked with tapes or had to budget for their use.
The second trend follows naturally from the first—the increased use of tiered backup and
recovery solutions.The use of snapshots, replication, and mirroring lets you minimize or
effectively eliminate application downtime for backing up data. Backing up and archiving data
isn't an isolated activity anymore—it's part of a larger business-continuation, high-availability
strategy.
The third trend stems from the use of database technology in more desktop applications. The
enhanced capabilities of SQL Server 2005 Express Edition (over Microsoft SQL Server Desktop
Engine—MSDE) combined with Microsoft's promotion of Visual Studio 2005 Express editions
(students, your first apps are free!) will drive this trend. WinFS (Microsoft's long-promised
database-oriented file system) might have been stripped from the next Microsoft OS you'll use,
but your users' next desktop application might very well employ database technology, and you'd
better have a strategy to protect and recover that data.
Database Mirroring
Database mirroring is one of the new features in SQL Server 2005 that I find the most exciting
for high availability. In simple terms, database mirroring lets you maintain a standby server that
provides data redundancy. That is, SQL Server maintains a mirrored copy of the principal
database on another server and can automatically fail over to the mirror if the principal server
fails.
In SQL Server 2000 Enterprise and Developer editions, log shipping lets you maintain a standby
server. Log shipping was widely adopted because it provides an affordable standby server
solution that's fairly easy to set up and doesn't require specialized hardware. However, log
shipping is a hybrid of several features that weren't originally designed for the sole purpose of
maintaining a standby server. Essentially, log shipping backs up the transaction log in the source
server, copies the backup files, and restores them to the target server. SQL Agent jobs maintain
the process. Log shipping has several limitations:




It incurs latencies according to the backup/copy/load intervals.
You can't set log shipping up to work in a synchronous mode where a transaction isn't
committed in the source unless it was received by the target.
It doesn't support auto failover.
There are several possible points of failure because log shipping isn't a native solution,
and upon failure it might not be easy to restore the log shipping process.
Database mirroring addresses these limitations by introducing a native solution for maintaining a
standby server.
Three servers play major roles in database mirroring. The principal holds the primary database.
The mirror holds the copy. The witness (which is an optional server) allows support for auto
failover. A new client feature, auto-client redirect, appears to support the client functionality in a
failover event. No specialized hardware is necessary, and setting up a mirroring session is
amazingly simple. Database mirroring transfers transaction log records over a mirroring session
rather than copies backup files. The mirror copy of the database is in a non-recovered mode,
meaning it's not accessible for read purposes. Figure 1 illustrates the database mirroring server
configuration. An option exists to make a snapshot of the mirror available for read purposes. I
discuss database snapshots next.
You can set up a mirroring session to work in synchronous or asynchronous mode. In
synchronous mode, changes to the principal database are committed only after the mirror
receives them. In this mode, latencies are based on the network speed and number of changes.
Asynchronous mode is the faster mode because changes sent to the principal can be committed
immediately. However, in asynchronous mode there's no guarantee that the mirror received all
changes that were committed in the principal. (For more information about database mirroring,
refer to Ron Talmage's Microsoft article, "Database Mirroring in SQL Server 2005".)
Author's Note: After evaluating the early beta test coverage, Microsoft learned that the database
mirroring feature has been tested and deployed by fewer customers than is necessary to build full
confidence in such a crucial database-availability feature. Therefore, Microsoft decided that
database mirroring needs more time in the hands of customers before it's made generally
available for production use. The feature is complete, has passed extensive internal testing, and
Microsoft is committed to making it generally available in the first half of 2006. The SQL Server
2005 release to manufacturing (RTM) will have database mirroring turned off by default, but the
feature will be available for evaluation under a trace flag. Microsoft will continue to field-test the
feature with customers and will release it for general use as soon as it is ready.
Database Snapshots
Database snapshots is a new feature in SQL Server 2005 that lets you provide new functionality
and higher availability for your databases. A database snapshot is an object that looks like a readonly copy of a database at a particular moment. With a database snapshot, you create a new
database that's a snapshot of an existing database, providing the snapshot a name and a
corresponding data file for each existing data file in the source database. Because snapshots are
read-only and don't accept changes, no transaction log files are needed. A database snapshot is
extremely space-efficient. The data files in the snapshot are initially created completely empty.
SQL Server uses a trick to maintain the snapshot as a point-in-time picture of the source
database: Upon the first change that a page in the source database incurs after a snapshot is
created, the page is copied to the corresponding snapshot file before the change is applied.
Further changes to the same page don't result in copying because the snapshot maintains the state
of the page before any changes were made to it.
When you query a snapshot, SQL Server reads from the snapshot files pages that were modified
and reads from the source database pages that weren't modified. The largest a snapshot can
become is the size of the source database's data files, and only if each and every page of the
source database is changed after the snapshot is created.
You can create multiple snapshots of the same database at different points in time. For example,
you might want to create a snapshot periodically (e.g., every day or every hour). In cases in
which data is accidentally deleted, you can recover the data from the most recent snapshot. You
can also create a snapshot before applying a very intensive process that has the potential to
damage the data. For example, the process might be too big to maintain in a single transaction. If
the process fails, you can revert the database back to its snapshot's state as long as only one
snapshot of the database was created. You can also use snapshots for reporting purposes for
applications that logically need to access all data at a certain point in time.
Finally, you can create a database snapshot on the mirrored database, and in this way make the
mirror available for reading purposes. Doing so lets you reduce the query load from the principal
database.
Although the benefits to working with database snapshots are obvious, keep in mind that
whenever a page is modified for the first time after a snapshot is created, its image before the
change is copied to the snapshot. The copying process has a cost and will slow down some of the
modifications against the source database.
Row Versioning and Snapshot Isolation
SQL Server 2000 could maintain only one version of a row—the most recent one. SQL Server
2005 introduces a new technology that lets it maintain versions of a row at different points in
time in linked lists stored in tempdb. This new technology serves several purposes: It supports
the new Snapshot and Read Committed with Snapshot isolation levels (known together as
Snapshot-based Isolation Levels), building the inserted and deleted tables in triggers and online
index operations and supporting Multiple Active Result Sets (MARS).
The new isolation levels let SQL Server work in a mode in which shared locks aren't acquired
when you read data; therefore, readers aren't blocked by writers. SQL Server returns to the
readers a consistent (committed) version of the row by using row versioning. In snapshot
isolation, SQL Server returns to the reader the most recent consistent version of a row according
to the time the reader's transaction started (technically, this is the time at which the first
statement of the transaction was submitted). Multiple reads within the same transaction are
guaranteed to return the same version of the row. Snapshot isolation also detects update conflicts.
If another transaction changed the data between the time you accessed a row and the time you
modified it in the same transaction, upon modification your transaction will fail. The failure
signals that someone else changed the row and your calculations may not be valid anymore. At
this point, you can retry the transaction.
SQL Server 2005 introduces another isolation level based on row versioning that's actually an
enhancement to an existing isolation level. This new isolation level is called Read Committed
with Snapshot. In this isolation level, your transaction doesn't acquire shared locks when reading
and gets the most recent committed version of a row according to when the current SELECT
statement started (rather than when the transaction started). In this mode, multiple different reads
within the same transaction can get different versions of the row (all committed). Your reads
don't need to wait for modifying transactions to commit.
These new isolation levels benefit applications that principally read data because the applications
won't need to wait for modifying transactions to commit. Also, you now have a simple way to
enforce optimistic locking with conflict detection. But remember that the new isolation levels
aren't adequate for all environments because of the cost to maintaining and traversing the linked
lists with the row versions in tempdb. For example, the isolation levels won't be adequate in
cases where modifications are frequent and many update conflicts exist.
Row versioning is also used in SQL Server 2005 to build the inserted and deleted tables in
triggers. In SQL Server 2000, inserted and deleted are actually views on top of the section in the
transaction log that contains the log records of the change that fired the trigger. By querying
inserted and deleted, you gain access to the old and new images of the affected rows. Whenever
you access inserted or deleted you're in effect scanning a portion of the transaction log. Even
when not working with triggers, the transaction log can potentially be a bottleneck, mainly in
online transaction processing (OLTP) systems. SQL Server must first write a change to the
transaction log before it can apply the change to the data portion of the database. The
architecture of the transaction log is such that SQL Server can only write to it sequentially.
Therefore, any interference with transaction log activity (e.g., querying deleted and inserted in
triggers, transaction log replication) ultimately postpones flushing changes to the data. You need
to put a lot of attention and focus on the transaction log when implementing and tuning your
database.
SQL Server 2005 uses row versioning to keep track of versions of rows that are affected both by
the change that fired the trigger and by changes submitted from the trigger itself. SQL Server
builds inserted and deleted from the linked lists with the row versions it maintains in tempdb.
Unlike the transaction log, tempdb can be written to and read from in parallel if tempdb is striped
on multiple disk drives. It's comforting to know that the performance tension on the transaction
log is reduced, but you should also realize that you need to put more focus on tuning tempdb
now.
Another very important new feature that uses row versioning technology is online index
operations. All index operations in SQL Server 2000 (including create, rebuild, and drop) occur
offline. It's important to rebuild indexes periodically to combat index fragmentation, which can
dramatically slow ordered index range scans (i.e., range queries that use an index). When you
rebuild a clustered index, SQL Server acquires an exclusive lock on the table so that the table
isn't available for reading or writing. When you rebuild a non-clustered index, SQL Server
acquires a shared lock on the table so that the table isn't available for writing, and the index itself
can't be used during the operation. SQL Server 2000 introduced an online index defragmentation
utility (DBCC INDEXDEFRAG) to address some of the problems with index rebuilds. However,
this utility sometimes takes longer than an index rebuild, consumes more log resources, and the
end result is not as optimal as that of a full index rebuild.
SQL Server 2005 introduces online index operations (i.e., create, rebuild, drop). I find the ability
to rebuild an index online important because doing so is necessary for regular maintenance. SQL
Server uses row versioning to maintain changes that take place during the rebuild activity.
Logically, imagine that another copy of the index is constructed, allowing you to access the
source data, then when the operation finishes, the copy substitutes the source. Keep in mind that
you'll need enough database space for the operation. This enhancement is especially crucial for
24/7 shops that can't allow downtime.
Native Partitioning
Partitioning isn't a new concept in SQL Server 2005. Scaling and maintaining huge tables can be
a nightmare for DBAs, requiring rebuilding indexes to deal with fragmentation, purging and
archiving historic data, and other time-consuming and tedious tasks. Dataloading becomes
slower as a table grows larger for some insert patterns to the different indexes. DBAs use
partitioning to physically split a single huge table into multiple, smaller, more manageable units,
resulting in an environment that is much more scalable.
Partitioning in SQL Server 2000 is a hybrid of several elements that weren't originally designed
for partitioning: namely, tables, check constraints, views, and some added functionality. In SQL
Server 2000 partitioning is achieved by:



Creating multiple smaller tables instead of a single large one
Limiting the range supported by each table with a check constraint
Creating a view that unifies all pieces; making the view look and feel like the original
single table to the eyes of the user and application
The fact that partitioning isn't native in SQL Server 2000 has several implications, both in terms
of managing partitioned data and performance. DBAs need to maintain multiple physical objects
instead of one. Each partition is a separate table, and there might be variations among tables in
terms of schema and indexing. The optimizer needs to separately consider each relevant table for
a query when generating an execution plan, resulting in long optimization time and large plans.
Also, there are many requirements and limitations to support the updatability of the data through
the partitioned view, which Figure 2, illustrates.
SQL Server 2005 introduces native partitioning of tables and indexes, addressing many of the
limitations of partitioning in SQL Server 2000. You create a single object (table or index) that is
internally partitioned, as Figure 3 shows. You need only work with a single entity, resulting in
significantly reduced management and maintenance overhead. Because partitioning is native in
SQL Server 2005, you use a new vocabulary with native commands for activities such as adding,
removing, and switching partitions. A significantly reduced set of requirements for partitioning
fully supports both retrieval and modification of data. In addition, all of a table's partitions must
be identical in structure (e.g., schema, indexes); therefore, the optimizer needs to spend much
less time to optimize queries, and execution plans are typically smaller. There's much more to
say about partitioning in SQL Server 2005.
Monitoring with DMVs and DMFs
SQL Server 2005 introduces 70 new Dynamic Management Views (DMVs) and Dynamic
Management Functions (DMFs). The new DMVs and DMFs provide a lot of useful information
about the current state of SQL Server and its health, allowing you to diagnose problems and tune
the performance of your instance and databases.
Diagnostic information is now easily accessible in a fully documented, convenient table format.
Some of this information was not exposed at all in SQL Server 2000, some was documented but
not available in a convenient table format (e.g., fragmentation information through DBCC
SHOWCONTIG), and some was available only through undocumented tools (e.g., wait
information through DBCC SQLPERF(WAITSTATS)).
The new DMVs and DMFs cover two types of scope: database scope and server scope. The new
dynamic management objects cover the following categories of diagnostics: Common Language
Runtime, Database Mirroring, Databases, Execution, Full-Text Search, Indexing, I/O, Query
Notifications, Replication, Service Broker, SQL Operating System, and Transactions. You can
find a lot of information about these new objects in SQL Server 2005 Books Online under the
subject Dynamic Management Objects. Researching these new objects is time well spent because
you can now find much useful information about them.
Security
SQL Server 2005 introduces several important security-related enhancements. All permissions in
SQL Server 2005 are now grantable with the GRANT statement. In SQL Server 2000, some
permissions were directly grantable and others were available only through other means (e.g., by
being a member of a role). The management of security in SQL Server 2005 is hierarchical and
requires you to get used to new vocabulary. For example, securables are entities that you can
secure with permissions (e.g., a login or database at the server scope, an assembly or a service at
the database scope, or lower-level entities such as a type at the schema scope or a table at the
object scope). Actions on securables are granted to principals (e.g., Windows groups/logins,
SQL Server roles/logins, database roles/users).
SQL Server 2005 also has an accurate notion of a schema (as defined by the ANSI committee)
and completely separates database users from schemas. In SQL Server 2000, the schema to
which an object belongs and the database user who creates the object are the same and can't be
separated. If user1 creates Table1, the table becomes user1.Table1. If you want to drop the
database user user1 because the user leaves the company, you first must change the owner of all
objects that user1 owns to a different database user. In SQL Server 2005, you create objects in
schemas, and a schema doesn't represent a database user—it's only a schema. You can grant,
deny, and revoke permissions from principals on a schema, which in SQL Server 2005 is a
securable. You don't have any problems when you need to drop database users because they
don't "own" objects. You also have much more flexibility in regulating security against
collections of objects (i.e., schemas).
Another enhancement that DBAs have been waiting for is the ability to use built-in tools to
encrypt data within the database. SQL Server 2005 introduces a new tool that lets you control the
security context of a command or a routine by using the EXECUTE AS statement. EXECUTE
AS replaces the older SETUSER statement, providing more flexible means for security context
switching. For more information on security enhancements in SQL Server 2005, refer to BOL
and to the Microsoft SQL Server 2005 article "Introduction to SQL Server 2005 Relational
Engine Security Features.
T-SQL Enhancements
If you're in charge of writing, reviewing, and maintaining T-SQL code, you'll find a wealth of
new features and enhancements in SQL Server 2005. Let me highlight a couple of Data
Definition Language (DDL) and Data Manipulation Language (DML) enhancements that I find
particularly useful and interesting.
SQL Server 2005 introduces DDL Triggers, which let you reject or react to DDL events. A
trigger can react to server-level events (e.g., ALTER LOGIN) or database-level events (e.g.,
CREATE TABLE). The potential in this new feature is enormous—you can use it to enforce
company policies with object naming conventions, auditing, schema version changes, and more.
SQL Server 2005 also introduces the new XML datatype. This is a native XML datatype that lets
you store XML data within your database and also use it for local variables and input/output
arguments of routines. You can index the new XML datatype with specialized XML indexes,
you can constrain it with schemas, and you can query and modify it by using the XQuery
language.
SQL Server 2005 enhances the variable length datatypes (VARCHAR, NVARCHAR, and
VARBINARY) by introducing the MAX specifier instead of an actual size. With the MAX
specifier, you let SQL Server determine when to internally manage the value as a regular value
or as a large object. The nice thing about working with the enhanced datatypes is that the
programming model for regular types and large objects is unified. You can use them as local
variables and as input/output arguments for routines, and you can also use most of the functions
that apply to regular datatypes with the enhanced datatypes.
The two querying-related enhancements that I find most exciting are Analytical Ranking
Functions and Recursive Queries. The former lets you provide row numbers and other ranking
values to rows of a result set of a query. I've been able use those functions to tune many existing
solutions. The latter lets you to write recursive queries, which are very handy in manipulating
hierarchical data.
Microsoft SQL Server is a relational database management system developed by Microsoft. As
a database, it is a software product whose primary function is to store and retrieve data as
requested by other software applications, be it those on the same computer or those running on
another computer across a network (including the Internet). There are at least a dozen different
editions of Microsoft SQL Server aimed at different audiences and for workloads ranging from
small single-machine applications to large Internet-facing applications with many concurrent
users. Its primary query languages are T-SQL and ANSI SQL.
Contents












1 History
o 1.1 Genesis
o 1.2 SQL Server 2005
o 1.3 SQL Server 2008
o 1.4 SQL Server 2008 R2
o 1.5 SQL Server 2012
o 1.6 SQL Server 2014
2 Editions
o 2.1 Mainstream editions
o 2.2 Specialized editions
3 Architecture
4 Data storage
o 4.1 Buffer management
o 4.2 Concurrency and locking
5 Data retrieval
o 5.1 SQL CLR
6 Services
o 6.1 Service Broker
o 6.2 Replication Services
o 6.3 Analysis Services
o 6.4 Reporting Services
o 6.5 Notification Services
o 6.6 Integration Services
o 6.7 Full Text Search Service
o 6.8 SQLCMD
o 6.9 Visual Studio
o 6.10 SQL Server Management Studio
o 6.11 Business Intelligence Development Studio
7 Programmability
o 7.1 T-SQL
o 7.2 SQL Native Client (aka SNAC)
8 See also
9 Notes
10 References
11 Further reading
12 External links
History
Genesis
SQL Server Release History
Version Year Release Name
Codename
1.0
SQL Server 1.0
1989
(OS/2)
(16 bit)
1.1
SQL Server 1.1
1991
(OS/2)
(16 bit)
4.21
1993 SQL Server 4.21
SQLNT
(WinNT)
6.0
1995 SQL Server 6.0
SQL95
6.5
1996 SQL Server 6.5
Hydra
7.0
1998 SQL Server 7.0
Sphinx
SQL Server 7.0
1999
Palato mania
OLAP Tools
8.0
2000 SQL Server 2000
Shiloh
SQL Server 2000
8.0
2003
Liberty
64-bit Edition
9.0
2005 SQL Server 2005
Yukon
10.0
2008 SQL Server 2008
Katmai
10.25
2010 SQL Azure DB
CloudDatabase
10.5
2010 SQL Server 2008 R2 Kilimanjaro (aka KJ)
11.0
2012 SQL Server 2012
Denali
12.0
2014 SQL Server 2014
SQL14
Prior to version 7.0 the code base for MS SQL Server was sold by Sybase SQL Server to
Microsoft, and was Microsoft's entry to the enterprise-level database market, competing against
Oracle, IBM, and, later, Sybase. Microsoft, Sybase and Ashton-Tate originally worked together
to create and market the first version named SQL Server 1.0 for OS/2 (about 1989) which was
essentially the same as Sybase SQL Server 3.0 on Unix, VMS, etc. Microsoft SQL Server 4.2
was shipped around 1992 (available bundled with IBM OS/2 version 1.3). Later Microsoft SQL
Server 4.21 for Windows NT was released at the same time as Windows NT 3.1. Microsoft SQL
Server v6.0 was the first version designed for NT, and did not include any direction from Sybase.
About the time Windows NT was released in July 1993, Sybase and Microsoft parted ways and
each pursued its own design and marketing schemes. Microsoft negotiated exclusive rights to all
versions of SQL Server written for Microsoft operating systems. (In 1996 Sybase changed the
name of its product to Adaptive Server Enterprise to avoid confusion with Microsoft SQL
Server.) Until 1994, Microsoft's SQL Server carried three Sybase copyright notices as an
indication of its origin.
SQL Server 7.0 and SQL Server 2000 included modifications and extensions to the Sybase code
base, adding support for the IA-64 architecture. By SQL Server 2005 the legacy Sybase code had
been completely rewritten.[5]
Since the release of SQL Server 2000, advances have been made in performance, the client IDE
tools, and several complementary systems that are packaged with SQL Server 2005. These
include:




an extract-transform-load (ETL) tool (SQL Server Integration Services or SSIS)
a Reporting Server
an OLAP and data mining server (Analysis Services)
several messaging technologies, specifically Service Broker and Notification Services
SQL Server 2005
SQL Server 2005 (formerly codenamed "Yukon") released in October 2005. It included native
support for managing XML data, in addition to relational data. For this purpose, it defined an
xml data type that could be used either as a data type in database columns or as literals in queries.
XML columns can be associated with XSD schemas; XML data being stored is verified against
the schema. XML is converted to an internal binary data type before being stored in the database.
Specialized indexing methods were made available for XML data. XML data is queried using
XQuery; SQL Server 2005 added some extensions to the T-SQL language to allow embedding
XQuery queries in T-SQL. In addition, it also defines a new extension to XQuery, called XML
DML, that allows query-based modifications to XML data. SQL Server 2005 also allows a
database server to be exposed over web services using Tabular Data Stream (TDS) packets
encapsulated within SOAP (protocol) requests. When the data is accessed over web services,
results are returned as XML.[6]
Common Language Runtime (CLR) integration was introduced with this version, enabling one to
write SQL code as Managed Code by the CLR. For relational data, T-SQL has been augmented
with error handling features (try/catch) and support for recursive queries with CTEs (Common
Table Expressions). SQL Server 2005 has also been enhanced with new indexing algorithms,
syntax and better error recovery systems. Data pages are checksummed for better error
resiliency, and optimistic concurrency support has been added for better performance.
Permissions and access control have been made more granular and the query processor handles
concurrent execution of queries in a more efficient way. Partitions on tables and indexes are
supported natively, so scaling out a database onto a cluster is easier. SQL CLR was introduced
with SQL Server 2005 to let it integrate with the .NET Framework.[7]
SQL Server 2005 introduced "MARS" (Multiple Active Results Sets), a method of allowing
usage of database connections for multiple purposes.[8]
SQL Server 2005 introduced DMVs (Dynamic Management Views), which are specialized
views and functions that return server state information that can be used to monitor the health of
a server instance, diagnose problems, and tune performance.[9]
Service Pack 1 (SP1) of SQL Server 2005 introduced Database Mirroring,[Note 1][10] a high
availability option that provides redundancy and failover capabilities at the database level.
Failover can be performed manually or can be configured for automatic failover. Automatic
failover requires a witness partner and an operating mode of synchronous (also known as highsafety or full safety).[11]
SQL Server 2008
SQL Server 2008 (formerly codenamed "Katmai") [12][13] was released on August 6, 2008[14] and
aims to make data management self-tuning, self organizing, and self maintaining with the
development of SQL Server Always On technologies, to provide near-zero downtime. SQL
Server 2008 also includes support for structured and semi-structured data, including digital
media formats for pictures, audio, video and other multimedia data. In current versions, such
multimedia data can be stored as BLOBs (binary large objects), but they are generic bitstreams.
Intrinsic awareness of multimedia data will allow specialized functions to be performed on them.
According to Paul Flessner, senior Vice President, Server Applications, Microsoft Corp., SQL
Server 2008 can be a data storage backend for different varieties of data: XML, email,
time/calendar, file, document, spatial, etc as well as perform search, query, analysis, sharing,
and synchronization across all data types.[13]
Other new data types include specialized date and time types and a Spatial data type for locationdependent data.[15] Better support for unstructured and semi-structured data is provided using the
new FILESTREAM[16] data type, which can be used to reference any file stored on the file
system.[17] Structured data and metadata about the file is stored in SQL Server database, whereas
the unstructured component is stored in the file system. Such files can be accessed both via
Win32 file handling APIs as well as via SQL Server using T-SQL; doing the latter accesses the
file data as a BLOB. Backing up and restoring the database backs up or restores the referenced
files as well.[18] SQL Server 2008 also natively supports hierarchical data, and includes T-SQL
constructs to directly deal with them, without using recursive queries.[18]
The Full-text search functionality has been integrated with the database engine. According to a
Microsoft technical article, this simplifies management and improves performance.[19]
Spatial data will be stored in two types. A "Flat Earth" (GEOMETRY or planar) data type
represents geospatial data which has been projected from its native, spherical, coordinate system
into a plane. A "Round Earth" data type (GEOGRAPHY) uses an ellipsoidal model in which the
Earth is defined as a single continuous entity which does not suffer from the singularities such as
the international dateline, poles, or map projection zone "edges". Approximately 70 methods are
available to represent spatial operations for the Open Geospatial Consortium Simple Features for
SQL, Version 1.1.[20]
SQL Server includes better compression features, which also helps in improving scalability.[21] It
enhanced the indexing algorithms and introduced the notion of filtered indexes. It also includes
Resource Governor that allows reserving resources for certain users or workflows. It also
includes capabilities for transparent encryption of data (TDE) as well as compression of
backups.[16] SQL Server 2008 supports the ADO.NET Entity Framework and the reporting tools,
replication, and data definition will be built around the Entity Data Model.[22] SQL Server
Reporting Services will gain charting capabilities from the integration of the data visualization
products from Dundas Data Visualization, Inc., which was acquired by Microsoft.[23] On the
management side, SQL Server 2008 includes the Declarative Management Framework which
allows configuring policies and constraints, on the entire database or certain tables,
declaratively.[15] The version of SQL Server Management Studio included with SQL Server 2008
supports IntelliSense for SQL queries against a SQL Server 2008 Database Engine.[24] SQL
Server 2008 also makes the databases available via Windows PowerShell providers and
management functionality available as Cmdlets, so that the server and all the running instances
can be managed from Windows PowerShell.[25]
SQL Server 2008 R2
SQL Server 2008 R2 (10.50.1600.1, formerly codenamed "Kilimanjaro") was announced at
TechEd 2009, and was released to manufacturing on April 21, 2010.[26] SQL Server 2008 R2
adds certain features to SQL Server 2008 including a master data management system branded as
Master Data Services, a central management of master data entities and hierarchies. Also Multi
Server Management, a centralized console to manage multiple SQL Server 2008 instances and
services including relational databases, Reporting Services, Analysis Services & Integration
Services.[27]
SQL Server 2008 R2 includes a number of new services,[28] including PowerPivot for Excel and
SharePoint, Master Data Services, StreamInsight, Report Builder 3.0, Reporting Services Add-in
for SharePoint, a Data-tier function in Visual Studio that enables packaging of tiered databases
as part of an application, and a SQL Server Utility named UC (Utility Control Point), part of
AMSM (Application and Multi-Server Management) that is used to manage multiple SQL
Servers.[29]
The first SQL Server 2008 R2 service pack (10.50.2500, Service Pack 1) was released on July
11, 2011.[30]
The second SQL Server 2008 R2 service pack (10.50.4000, Service Pack 2) was released on July
26, 2012.[31]
SQL Server 2012
At the 2011 Professional Association for SQL Server (PASS) summit on October 11, Microsoft
announced that the next major version of SQL Server (codenamed "Denali"), would be SQL
Server 2012. It was released to manufacturing on March 6, 2012.[32] SQL Server 2012 Service
Pack 1 was released to manufacturing on November 9, 2012.
It was announced to be the last version to natively support OLE DB and instead to prefer ODBC
for native connectivity.[33]
SQL Server 2012's new features and enhancements include AlwaysOn SQL Server Failover
Cluster Instances and Availability Groups which provides a set of options to improve database
availability,[34] Contained Databases which simplify the moving of databases between instances,
new and modified Dynamic Management Views and Functions,[35] programmability
enhancements including new spatial features,[36] metadata discovery, sequence objects and the
THROW statement,[37] performance enhancements such as ColumnStore Indexes as well as
improvements to OnLine and partition level operations and security enhancements including
provisioning during setup, new permissions, improved role management, and default schema
assignment for groups.[38][39]
SQL Server 2014
SQL Server 2014 was released to manufacturing on March 18, 2014, and released to the general
public on April 1, 2014. Until November, 2013 there were two CTP revisions, CTP1 and
CTP2.[40] SQL Server 2014 provides a new in-memory capability for tables that can fit entirely in
memory (also known as Hekaton). Whilst small tables may be entirely resident in memory in all
versions of SQL Server, they also may reside on disk, so work is involved in reserving RAM,
writing evicted pages to disk, loading new pages from disk, locking the pages in RAM while
they are being operated on, and many other tasks. By treating a table as guaranteed to be entirely
resident in memory much of the 'plumbing' of disk-based databases can be avoided.[41]
For disk-based SQL Server applications, it also provides the SSD Buffer Pool Extension, which
can improve performance by using SSDs as a cache between DRAM and spinning media.
SQL Server 2014 also enhances the AlwaysOn (HADR) solution by increasing the readable
secondaries count and sustaining read operations upon secondary-primary disconnections, and it
provides new hybrid disaster recovery and backup solutions with Windows Azure, enabling
customers to use existing skills with the on-premises version of SQL Server to take advantage of
Microsoft's global datacenters. In addition, it takes advantage of new Windows Server 2012 and
Windows Server 2012 R2 capabilities for database application scalability in a physical or virtual
environment.
Editions
Microsoft makes SQL Server available in multiple editions, with different feature sets and
targeting different users. These editions are:[42][43]
Mainstream editions
Datacenter
SQL Server 2008 R2 Datacenter is the full-featured edition of SQL Server and is
designed for datacenters that need the high levels of application support and scalability. It
supports 256 logical processors and virtually unlimited memory. Comes with
StreamInsight Premium edition.[44] The Datacenter edition has been retired in SQL Server
2012, all its features are available in SQL Server 2012 Enterprise Edition.[45]
Enterprise
SQL Server Enterprise Edition includes both the core database engine and add-on
services, with a range of tools for creating and managing a SQL Server cluster. It can
manage databases as large as 524 petabytes and address 2 terabytes of memory and
supports 8 physical processors. SQL Server 2012 Enterprise Edition supports 160
physical processors [46]
Standard
SQL Server Standard edition includes the core database engine, along with the standalone services. It differs from Enterprise edition in that it supports fewer active instances
(number of nodes in a cluster) and does not include some high-availability functions such
as hot-add memory (allowing memory to be added while the server is still running), and
parallel indexes.
Web
SQL Server Web Edition is a low-TCO option for Web hosting.
Business Intelligence
Introduced in SQL Server 2012 and focusing on Self Service and Corporate Business
Intelligence. It includes the Standard Edition capabilities and Business Intelligence tools:
PowerPivot, Power View, the BI Semantic Model, Master Data Services, Data Quality
Services and xVelocity in-memory analytics.[47]
Workgroup
SQL Server Workgroup Edition includes the core database functionality but does not
include the additional services. Note that this edition has been retired in SQL Server
2012.[45]
Express
SQL Server Express Edition is a scaled down, free edition of SQL Server, which includes
the core database engine. While there are no limitations on the number of databases or
users supported, it is limited to using one processor, 1 GB memory and 10 GB database
files (4 GB database files prior to SQL Server Express 2008 R2).[48] It is intended as a
replacement for MSDE. Two additional editions provide a superset of features not in the
original Express Edition. The first is SQL Server Express with Tools, which includes
SQL Server Management Studio Basic. SQL Server Express with Advanced Services
adds full-text search capability and reporting services.[49]
Specialized editions
Azure
Microsoft SQL Azure Database is the cloud-based version of Microsoft SQL Server,
presented as software as a service on Azure Services Platform.
Compact (SQL CE)
The compact edition is an embedded database engine. Unlike the other editions of SQL
Server, the SQL CE engine is based on SQL Mobile (initially designed for use with handheld devices) and does not share the same binaries. Due to its small size (1 MB DLL
footprint), it has a markedly reduced feature set compared to the other editions. For
example, it supports a subset of the standard data types, does not support stored
procedures or Views or multiple-statement batches (among other limitations). It is limited
to 4 GB maximum database size and cannot be run as a Windows service, Compact
Edition must be hosted by the application using it. The 3.5 version includes support for
ADO.NET Synchronization Services. SQL CE does not support ODBC connectivity,
unlike SQL Server proper.
Developer
SQL Server Developer Edition includes the same features as SQL Server 2012 Enterprise
Edition, but is limited by the license to be only used as a development and test system,
and not as production server. This edition is available to download by students free of
charge as a part of Microsoft's DreamSpark program.[50]
Embedded (SSEE)
SQL Server 2005 Embedded Edition is a specially configured named instance of the SQL
Server Express database engine which can be accessed only by certain Windows
Services.
Evaluation
SQL Server Evaluation Edition, also known as the Trial Edition, has all the features of
the Enterprise Edition, but is limited to 180 days, after which the tools will continue to
run, but the server services will stop.[51]
Fast Track
SQL Server Fast Track is specifically for enterprise-scale data warehousing storage and
business intelligence processing, and runs on reference-architecture hardware that is
optimized for Fast Track.[52]
LocalDB
Introduced in SQL Server Express 2012, LocalDB is a minimal, on-demand, version of
SQL Server that is designed for application developers.[53] It can also be used as an
embedded database.[54]
Parallel Data Warehouse (PDW)
A massively parallel processing (MPP) SQL Server appliance optimized for large-scale
data warehousing such as hundreds of terabytes.[55]
Datawarehouse Appliance Edition
Pre-installed and configured as part of an appliance in partnership with Dell & HP base
on the Fast Track architecture. This edition does not include SQL Server Integration
Services, Analysis Services, or Reporting Services.
Architecture
The protocol layer implements the external interface to SQL Server. All operations that can be
invoked on SQL Server are communicated to it via a Microsoft-defined format, called Tabular
Data Stream (TDS). TDS is an application layer protocol, used to transfer data between a
database server and a client. Initially designed and developed by Sybase Inc. for their Sybase
SQL Server relational database engine in 1984, and later by Microsoft in Microsoft SQL Server,
TDS packets can be encased in other physical transport dependent protocols, including TCP/IP,
Named pipes, and Shared memory. Consequently, access to SQL Server is available over these
protocols. In addition, the SQL Server API is also exposed over web services.[43]
Data storage
Data storage is a database, which is a collection of tables with typed columns. SQL Server
supports different data types, including primary types such as Integer, Float, Decimal, Char
(including character strings), Varchar (variable length character strings), binary (for unstructured
blobs of data), Text (for textual data) among others. The rounding of floats to integers uses either
Symmetric Arithmetic Rounding or Symmetric Round Down (Fix) depending on arguments:
SELECT Round(2.5, 0) gives 3.
Microsoft SQL Server also allows user-defined composite types (UDTs) to be defined and used.
It also makes server statistics available as virtual tables and views (called Dynamic Management
Views or DMVs). In addition to tables, a database can also contain other objects including views,
stored procedures, indexes and constraints, along with a transaction log. A SQL Server database
can contain a maximum of 231 objects, and can span multiple OS-level files with a maximum file
size of 260 bytes (1 exabyte).[43] The data in the database are stored in primary data files with an
extension .mdf. Secondary data files, identified with a .ndf extension, are used to store optional
metadata. Log files are identified with the .ldf extension.[43]
Storage space allocated to a database is divided into sequentially numbered pages, each 8 KB in
size. A page is the basic unit of I/O for SQL Server operations. A page is marked with a 96-byte
header which stores metadata about the page including the page number, page type, free space on
the page and the ID of the object that owns it. Page type defines the data contained in the page data stored in the database, index, allocation map which holds information about how pages are
allocated to tables and indexes, change map which holds information about the changes made to
other pages since last backup or logging, or contain large data types such as image or text. While
page is the basic unit of an I/O operation, space is actually managed in terms of an extent which
consists of 8 pages. A database object can either span all 8 pages in an extent ("uniform extent")
or share an extent with up to 7 more objects ("mixed extent"). A row in a database table cannot
span more than one page, so is limited to 8 KB in size. However, if the data exceeds 8 KB and
the row contains Varchar or Varbinary data, the data in those columns are moved to a new page
(or possibly a sequence of pages, called an Allocation unit) and replaced with a pointer to the
data.[56]
For physical storage of a table, its rows are divided into a series of partitions (numbered 1 to n).
The partition size is user defined; by default all rows are in a single partition. A table is split into
multiple partitions in order to spread a database over a cluster. Rows in each partition are stored
in either B-tree or heap structure. If the table has an associated index to allow fast retrieval of
rows, the rows are stored in-order according to their index values, with a B-tree providing the
index. The data is in the leaf node of the leaves, and other nodes storing the index values for the
leaf data reachable from the respective nodes. If the index is non-clustered, the rows are not
sorted according to the index keys. An indexed view has the same storage structure as an indexed
table. A table without an index is stored in an unordered heap structure. Both heaps and B-trees
can span multiple allocation units.[57]
Buffer management
SQL Server buffers pages in RAM to minimize disc I/O. Any 8 KB page can be buffered inmemory, and the set of all pages currently buffered is called the buffer cache. The amount of
memory available to SQL Server decides how many pages will be cached in memory. The buffer
cache is managed by the Buffer Manager. Either reading from or writing to any page copies it to
the buffer cache. Subsequent reads or writes are redirected to the in-memory copy, rather than
the on-disc version. The page is updated on the disc by the Buffer Manager only if the inmemory cache has not been referenced for some time. While writing pages back to disc,
asynchronous I/O is used whereby the I/O operation is done in a background thread so that other
operations do not have to wait for the I/O operation to complete. Each page is written along with
its checksum when it is written. When reading the page back, its checksum is computed again
and matched with the stored version to ensure the page has not been damaged or tampered with
in the meantime.[58]
Concurrency and locking
SQL Server allows multiple clients to use the same database concurrently. As such, it needs to
control concurrent access to shared data, to ensure data integrity—when multiple clients update
the same data, or clients attempt to read data that is in the process of being changed by another
client. SQL Server provides two modes of concurrency control: pessimistic concurrency and
optimistic concurrency. When pessimistic concurrency control is being used, SQL Server
controls concurrent access by using locks. Locks can be either shared or exclusive. Exclusive
lock grants the user exclusive access to the data—no other user can access the data as long as the
lock is held. Shared locks are used when some data is being read—multiple users can read from
data locked with a shared lock, but not acquire an exclusive lock. The latter would have to wait
for all shared locks to be released. Locks can be applied on different levels of granularity—on
entire tables, pages, or even on a per-row basis on tables. For indexes, it can either be on the
entire index or on index leaves. The level of granularity to be used is defined on a per-database
basis by the database administrator. While a fine grained locking system allows more users to
use the table or index simultaneously, it requires more resources. So it does not automatically
turn into higher performing solution. SQL Server also includes two more lightweight mutual
exclusion solutions—latches and spinlocks—which are less robust than locks but are less
resource intensive. SQL Server uses them for DMVs and other resources that are usually not
busy. SQL Server also monitors all worker threads that acquire locks to ensure that they do not
end up in deadlocks—in case they do, SQL Server takes remedial measures, which in many
cases is to kill one of the threads entangled in a deadlock and rollback the transaction it
started.[43] To implement locking, SQL Server contains the Lock Manager. The Lock Manager
maintains an in-memory table that manages the database objects and locks, if any, on them along
with other metadata about the lock. Access to any shared object is mediated by the lock manager,
which either grants access to the resource or blocks it.
SQL Server also provides the optimistic concurrency control mechanism, which is similar to the
multiversion concurrency control used in other databases. The mechanism allows a new version
of a row to be created whenever the row is updated, as opposed to overwriting the row, i.e., a
row is additionally identified by the ID of the transaction that created the version of the row.
Both the old as well as the new versions of the row are stored and maintained, though the old
versions are moved out of the database into a system database identified as Tempdb. When a row
is in the process of being updated, any other requests are not blocked (unlike locking) but are
executed on the older version of the row. If the other request is an update statement, it will result
in two different versions of the rows—both of them will be stored by the database, identified by
their respective transaction IDs.[43]
Data retrieval
The main mode of retrieving data from an SQL Server database is querying for it. The query is
expressed using a variant of SQL called T-SQL, a dialect Microsoft SQL Server shares with
Sybase SQL Server due to its legacy. The query declaratively specifies what is to be retrieved. It
is processed by the query processor, which figures out the sequence of steps that will be
necessary to retrieve the requested data. The sequence of actions necessary to execute a query is
called a query plan. There might be multiple ways to process the same query. For example, for a
query that contains a join statement and a select statement, executing join on both the tables and
then executing select on the results would give the same result as selecting from each table and
then executing the join, but result in different execution plans. In such case, SQL Server chooses
the plan that is expected to yield the results in the shortest possible time. This is called query
optimization and is performed by the query processor itself.[43]
SQL Server includes a cost-based query optimizer which tries to optimize on the cost, in terms of
the resources it will take to execute the query. Given a query, then the query optimizer looks at
the database schema, the database statistics and the system load at that time. It then decides
which sequence to access the tables referred in the query, which sequence to execute the
operations and what access method to be used to access the tables. For example, if the table has
an associated index, whether the index should be used or not - if the index is on a column which
is not unique for most of the columns (low "selectivity"), it might not be worthwhile to use the
index to access the data. Finally, it decides whether to execute the query concurrently or not.
While a concurrent execution is more costly in terms of total processor time, because the
execution is actually split to different processors might mean it will execute faster. Once a query
plan is generated for a query, it is temporarily cached. For further invocations of the same query,
the cached plan is used. Unused plans are discarded after some time.[43][59]
SQL Server also allows stored procedures to be defined. Stored procedures are parameterized TSQL queries, that are stored in the server itself (and not issued by the client application as is the
case with general queries). Stored procedures can accept values sent by the client as input
parameters, and send back results as output parameters. They can call defined functions, and
other stored procedures, including the same stored procedure (up to a set number of times). They
can be selectively provided access to. Unlike other queries, stored procedures have an associated
name, which is used at runtime to resolve into the actual queries. Also because the code need not
be sent from the client every time (as it can be accessed by name), it reduces network traffic and
somewhat improves performance.[60] Execution plans for stored procedures are also cached as
necessary.
SQL CLR
Main article: SQL CLR
Microsoft SQL Server 2005 includes a component named SQL CLR ("Common Language
Runtime") via which it integrates with .NET Framework. Unlike most other applications that use
.NET Framework, SQL Server itself hosts the .NET Framework runtime, i.e., memory, threading
and resource management requirements of .NET Framework are satisfied by SQLOS itself,
rather than the underlying Windows operating system. SQLOS provides deadlock detection and
resolution services for .NET code as well. With SQL CLR, stored procedures and triggers can be
written in any managed .NET language, including C# and VB.NET. Managed code can also be
used to define UDT's (user defined types), which can persist in the database. Managed code is
compiled to CLI assemblies and after being verified for type safety, registered at the database.
After that, they can be invoked like any other procedure.[61] However, only a subset of the Base
Class Library is available, when running code under SQL CLR. Most APIs relating to user
interface functionality are not available.[61]
When writing code for SQL CLR, data stored in SQL Server databases can be accessed using the
ADO.NET APIs like any other managed application that accesses SQL Server data. However,
doing that creates a new database session, different from the one in which the code is executing.
To avoid this, SQL Server provides some enhancements to the ADO.NET provider that allows
the connection to be redirected to the same session which already hosts the running code. Such
connections are called context connections and are set by setting context connection
parameter to true in the connection string. SQL Server also provides several other
enhancements to the ADO.NET API, including classes to work with tabular data or a single row
of data as well as classes to work with internal metadata about the data stored in the database. It
also provides access to the XML features in SQL Server, including XQuery support. These
enhancements are also available in T-SQL Procedures in consequence of the introduction of the
new XML Datatype (query,value,nodes functions).[62]
Services
SQL Server also includes an assortment of add-on services. While these are not essential for the
operation of the database system, they provide value added services on top of the core database
management system. These services either run as a part of some SQL Server component or outof-process as Windows Service and presents their own API to control and interact with them.
Service Broker
Used inside an instance, programming environment. For cross instance applications, Service
Broker communicates over TCP/IP and allows the different components to be synchronized
together, via exchange of messages. The Service Broker, which runs as a part of the database
engine, provides a reliable messaging and message queuing platform for SQL Server
applications.[63]
Replication Services
SQL Server Replication Services are used by SQL Server to replicate and synchronize database
objects, either in entirety or a subset of the objects present, across replication agents, which
might be other database servers across the network, or database caches on the client side.
Replication follows a publisher/subscriber model, i.e., the changes are sent out by one database
server ("publisher") and are received by others ("subscribers"). SQL Server supports three
different types of replication:[64]
Transaction replication
Each transaction made to the publisher database (master database) is synced out to
subscribers, who update their databases with the transaction. Transactional replication
synchronizes databases in near real time.[65]
Merge replication
Changes made at both the publisher and subscriber databases are tracked, and
periodically the changes are synchronized bi-directionally between the publisher and the
subscribers. If the same data has been modified differently in both the publisher and the
subscriber databases, synchronization will result in a conflict which has to be resolved either manually or by using pre-defined policies. rowguid needs to be configured on a
column if merge replication is configured.[66]
Snapshot replication
Snapshot replication publishes a copy of the entire database (the then-snapshot of the
data) and replicates out to the subscribers. Further changes to the snapshot are not
tracked.[67]
Analysis Services
Main article: SQL Server Analysis Services
SQL Server Analysis Services adds OLAP and data mining capabilities for SQL Server
databases. The OLAP engine supports MOLAP, ROLAP and HOLAP storage modes for data.
Analysis Services supports the XML for Analysis standard as the underlying communication
protocol. The cube data can be accessed using MDX and LINQ[68] queries.[69] Data mining
specific functionality is exposed via the DMX query language. Analysis Services includes
various algorithms - Decision trees, clustering algorithm, Naive Bayes algorithm, time series
analysis, sequence clustering algorithm, linear and logistic regression analysis, and neural
networks - for use in data mining.[70]
Reporting Services
Main article: SQL Server Reporting Services
SQL Server Reporting Services is a report generation environment for data gathered from SQL
Server databases. It is administered via a web interface. Reporting services features a web
services interface to support the development of custom reporting applications. Reports are
created as RDL files.[71]
Reports can be designed using recent versions of Microsoft Visual Studio (Visual Studio.NET
2003, 2005, and 2008)[72] with Business Intelligence Development Studio, installed or with the
included Report Builder. Once created, RDL files can be rendered in a variety of formats[73]
including Excel, PDF, CSV, XML, TIFF (and other image formats),[74] and HTML Web
Archive.
Notification Services
Main article: SQL Server Notification Services
Originally introduced as a post-release add-on for SQL Server 2000,[75] Notification Services
was bundled as part of the Microsoft SQL Server platform for the first and only time with SQL
Server 2005.[76][77] SQL Server Notification Services is a mechanism for generating data-driven
notifications, which are sent to Notification Services subscribers. A subscriber registers for a
specific event or transaction (which is registered on the database server as a trigger); when the
event occurs, Notification Services can use one of three methods to send a message to the
subscriber informing about the occurrence of the event. These methods include SMTP, SOAP, or
by writing to a file in the filesystem.[78] Notification Services was discontinued by Microsoft
with the release of SQL Server 2008 in August 2008, and is no longer an officially supported
component of the SQL Server database platform.
Integration Services
Main article: SQL Server Integration Services
SQL Server Integration Services (SSIS) provides ETL capabilities for SQL Server for data
import, data integration and data warehousing needs. Integration Services includes GUI tools to
build workflows such as extracting data from various sources, querying data, transforming
data—including aggregation, de-duplication, de-/normalization and merging of data—and then
exporting the transformed data into destination databases or files.[79]
Full Text Search Service
The SQL Server Full Text Search service architecture
SQL Server Full Text Search service is a specialized indexing and querying service for
unstructured text stored in SQL Server databases. The full text search index can be created on
any column with character based text data. It allows for words to be searched for in the text
columns. While it can be performed with the SQL LIKE operator, using SQL Server Full Text
Search service can be more efficient. Full allows for inexact matching of the source string,
indicated by a Rank value which can range from 0 to 1000 - a higher rank means a more accurate
match. It also allows linguistic matching ("inflectional search"), i.e., linguistic variants of a word
(such as a verb in a different tense) will also be a match for a given word (but with a lower rank
than an exact match). Proximity searches are also supported, i.e., if the words searched for do not
occur in the sequence they are specified in the query but are near each other, they are also
considered a match. T-SQL exposes special operators that can be used to access the FTS
capabilities.[80][81]
The Full Text Search engine is divided into two processes - the Filter Daemon process
(msftefd.exe) and the Search process (msftesql.exe). These processes interact with the SQL
Server. The Search process includes the indexer (that creates the full text indexes) and the full
text query processor. The indexer scans through text columns in the database. It can also index
through binary columns, and use iFilters to extract meaningful text from the binary blob (for
example, when a Microsoft Word document is stored as an unstructured binary file in a
database). The iFilters are hosted by the Filter Daemon process. Once the text is extracted, the
Filter Daemon process breaks it up into a sequence of words and hands it over to the indexer.
The indexer filters out noise words, i.e., words like A, And etc., which occur frequently and are
not useful for search. With the remaining words, an inverted index is created, associating each
word with the columns they were found in. SQL Server itself includes a Gatherer component
that monitors changes to tables and invokes the indexer in case of updates.[82]
When a full text query is received by the SQL Server query processor, it is handed over to the
FTS query processor in the Search process. The FTS query processor breaks up the query into
the constituent words, filters out the noise words, and uses an inbuilt thesaurus to find out the
linguistic variants for each word. The words are then queried against the inverted index and a
rank of their accurateness is computed. The results are returned to the client via the SQL Server
process.[82]
SQLCMD
SQLCMD is a command line application that comes with Microsoft SQL Server, and exposes
the management features of SQL Server. It allows SQL queries to be written and executed from
the command prompt. It can also act as a scripting language to create and run a set of SQL
statements as a script. Such scripts are stored as a .sql file, and are used either for management
of databases or to create the database schema during the deployment of a database.
SQLCMD was introduced with SQL Server 2005 and this continues with SQL Server 2012 and
2014. Its predecessor for earlier versions was OSQL and ISQL, which is functionally equivalent
as it pertains to TSQL execution, and many of the command line parameters are identical,
although SQLCMD adds extra versatility.
Visual Studio
Main article: Microsoft Visual Studio
Microsoft Visual Studio includes native support for data programming with Microsoft SQL
Server. It can be used to write and debug code to be executed by SQL CLR. It also includes a
data designer that can be used to graphically create, view or edit database schemas. Queries can
be created either visually or using code. SSMS 2008 onwards, provides intellisense for SQL
queries as well.
SQL Server Management Studio
Main article: SQL Server Management Studio
SQL Server Management Studio is a GUI tool included with SQL Server 2005 and later for
configuring, managing, and administering all components within Microsoft SQL Server. The tool
includes both script editors and graphical tools that work with objects and features of the
server.[83] SQL Server Management Studio replaces Enterprise Manager as the primary
management interface for Microsoft SQL Server since SQL Server 2005. A version of SQL
Server Management Studio is also available for SQL Server Express Edition, for which it is
known as SQL Server Management Studio Express (SSMSE).[84]
A central feature of SQL Server Management Studio is the Object Explorer, which allows the
user to browse, select, and act upon any of the objects within the server.[85] It can be used to
visually observe and analyze query plans and optimize the database performance, among
others.[86] SQL Server Management Studio can also be used to create a new database, alter any
existing database schema by adding or modifying tables and indexes, or analyze performance. It
includes the query windows which provide a GUI based interface to write and execute
queries.[43]
Business Intelligence Development Studio
Main article: Business Intelligence Development Studio
Business Intelligence Development Studio (BIDS) is the IDE from Microsoft used for
developing data analysis and Business Intelligence solutions utilizing the Microsoft SQL Server
Analysis Services, Reporting Services and Integration Services. It is based on the Microsoft
Visual Studio development environment but is customized with the SQL Server services-specific
extensions and project types, including tools, controls and projects for reports (using Reporting
Services), Cubes and data mining structures (using Analysis Services).[87]
Programmability
T-SQL
Main article: T-SQL
T-SQL (Transact-SQL) is the Secondary means of programming and managing SQL Server. It
exposes keywords for the operations that can be performed on SQL Server, including creating
and altering database schemas, entering and editing data in the database as well as monitoring
and managing the server itself. Client applications that consume data or manage the server will
leverage SQL Server functionality by sending T-SQL queries and statements which are then
processed by the server and results (or errors) returned to the client application. SQL Server
allows it to be managed using T-SQL. For this it exposes read-only tables from which server
statistics can be read. Management functionality is exposed via system-defined stored procedures
which can be invoked from T-SQL queries to perform the management operation. It is also
possible to create linked Server using T-SQL. Linked server allows operation to multiple server
as one query.[88]
SQL Native Client (aka SNAC)
SQL Native Client is the native client side data access library for Microsoft SQL Server, version
2005 onwards. It natively implements support for the SQL Server features including the Tabular
Data Stream implementation, support for mirrored SQL Server databases, full support for all data
types supported by SQL Server, asynchronous operations, query notifications, encryption
support, as well as receiving multiple result sets in a single database session. SQL Native Client
is used under the hood by SQL Server plug-ins for other data access technologies, including
ADO or OLE DB. The SQL Native Client can also be directly used, bypassing the generic data
access layers.[89]
On 28 Nov 2011 a preview release of the SQL Server ODBC driver for Linux was released.[90]
See also





Comparison of relational database management systems
Comparison of object-relational database management systems
Comparison of data modeling tools
Database management system
List of relational database management systems
Notes
1. Database Mirroring was included in the first release of SQL Server 2005 for evaluation
purposes only. Prior to SP1, it was not enabled by default, and was not supported by
Microsoft.
References
This article cites its sources but does not provide page references. You can help to
improve it by introducing citations that are more precise. (September 2010)
1. "SQL Server 2014 released to manufacturers, will be generally available April 1".
Microsoft Official Blog. Microsoft. 18 March 2014. Retrieved 9 Jun 2014.
2. Lextrait, Vincent (July 2010). "The Programming Languages Beacon, v10.3". Retrieved
5 September 2010.
3. "Hardware and Software Requirements for Installing SQL Server 2008 R2". MSDN.
Microsoft Corporation. Retrieved 18 July 2011.
4. "Download Microsoft SQL Server 2008 R2". Microsoft Evaluation Center. Microsoft
Corporation. Retrieved 18 July 2011.
5. All about the History of SQL Server - Scriptcase Blog PHP. Scriptcase.net. Retrieved on
2014-03-23.
6. "Database Engine XML Enhancements". Retrieved 2007-12-03.
7. "Database Engine Enhancements". Retrieved 2007-12-03.
8. Multiple Active Result Sets (MARS) in SQL Server 2005 (retrieved June 20, 2009)
9. Dynamic Management Views and Functions (retrieved June 06, 2010)
10. "Issues to consider when you use the database mirroring feature in the initial release of
SQL Server 2005". Support.microsoft.com. 2007-11-20. Retrieved 2011-09-04.
11. "Automatic Failover". Msdn.microsoft.com. Retrieved 2011-09-04.
12. "Microsoft SQL Server 2008". Retrieved 2007-04-06.
13. "ChannelWeb: Next SQL Server stop: Katmai". Retrieved 2005-11-05.
14. Announced to the SQL Server Special Interest Group at the ESRI 2008 User's
Conference on August 6, 2008 by Ed Katibah (Spatial Program Manager at Microsoft)
15. "Microsoft Gives Peek At Next Version Of SQL Server". Retrieved 2007-05-11.
16. "One more test build to go for SQL Server 2008". Retrieved 2006-11-13.
17. "Guest Blogger: Ted Kummert". Retrieved 2007-11-20.
18. Christian Kleinerman. "SQL Server 2008 for developers". Channel9. Retrieved 2008-0307.
19. Fernando Azpeitia Lopez. "SQL Server 2008 Full-Text Search: Internals and
Enhancements".
20. "Microsoft Shares Details on SQL Server 2008 Spatial Support by Directions Staff".
Archived from the original on 2007-08-08. Retrieved 2007-09-07.
21. "Features of SQL 2008". Technet.microsoft.com. 2009-02-12. Retrieved 2011-09-04.
22. "SQL Server "Katmai" to Deliver Entity Data Platform and Support LINQ". Retrieved
2007-05-12.
23. "Microsoft Details Dynamic IT Strategy at Tech-Ed 2007". Retrieved 2007-06-04.
24. "SQL Server IntelliSense". Retrieved 2008-08-18.
25. "SQL Server Support for PowerShell!". Retrieved 2007-12-03.
26. "SQL SQL Server 2008 R2 Launches!". Retrieved 2010-04-21.
27. SQL Server Team. "TechEd 2009 – new SQL Server Innovations". MSDN Blogs.
Retrieved 2009-05-12.
28. "Review: Microsoft SQL Server 2008 R2". Networkworld.com. 2010-05-03. Retrieved
2013-06-15.
29. "SQL SQL Server 2008 javed R2 Application and Multi-Server Management". Retrieved
2010-06-06.
30. "Download Details - Microsoft Download Center - Microsoft® SQL Server® 2008 R2
SP1". Retrieved 2011-09-19.
31. "Download Details - Microsoft Download Center - Microsoft® SQL Server® 2008 R2
SP2". Retrieved 2012-07-31.
32. "Microsoft Releases SQL Server 2012 to Help Customers Manage "Any Data, Any Size,
Anywhere"". Microsoft News Center. Microsoft. 6 March 2012. Retrieved 7 March 2012.
33. Lam, Rohan. "Microsoft is Aligning with ODBC for Native Relational Data Access FAQ". SQL Server Forums. Microsoft Corporation. Retrieved 7 March 2012.
34. "Availability Enhancements (Database Engine)". Msdn.microsoft.com. Retrieved 201306-15.
35. "Manageability Enhancements (Database Engine)". Msdn.microsoft.com. 2011-07-13.
Retrieved 2013-06-15.
36. Alastair Aitchison (2012). Pro Spatial with SQL Server 2012. Apress. pp. 21–23.
ISBN 978-1-4302-3491-3.
37. "Programmability Enhancements (Database Engine)". Msdn.microsoft.com. Retrieved
2013-06-15.
38. "Scalability and Performance Enhancements (Database Engine)". Msdn.microsoft.com.
Retrieved 2013-06-15.
39. "Security Enhancements (Database Engine)". Msdn.microsoft.com. Retrieved 2013-0615.
40. SQL Server 2014 - CTP2 is now available - Data > Knowledge > Intelligence - Site
Home - MSDN Blogs. Blogs.msdn.com (2013-10-16). Retrieved on 2014-03-23.
41. SQL Server 2012-2014-Explore | Server Cloud. Microsoft.com (2013-04-17). Retrieved
on 2014-03-23.
42. "Compare Editions". SQL Server homepage. Microsoft Corporation. Retrieved 2007-1203.
43. Kalen Delaney. Inside Microsoft SQL Server 2005: The Storage Engine. Microsoft Press.
ISBN 0-7356-2105-5.
44. "Choosing a StreamInsight Edition". MSDN. Microsoft Corporation. Retrieved 18 July
2011.
45. http://download.microsoft.com/download/4/F/7/4F74E127-827E-420D-971F53CECB6778BD/SQL_Server_2012_Licensing_Datasheet_and_FAQ_Mar2012.docx
46. "SQL Server 2008: Editions". Retrieved 2011-07-21.
47. "Database System | Performance & Scalability | SQL Server 2012 Business Intelligence
Editions". Microsoft.com. Retrieved 2013-06-15.
48. "SQL Server 2008 R2 Express Database Size Limit Increased to 10GB". Retrieved 201004-23.
49. "What's up with SQL Server 2008 Express editions". Retrieved 2008-08-15.
50. "Developer Edition". SQL Server home. Microsoft Corporation. Retrieved 18 July 2011.
51. "SQL Server 2008 Trial Software". Retrieved 2009-03-26.
52. "Microsoft SQL Server 2008: Fast Track Data Warehouse". Retrieved 2009-03-26.
53. "SQL Server 2012 Express LocalDB". msdn.microsoft.com. Retrieved 11 March 2013.
54. "Introducing LocalDB, an improved SQL Express".
55. "SQL Server 2008 R2 Parallel Data Warehouse". Retrieved 2011-07-13.
56. "Pages and Extents". Retrieved 2007-12-02.
57. "Table and Index Organization". Retrieved 2007-12-02.
58. "Buffer Management". Retrieved 2007-12-02.
59. "Single SQL Statement Processing". Retrieved 2007-12-03.
60. "Stored Procedure Basics". Retrieved 2007-12-03.
61. "Overview of CLR integration". Retrieved 2007-12-03.
62. "XML Support in SQL Server". Retrieved 2008-09-05.
63. "Introducing Service Broker". Retrieved 2007-12-03.
64. "Types of Replication Overview". Retrieved 2007-12-03.
65. "Transactional Replication Overview". Retrieved 2007-12-03.
66. "Merge Replication Overview". Retrieved 2007-12-03.
67. "Snapshot replication Overview". Retrieved 2007-12-03.
68. "SSAS Entity Framework Provider". Retrieved 2011-09-29.
69. "Analysis Services Architecture". Retrieved 2007-12-03.
70. "Data Mining Concepts". Retrieved 2007-12-03.
71. "SQL Server Reporting Services". Retrieved 2007-12-03.
72. "Cannot open a SQL Reporting Services .rptproj file | Microsoft Connect".
Connect.microsoft.com. Retrieved 2011-09-04.
73. MSDN Library: Reporting Services Render Method - See Device Information Settings
74. Image Device Information Settings - SSRS can render BMP, EMF, GIF, JPEG, PNG, and
TIFF.
75. "An Introduction to SQL Server Notification Services". Retrieved 2008-11-14.
76. "SQL Server Notification Services Removed from SQL Server 2008". Retrieved 200809-17.
77. "Discontinued Functionality in SQL Server 2008 Reporting Services". Retrieved 200809-17.
78. "Introducing SQL Server Notification Services". Retrieved 2007-12-03.
79. "Integration Services Overview". Retrieved 2007-12-03.
80. "Introduction to Full-Text Search". Retrieved 2007-12-03.
81. "Querying SQL Server using Full-Text Search". Retrieved 2007-12-03.
82. "Full-Text Search Architecture". Retrieved 2007-12-03.
83. "MSDN: Introducing SQL Server Management Studio". Msdn.microsoft.com. Retrieved
2011-09-04.
84. "SQL Server Management Studio Express". Microsoft.com. 2006-04-18. Retrieved 201109-04.
85. "MSDN: Using Object Explorer". Msdn.microsoft.com. Retrieved 2011-09-04.
86. "SQL Server 2005 Management Tools". Sqlmag.com. 2005-07-19. Retrieved 2011-0904.
87. "Introducing Business Intelligence Development Studio". Retrieved 2007-12-03.
88. "Transact-SQL Reference". Retrieved 2007-12-03.
89. "Features of SQL Native Client". Retrieved 2007-12-03.
90. "Available Today: Preview Release of the SQL Server ODBC Driver for Linux - SQL
Server Team Blog - Site Home - TechNet Blogs". Blogs.technet.com. 2011-11-28.
Retrieved 2013-06-15.
SQL Server 2005
SQL Server 2005 (formerly codenamed "Yukon") released in October 2005. It included native
support for managing XML data, in addition to relational data. For this purpose, it defined an
xml data type that could be used either as a data type in database columns or as literals in queries.
XML columns can be associated with XSD schemas; XML data being stored is verified against
the schema. XML is converted to an internal binary data type before being stored in the database.
Specialized indexing methods were made available for XML data. XML data is queried using
XQuery; SQL Server 2005 added some extensions to the T-SQL language to allow embedding
XQuery queries in T-SQL. In addition, it also defines a new extension to XQuery, called XML
DML, that allows query-based modifications to XML data. SQL Server 2005 also allows a
database server to be exposed over web services using Tabular Data Stream (TDS) packets
encapsulated within SOAP (protocol) requests. When the data is accessed over web services,
results are returned as XML.[6]
Common Language Runtime (CLR) integration was introduced with this version, enabling one to
write SQL code as Managed Code by the CLR. For relational data, T-SQL has been augmented
with error handling features (try/catch) and support for recursive queries with CTEs (Common
Table Expressions). SQL Server 2005 has also been enhanced with new indexing algorithms,
syntax and better error recovery systems. Data pages are checksummed for better error
resiliency, and optimistic concurrency support has been added for better performance.
Permissions and access control have been made more granular and the query processor handles
concurrent execution of queries in a more efficient way. Partitions on tables and indexes are
supported natively, so scaling out a database onto a cluster is easier. SQL CLR was introduced
with SQL Server 2005 to let it integrate with the .NET Framework.[7]
SQL Server 2005 introduced "MARS" (Multiple Active Results Sets), a method of allowing
usage of database connections for multiple purposes.[8]
SQL Server 2005 introduced DMVs (Dynamic Management Views), which are specialized
views and functions that return server state information that can be used to monitor the health of
a server instance, diagnose problems, and tune performance.[9]
Service Pack 1 (SP1) of SQL Server 2005 introduced Database Mirroring,[Note 1][10] a high
availability option that provides redundancy and failover capabilities at the database level.
Failover can be performed manually or can be configured for automatic failover. Automatic
failover requires a witness partner and an operating mode of synchronous (also known as highsafety or full safety).[11]
SQL Server 2008
SQL Server 2008 (formerly codenamed "Katmai") [12][13] was released on August 6, 2008[14] and
aims to make data management self-tuning, self organizing, and self maintaining with the
development of SQL Server Always On technologies, to provide near-zero downtime. SQL
Server 2008 also includes support for structured and semi-structured data, including digital
media formats for pictures, audio, video and other multimedia data. In current versions, such
multimedia data can be stored as BLOBs (binary large objects), but they are generic bitstreams.
Intrinsic awareness of multimedia data will allow specialized functions to be performed on them.
According to Paul Flessner, senior Vice President, Server Applications, Microsoft Corp., SQL
Server 2008 can be a data storage backend for different varieties of data: XML, email,
time/calendar, file, document, spatial, etc as well as perform search, query, analysis, sharing,
and synchronization across all data types.[13]
Other new data types include specialized date and time types and a Spatial data type for locationdependent data.[15] Better support for unstructured and semi-structured data is provided using the
new FILESTREAM[16] data type, which can be used to reference any file stored on the file
system.[17] Structured data and metadata about the file is stored in SQL Server database, whereas
the unstructured component is stored in the file system. Such files can be accessed both via
Win32 file handling APIs as well as via SQL Server using T-SQL; doing the latter accesses the
file data as a BLOB. Backing up and restoring the database backs up or restores the referenced
files as well.[18] SQL Server 2008 also natively supports hierarchical data, and includes T-SQL
constructs to directly deal with them, without using recursive queries.[18]
The Full-text search functionality has been integrated with the database engine. According to a
Microsoft technical article, this simplifies management and improves performance.[19]
Spatial data will be stored in two types. A "Flat Earth" (GEOMETRY or planar) data type
represents geospatial data which has been projected from its native, spherical, coordinate system
into a plane. A "Round Earth" data type (GEOGRAPHY) uses an ellipsoidal model in which the
Earth is defined as a single continuous entity which does not suffer from the singularities such as
the international dateline, poles, or map projection zone "edges". Approximately 70 methods are
available to represent spatial operations for the Open Geospatial Consortium Simple Features for
SQL, Version 1.1.[20]
SQL Server includes better compression features, which also helps in improving scalability.[21] It
enhanced the indexing algorithms and introduced the notion of filtered indexes. It also includes
Resource Governor that allows reserving resources for certain users or workflows. It also
includes capabilities for transparent encryption of data (TDE) as well as compression of
backups.[16] SQL Server 2008 supports the ADO.NET Entity Framework and the reporting tools,
replication, and data definition will be built around the Entity Data Model.[22] SQL Server
Reporting Services will gain charting capabilities from the integration of the data visualization
products from Dundas Data Visualization, Inc., which was acquired by Microsoft.[23] On the
management side, SQL Server 2008 includes the Declarative Management Framework which
allows configuring policies and constraints, on the entire database or certain tables,
declaratively.[15] The version of SQL Server Management Studio included with SQL Server 2008
supports IntelliSense for SQL queries against a SQL Server 2008 Database Engine.[24] SQL
Server 2008 also makes the databases available via Windows PowerShell providers and
management functionality available as Cmdlets, so that the server and all the running instances
can be managed from Windows PowerShell.[25]
SQL Server 2008 R2
SQL Server 2008 R2 (10.50.1600.1, formerly codenamed "Kilimanjaro") was announced at
TechEd 2009, and was released to manufacturing on April 21, 2010.[26] SQL Server 2008 R2
adds certain features to SQL Server 2008 including a master data management system branded as
Master Data Services, a central management of master data entities and hierarchies. Also Multi
Server Management, a centralized console to manage multiple SQL Server 2008 instances and
services including relational databases, Reporting Services, Analysis Services & Integration
Services.[27]
SQL Server 2008 R2 includes a number of new services,[28] including PowerPivot for Excel and
SharePoint, Master Data Services, StreamInsight, Report Builder 3.0, Reporting Services Add-in
for SharePoint, a Data-tier function in Visual Studio that enables packaging of tiered databases
as part of an application, and a SQL Server Utility named UC (Utility Control Point), part of
AMSM (Application and Multi-Server Management) that is used to manage multiple SQL
Servers.[29]
The first SQL Server 2008 R2 service pack (10.50.2500, Service Pack 1) was released on July
11, 2011.[30]
The second SQL Server 2008 R2 service pack (10.50.4000, Service Pack 2) was released on July
26, 2012.[31]
SQL Server 2012
At the 2011 Professional Association for SQL Server (PASS) summit on October 11, Microsoft
announced that the next major version of SQL Server (codenamed "Denali"), would be SQL
Server 2012. It was released to manufacturing on March 6, 2012.[32] SQL Server 2012 Service
Pack 1 was released to manufacturing on November 9, 2012.
It was announced to be the last version to natively support OLE DB and instead to prefer ODBC
for native connectivity.[33]
SQL Server 2012's new features and enhancements include AlwaysOn SQL Server Failover
Cluster Instances and Availability Groups which provides a set of options to improve database
availability,[34] Contained Databases which simplify the moving of databases between instances,
new and modified Dynamic Management Views and Functions,[35] programmability
enhancements including new spatial features,[36] metadata discovery, sequence objects and the
THROW statement,[37] performance enhancements such as ColumnStore Indexes as well as
improvements to OnLine and partition level operations and security enhancements including
provisioning during setup, new permissions, improved role management, and default schema
assignment for groups.[38][39]
SQL Server 2014
SQL Server 2014 was released to manufacturing on March 18, 2014, and released to the general
public on April 1, 2014. Until November, 2013 there were two CTP revisions, CTP1 and
CTP2.[40] SQL Server 2014 provides a new in-memory capability for tables that can fit entirely in
memory (also known as Hekaton). Whilst small tables may be entirely resident in memory in all
versions of SQL Server, they also may reside on disk, so work is involved in reserving RAM,
writing evicted pages to disk, loading new pages from disk, locking the pages in RAM while
they are being operated on, and many other tasks. By treating a table as guaranteed to be entirely
resident in memory much of the 'plumbing' of disk-based databases can be avoided.[41]
For disk-based SQL Server applications, it also provides the SSD Buffer Pool Extension, which
can improve performance by using SSDs as a cache between DRAM and spinning media.
SQL Server 2014 also enhances the AlwaysOn (HADR) solution by increasing the readable
secondaries count and sustaining read operations upon secondary-primary disconnections, and it
provides new hybrid disaster recovery and backup solutions with Windows Azure, enabling
customers to use existing skills with the on-premises version of SQL Server to take advantage of
Microsoft's global datacenters. In addition, it takes advantage of new Windows Server 2012 and
Windows Server 2012 R2 capabilities for database application scalability in a physical or virtual
environment.
Editions
Microsoft makes SQL Server available in multiple editions, with different feature sets and
targeting different users. These editions are:[42][43]
Mainstream editions
Datacenter
SQL Server 2008 R2 Datacenter is the full-featured edition of SQL Server and is designed for
datacenters that need the high levels of application support and scalability. It supports 256
logical processors and virtually unlimited memory. Comes with StreamInsight Premium
edition.[44] The Datacenter edition has been retired in SQL Server 2012, all its features are
available in SQL Server 2012 Enterprise Edition.[45]
Enterprise
SQL Server Enterprise Edition includes both the core database engine and add-on services, with
a range of tools for creating and managing a SQL Server cluster. It can manage databases as
large as 524 petabytes and address 2 terabytes of memory and supports 8 physical processors.
SQL Server 2012 Enterprise Edition supports 160 physical processors [46]
Standard
SQL Server Standard edition includes the core database engine, along with the stand-alone
services. It differs from Enterprise edition in that it supports fewer active instances (number of
nodes in a cluster) and does not include some high-availability functions such as hot-add
memory (allowing memory to be added while the server is still running), and parallel indexes.
Web
SQL Server Web Edition is a low-TCO option for Web hosting.
Business Intelligence
Introduced in SQL Server 2012 and focusing on Self Service and Corporate Business Intelligence.
It includes the Standard Edition capabilities and Business Intelligence tools: PowerPivot, Power
View, the BI Semantic Model, Master Data Services, Data Quality Services and xVelocity inmemory analytics.[47]
Workgroup
SQL Server Workgroup Edition includes the core database functionality but does not include the
additional services. Note that this edition has been retired in SQL Server 2012.[45]
Express
SQL Server Express Edition is a scaled down, free edition of SQL Server, which includes the core
database engine. While there are no limitations on the number of databases or users supported,
it is limited to using one processor, 1 GB memory and 10 GB database files (4 GB database files
prior to SQL Server Express 2008 R2).[48] It is intended as a replacement for MSDE. Two
additional editions provide a superset of features not in the original Express Edition. The first is
SQL Server Express with Tools, which includes SQL Server Management Studio Basic. SQL Server
Express with Advanced Services adds full-text search capability and reporting services.[49]
Specialized editions
Azure
Microsoft SQL Azure Database is the cloud-based version of Microsoft SQL Server, presented as
software as a service on Azure Services Platform.
Compact (SQL CE)
The compact edition is an embedded database engine. Unlike the other editions of SQL Server,
the SQL CE engine is based on SQL Mobile (initially designed for use with hand-held devices) and
does not share the same binaries. Due to its small size (1 MB DLL footprint), it has a markedly
reduced feature set compared to the other editions. For example, it supports a subset of the
standard data types, does not support stored procedures or Views or multiple-statement
batches (among other limitations). It is limited to 4 GB maximum database size and cannot be
run as a Windows service, Compact Edition must be hosted by the application using it. The 3.5
version includes support for ADO.NET Synchronization Services. SQL CE does not support ODBC
connectivity, unlike SQL Server proper.
Developer
SQL Server Developer Edition includes the same features as SQL Server 2012 Enterprise Edition,
but is limited by the license to be only used as a development and test system, and not as
production server. This edition is available to download by students free of charge as a part of
Microsoft's DreamSpark program.[50]
Embedded (SSEE)
SQL Server 2005 Embedded Edition is a specially configured named instance of the SQL Server
Express database engine which can be accessed only by certain Windows Services.
Evaluation
SQL Server Evaluation Edition, also known as the Trial Edition, has all the features of the
Enterprise Edition, but is limited to 180 days, after which the tools will continue to run, but the
server services will stop.[51]
Fast Track
SQL Server Fast Track is specifically for enterprise-scale data warehousing storage and business
intelligence processing, and runs on reference-architecture hardware that is optimized for Fast
Track.[52]
LocalDB
Introduced in SQL Server Express 2012, LocalDB is a minimal, on-demand, version of SQL Server
that is designed for application developers.[53] It can also be used as an embedded database.[54]
Parallel Data Warehouse (PDW)
A massively parallel processing (MPP) SQL Server appliance optimized for large-scale data
warehousing such as hundreds of terabytes.[55]
Datawarehouse Appliance Edition
Pre-installed and configured as part of an appliance in partnership with Dell & HP base on the
Fast Track architecture. This edition does not include SQL Server Integration Services, Analysis
Services, or Reporting Services.
Architecture
The protocol layer implements the external interface to SQL Server. All operations that can be
invoked on SQL Server are communicated to it via a Microsoft-defined format, called Tabular
Data Stream (TDS). TDS is an application layer protocol, used to transfer data between a
database server and a client. Initially designed and developed by Sybase Inc. for their Sybase
SQL Server relational database engine in 1984, and later by Microsoft in Microsoft SQL Server,
TDS packets can be encased in other physical transport dependent protocols, including TCP/IP,
Named pipes, and Shared memory. Consequently, access to SQL Server is available over these
protocols. In addition, the SQL Server API is also exposed over web services.[43]
Data storage
Data storage is a database, which is a collection of tables with typed columns. SQL Server
supports different data types, including primary types such as Integer, Float, Decimal, Char
(including character strings), Varchar (variable length character strings), binary (for unstructured
blobs of data), Text (for textual data) among others. The rounding of floats to integers uses either
Symmetric Arithmetic Rounding or Symmetric Round Down (Fix) depending on arguments:
SELECT Round(2.5, 0) gives 3.
Microsoft SQL Server also allows user-defined composite types (UDTs) to be defined and used.
It also makes server statistics available as virtual tables and views (called Dynamic Management
Views or DMVs). In addition to tables, a database can also contain other objects including views,
stored procedures, indexes and constraints, along with a transaction log. A SQL Server database
can contain a maximum of 231 objects, and can span multiple OS-level files with a maximum file
size of 260 bytes (1 exabyte).[43] The data in the database are stored in primary data files with an
extension .mdf. Secondary data files, identified with a .ndf extension, are used to store optional
metadata. Log files are identified with the .ldf extension.[43]
Storage space allocated to a database is divided into sequentially numbered pages, each 8 KB in
size. A page is the basic unit of I/O for SQL Server operations. A page is marked with a 96-byte
header which stores metadata about the page including the page number, page type, free space on
the page and the ID of the object that owns it. Page type defines the data contained in the page data stored in the database, index, allocation map which holds information about how pages are
allocated to tables and indexes, change map which holds information about the changes made to
other pages since last backup or logging, or contain large data types such as image or text. While
page is the basic unit of an I/O operation, space is actually managed in terms of an extent which
consists of 8 pages. A database object can either span all 8 pages in an extent ("uniform extent")
or share an extent with up to 7 more objects ("mixed extent"). A row in a database table cannot
span more than one page, so is limited to 8 KB in size. However, if the data exceeds 8 KB and
the row contains Varchar or Varbinary data, the data in those columns are moved to a new page
(or possibly a sequence of pages, called an Allocation unit) and replaced with a pointer to the
data.[56]
For physical storage of a table, its rows are divided into a series of partitions (numbered 1 to n).
The partition size is user defined; by default all rows are in a single partition. A table is split into
multiple partitions in order to spread a database over a cluster. Rows in each partition are stored
in either B-tree or heap structure. If the table has an associated index to allow fast retrieval of
rows, the rows are stored in-order according to their index values, with a B-tree providing the
index. The data is in the leaf node of the leaves, and other nodes storing the index values for the
leaf data reachable from the respective nodes. If the index is non-clustered, the rows are not
sorted according to the index keys. An indexed view has the same storage structure as an indexed
table. A table without an index is stored in an unordered heap structure. Both heaps and B-trees
can span multiple allocation units.[57]
Buffer management
SQL Server buffers pages in RAM to minimize disc I/O. Any 8 KB page can be buffered inmemory, and the set of all pages currently buffered is called the buffer cache. The amount of
memory available to SQL Server decides how many pages will be cached in memory. The buffer
cache is managed by the Buffer Manager. Either reading from or writing to any page copies it to
the buffer cache. Subsequent reads or writes are redirected to the in-memory copy, rather than
the on-disc version. The page is updated on the disc by the Buffer Manager only if the inmemory cache has not been referenced for some time. While writing pages back to disc,
asynchronous I/O is used whereby the I/O operation is done in a background thread so that other
operations do not have to wait for the I/O operation to complete. Each page is written along with
its checksum when it is written. When reading the page back, its checksum is computed again
and matched with the stored version to ensure the page has not been damaged or tampered with
in the meantime.[58]
Concurrency and locking
SQL Server allows multiple clients to use the same database concurrently. As such, it needs to
control concurrent access to shared data, to ensure data integrity—when multiple clients update
the same data, or clients attempt to read data that is in the process of being changed by another
client. SQL Server provides two modes of concurrency control: pessimistic concurrency and
optimistic concurrency. When pessimistic concurrency control is being used, SQL Server
controls concurrent access by using locks. Locks can be either shared or exclusive. Exclusive
lock grants the user exclusive access to the data—no other user can access the data as long as the
lock is held. Shared locks are used when some data is being read—multiple users can read from
data locked with a shared lock, but not acquire an exclusive lock. The latter would have to wait
for all shared locks to be released. Locks can be applied on different levels of granularity—on
entire tables, pages, or even on a per-row basis on tables. For indexes, it can either be on the
entire index or on index leaves. The level of granularity to be used is defined on a per-database
basis by the database administrator. While a fine grained locking system allows more users to
use the table or index simultaneously, it requires more resources. So it does not automatically
turn into higher performing solution. SQL Server also includes two more lightweight mutual
exclusion solutions—latches and spinlocks—which are less robust than locks but are less
resource intensive. SQL Server uses them for DMVs and other resources that are usually not
busy. SQL Server also monitors all worker threads that acquire locks to ensure that they do not
end up in deadlocks—in case they do, SQL Server takes remedial measures, which in many
cases is to kill one of the threads entangled in a deadlock and rollback the transaction it
started.[43] To implement locking, SQL Server contains the Lock Manager. The Lock Manager
maintains an in-memory table that manages the database objects and locks, if any, on them along
with other metadata about the lock. Access to any shared object is mediated by the lock manager,
which either grants access to the resource or blocks it.
SQL Server also provides the optimistic concurrency control mechanism, which is similar to the
multiversion concurrency control used in other databases. The mechanism allows a new version
of a row to be created whenever the row is updated, as opposed to overwriting the row, i.e., a
row is additionally identified by the ID of the transaction that created the version of the row.
Both the old as well as the new versions of the row are stored and maintained, though the old
versions are moved out of the database into a system database identified as Tempdb. When a row
is in the process of being updated, any other requests are not blocked (unlike locking) but are
executed on the older version of the row. If the other request is an update statement, it will result
in two different versions of the rows—both of them will be stored by the database, identified by
their respective transaction IDs.[43]
Data retrieval
The main mode of retrieving data from an SQL Server database is querying for it. The query is
expressed using a variant of SQL called T-SQL, a dialect Microsoft SQL Server shares with
Sybase SQL Server due to its legacy. The query declaratively specifies what is to be retrieved. It
is processed by the query processor, which figures out the sequence of steps that will be
necessary to retrieve the requested data. The sequence of actions necessary to execute a query is
called a query plan. There might be multiple ways to process the same query. For example, for a
query that contains a join statement and a select statement, executing join on both the tables and
then executing select on the results would give the same result as selecting from each table and
then executing the join, but result in different execution plans. In such case, SQL Server chooses
the plan that is expected to yield the results in the shortest possible time. This is called query
optimization and is performed by the query processor itself.[43]
SQL Server includes a cost-based query optimizer which tries to optimize on the cost, in terms of
the resources it will take to execute the query. Given a query, then the query optimizer looks at
the database schema, the database statistics and the system load at that time. It then decides
which sequence to access the tables referred in the query, which sequence to execute the
operations and what access method to be used to access the tables. For example, if the table has
an associated index, whether the index should be used or not - if the index is on a column which
is not unique for most of the columns (low "selectivity"), it might not be worthwhile to use the
index to access the data. Finally, it decides whether to execute the query concurrently or not.
While a concurrent execution is more costly in terms of total processor time, because the
execution is actually split to different processors might mean it will execute faster. Once a query
plan is generated for a query, it is temporarily cached. For further invocations of the same query,
the cached plan is used. Unused plans are discarded after some time.[43][59]
SQL Server also allows stored procedures to be defined. Stored procedures are parameterized TSQL queries, that are stored in the server itself (and not issued by the client application as is the
case with general queries). Stored procedures can accept values sent by the client as input
parameters, and send back results as output parameters. They can call defined functions, and
other stored procedures, including the same stored procedure (up to a set number of times). They
can be selectively provided access to. Unlike other queries, stored procedures have an associated
name, which is used at runtime to resolve into the actual queries. Also because the code need not
be sent from the client every time (as it can be accessed by name), it reduces network traffic and
somewhat improves performance.[60] Execution plans for stored procedures are also cached as
necessary.
SQL CLR
Main article: SQL CLR
Microsoft SQL Server 2005 includes a component named SQL CLR ("Common Language
Runtime") via which it integrates with .NET Framework. Unlike most other applications that use
.NET Framework, SQL Server itself hosts the .NET Framework runtime, i.e., memory, threading
and resource management requirements of .NET Framework are satisfied by SQLOS itself,
rather than the underlying Windows operating system. SQLOS provides deadlock detection and
resolution services for .NET code as well. With SQL CLR, stored procedures and triggers can be
written in any managed .NET language, including C# and VB.NET. Managed code can also be
used to define UDT's (user defined types), which can persist in the database. Managed code is
compiled to CLI assemblies and after being verified for type safety, registered at the database.
After that, they can be invoked like any other procedure.[61] However, only a subset of the Base
Class Library is available, when running code under SQL CLR. Most APIs relating to user
interface functionality are not available.[61]
When writing code for SQL CLR, data stored in SQL Server databases can be accessed using the
ADO.NET APIs like any other managed application that accesses SQL Server data. However,
doing that creates a new database session, different from the one in which the code is executing.
To avoid this, SQL Server provides some enhancements to the ADO.NET provider that allows
the connection to be redirected to the same session which already hosts the running code. Such
connections are called context connections and are set by setting context connection
parameter to true in the connection string. SQL Server also provides several other
enhancements to the ADO.NET API, including classes to work with tabular data or a single row
of data as well as classes to work with internal metadata about the data stored in the database. It
also provides access to the XML features in SQL Server, including XQuery support. These
enhancements are also available in T-SQL Procedures in consequence of the introduction of the
new XML Datatype (query,value,nodes functions).[62]
Services
SQL Server also includes an assortment of add-on services. While these are not essential for the
operation of the database system, they provide value added services on top of the core database
management system. These services either run as a part of some SQL Server component or outof-process as Windows Service and presents their own API to control and interact with them.
Service Broker
Used inside an instance, programming environment. For cross instance applications, Service
Broker communicates over TCP/IP and allows the different components to be synchronized
together, via exchange of messages. The Service Broker, which runs as a part of the database
engine, provides a reliable messaging and message queuing platform for SQL Server
applications.[63]
Replication Services
SQL Server Replication Services are used by SQL Server to replicate and synchronize database
objects, either in entirety or a subset of the objects present, across replication agents, which
might be other database servers across the network, or database caches on the client side.
Replication follows a publisher/subscriber model, i.e., the changes are sent out by one database
server ("publisher") and are received by others ("subscribers"). SQL Server supports three
different types of replication:[64]
Transaction replication
Each transaction made to the publisher database (master database) is synced out to subscribers,
who update their databases with the transaction. Transactional replication synchronizes
databases in near real time.[65]
Merge replication
Changes made at both the publisher and subscriber databases are tracked, and periodically the
changes are synchronized bi-directionally between the publisher and the subscribers. If the
same data has been modified differently in both the publisher and the subscriber databases,
synchronization will result in a conflict which has to be resolved - either manually or by using
pre-defined policies. rowguid needs to be configured on a column if merge replication is
configured.[66]
Snapshot replication
Snapshot replication publishes a copy of the entire database (the then-snapshot of the data) and
replicates out to the subscribers. Further changes to the snapshot are not tracked.[67]
Analysis Services
Main article: SQL Server Analysis Services
SQL Server Analysis Services adds OLAP and data mining capabilities for SQL Server
databases. The OLAP engine supports MOLAP, ROLAP and HOLAP storage modes for data.
Analysis Services supports the XML for Analysis standard as the underlying communication
protocol. The cube data can be accessed using MDX and LINQ[68] queries.[69] Data mining
specific functionality is exposed via the DMX query language. Analysis Services includes
various algorithms - Decision trees, clustering algorithm, Naive Bayes algorithm, time series
analysis, sequence clustering algorithm, linear and logistic regression analysis, and neural
networks - for use in data mining.[70]
Reporting Services
Main article: SQL Server Reporting Services
SQL Server Reporting Services is a report generation environment for data gathered from SQL
Server databases. It is administered via a web interface. Reporting services features a web
services interface to support the development of custom reporting applications. Reports are
created as RDL files.[71]
Reports can be designed using recent versions of Microsoft Visual Studio (Visual Studio.NET
2003, 2005, and 2008)[72] with Business Intelligence Development Studio, installed or with the
included Report Builder. Once created, RDL files can be rendered in a variety of formats[73]
including Excel, PDF, CSV, XML, TIFF (and other image formats),[74] and HTML Web
Archive.
Notification Services
Main article: SQL Server Notification Services
Originally introduced as a post-release add-on for SQL Server 2000,[75] Notification Services
was bundled as part of the Microsoft SQL Server platform for the first and only time with SQL
Server 2005.[76][77] SQL Server Notification Services is a mechanism for generating data-driven
notifications, which are sent to Notification Services subscribers. A subscriber registers for a
specific event or transaction (which is registered on the database server as a trigger); when the
event occurs, Notification Services can use one of three methods to send a message to the
subscriber informing about the occurrence of the event. These methods include SMTP, SOAP, or
by writing to a file in the filesystem.[78] Notification Services was discontinued by Microsoft
with the release of SQL Server 2008 in August 2008, and is no longer an officially supported
component of the SQL Server database platform.
Integration Services
Main article: SQL Server Integration Services
SQL Server Integration Services (SSIS) provides ETL capabilities for SQL Server for data
import, data integration and data warehousing needs. Integration Services includes GUI tools to
build workflows such as extracting data from various sources, querying data, transforming
data—including aggregation, de-duplication, de-/normalization and merging of data—and then
exporting the transformed data into destination databases or files.[79]
Full Text Search Service
The SQL Server Full Text Search service architecture
SQL Server Full Text Search service is a specialized indexing and querying service for
unstructured text stored in SQL Server databases. The full text search index can be created on
any column with character based text data. It allows for words to be searched for in the text
columns. While it can be performed with the SQL LIKE operator, using SQL Server Full Text
Search service can be more efficient. Full allows for inexact matching of the source string,
indicated by a Rank value which can range from 0 to 1000 - a higher rank means a more accurate
match. It also allows linguistic matching ("inflectional search"), i.e., linguistic variants of a word
(such as a verb in a different tense) will also be a match for a given word (but with a lower rank
than an exact match). Proximity searches are also supported, i.e., if the words searched for do not
occur in the sequence they are specified in the query but are near each other, they are also
considered a match. T-SQL exposes special operators that can be used to access the FTS
capabilities.[80][81]
The Full Text Search engine is divided into two processes - the Filter Daemon process
(msftefd.exe) and the Search process (msftesql.exe). These processes interact with the SQL
Server. The Search process includes the indexer (that creates the full text indexes) and the full
text query processor. The indexer scans through text columns in the database. It can also index
through binary columns, and use iFilters to extract meaningful text from the binary blob (for
example, when a Microsoft Word document is stored as an unstructured binary file in a
database). The iFilters are hosted by the Filter Daemon process. Once the text is extracted, the
Filter Daemon process breaks it up into a sequence of words and hands it over to the indexer.
The indexer filters out noise words, i.e., words like A, And etc., which occur frequently and are
not useful for search. With the remaining words, an inverted index is created, associating each
word with the columns they were found in. SQL Server itself includes a Gatherer component
that monitors changes to tables and invokes the indexer in case of updates.[82]
When a full text query is received by the SQL Server query processor, it is handed over to the
FTS query processor in the Search process. The FTS query processor breaks up the query into
the constituent words, filters out the noise words, and uses an inbuilt thesaurus to find out the
linguistic variants for each word. The words are then queried against the inverted index and a
rank of their accurateness is computed. The results are returned to the client via the SQL Server
process.[82]
SQLCMD
SQLCMD is a command line application that comes with Microsoft SQL Server, and exposes
the management features of SQL Server. It allows SQL queries to be written and executed from
the command prompt. It can also act as a scripting language to create and run a set of SQL
statements as a script. Such scripts are stored as a .sql file, and are used either for management
of databases or to create the database schema during the deployment of a database.
SQLCMD was introduced with SQL Server 2005 and this continues with SQL Server 2012 and
2014. Its predecessor for earlier versions was OSQL and ISQL, which is functionally equivalent
as it pertains to TSQL execution, and many of the command line parameters are identical,
although SQLCMD adds extra versatility.
Visual Studio
Main article: Microsoft Visual Studio
Microsoft Visual Studio includes native support for data programming with Microsoft SQL
Server. It can be used to write and debug code to be executed by SQL CLR. It also includes a
data designer that can be used to graphically create, view or edit database schemas. Queries can
be created either visually or using code. SSMS 2008 onwards, provides intellisense for SQL
queries as well.
SQL Server Management Studio
Main article: SQL Server Management Studio
SQL Server Management Studio is a GUI tool included with SQL Server 2005 and later for
configuring, managing, and administering all components within Microsoft SQL Server. The tool
includes both script editors and graphical tools that work with objects and features of the
server.[83] SQL Server Management Studio replaces Enterprise Manager as the primary
management interface for Microsoft SQL Server since SQL Server 2005. A version of SQL
Server Management Studio is also available for SQL Server Express Edition, for which it is
known as SQL Server Management Studio Express (SSMSE).[84]
A central feature of SQL Server Management Studio is the Object Explorer, which allows the
user to browse, select, and act upon any of the objects within the server.[85] It can be used to
visually observe and analyze query plans and optimize the database performance, among
others.[86] SQL Server Management Studio can also be used to create a new database, alter any
existing database schema by adding or modifying tables and indexes, or analyze performance. It
includes the query windows which provide a GUI based interface to write and execute
queries.[43]
Business Intelligence Development Studio
Main article: Business Intelligence Development Studio
Business Intelligence Development Studio (BIDS) is the IDE from Microsoft used for
developing data analysis and Business Intelligence solutions utilizing the Microsoft SQL Server
Analysis Services, Reporting Services and Integration Services. It is based on the Microsoft
Visual Studio development environment but is customized with the SQL Server services-specific
extensions and project types, including tools, controls and projects for reports (using Reporting
Services), Cubes and data mining structures (using Analysis Services).[87]
Programmability
T-SQL
Main article: T-SQL
T-SQL (Transact-SQL) is the Secondary means of programming and managing SQL Server. It
exposes keywords for the operations that can be performed on SQL Server, including creating
and altering database schemas, entering and editing data in the database as well as monitoring
and managing the server itself. Client applications that consume data or manage the server will
leverage SQL Server functionality by sending T-SQL queries and statements which are then
processed by the server and results (or errors) returned to the client application. SQL Server
allows it to be managed using T-SQL. For this it exposes read-only tables from which server
statistics can be read. Management functionality is exposed via system-defined stored procedures
which can be invoked from T-SQL queries to perform the management operation. It is also
possible to create linked Server using T-SQL. Linked server allows operation to multiple server
as one query.[88]
SQL Native Client (aka SNAC)
SQL Native Client is the native client side data access library for Microsoft SQL Server, version
2005 onwards. It natively implements support for the SQL Server features including the Tabular
Data Stream implementation, support for mirrored SQL Server databases, full support for all data
types supported by SQL Server, asynchronous operations, query notifications, encryption
support, as well as receiving multiple result sets in a single database session. SQL Native Client
is used under the hood by SQL Server plug-ins for other data access technologies, including
ADO or OLE DB. The SQL Native Client can also be directly used, bypassing the generic data
access layers.[89]
On 28 Nov 2011 a preview release of the SQL Server ODBC driver for Linux was released.[90]