This means that if the production or mirror server is unable to read a data page due to certain types of errors like 823, 824, or 829, then the server that is unable to read the page req
Trang 1What’s New in SQL Server Database Mirroring?
SQL Server 2008 database mirroring has some exciting new features, one of which is calledlog
com-pression As the name suggests, this feature compresses the transaction log records on the production
server before sending them to the mirror server This feature reduces network bandwidth and increases
application performance and throughput at the cost of increased CPU usage
Another new feature is the capability to automatically repair a page This means that if the production or
mirror server is unable to read a data page due to certain types of errors like 823, 824, or 829, then the server
that is unable to read the page requests a copy from the other server participating in database mirroring
Upon successful retrieval of the data page, the server replaces the unreadable page, which resolves the error
automatically This feature is really nice because in order to fix similar errors during a SQL Server 2005
database mirroring session, you may have to manually run the DBCC REPAIR_ALLOW_DATA_LOSS option,
which, as the name suggests, may result in some data loss
The log compression feature is available in SQL Server 2008 Enterprise, Developer, and Standard Editions It is on by default and requires no special configuration or switches.
However, if the extra CPU usage due to log compression is not desirable in your environment, then you
can turn off log compression by turning on the trace flag 1462
The automatic page repair feature is not available in SQL Server 2008 Standard Edition It is available
only in SQL Server 2008 Enterprise and Developer Editions.
■ By default, it compresses and encrypts the data between the principal and mirror server
■ It improves the availability of your databases during hardware or software upgrades
■ It can be used for high database availability and disaster recovery purposes To achieve high database availability, place the principal and mirror SQL Servers in the same data-center For disaster recovery, place the principal and mirror SQL Servers in different datacenters so that
a disaster in one datacenter does not affect the other datacenter
■ By default, it does not support reporting If you want to use the mirror database for reporting purposes, you can create a database snapshot (refer to Chapter 45 for details on database snapshot) on the mirror database and use the snapshot for reporting purposes
If you are using the mirror database for reporting purposes, then you need to fully license the mirror server Conversely, if the mirror server is just being used as a hot standby or passive server, then (as per the Microsoft SQL Server 2008 Pricing and Licensing Guide) a license is not
required, provided that the number of processors in the passive server is equal to or less than those of
the active server The passive server can take the duties of the active server for 30 days Afterward, it
must be licensed accordingly.
■ It provides options for no data loss for committed transactions
■ It can provide an almost instantaneous database failover solution by using an optional server
called a witness.
Trang 2■ There is no real distance limitation between the principal and mirror servers.
■ It can be implemented without exotic hardware and may be significantly cheaper than other
high-availability solutions like SQL Server failover clustering Note that SQL Server failover
clustering provides high availability for the entire SQL Server instance, whereas database
mir-roring provides high availability only at the database level
■ It can complement existing log shipping and failover clustering implementations
■ If your applications use ADO.NET or the SQL Server Native Client to connect to a database,
then in case of a failure, the applications can automatically redirect the clients to the mirror
database
However, database mirroring has a few drawbacks:
■ Only user databases infullrecovery model can be used for database mirroring.Simple
orbulk-loggedrecovery model cannot be used This also means that database mirroring
will break if the recovery model for a mirrored database is changed fromfulltosimpleor
bulk-logged
■ System databases (master,model,msdb,tempdb) cannot be mirrored
■ Database mirroring does not supportFILESTREAM This means that databases with a
FILESTREAMfilegroup cannot be mirrored, nor can you create aFILESTREAMfilegroup on a
principal database
■ Database mirroring does not support cross-database transactions or distributed transactions
■ Like log shipping, database mirroring provides redundancy at the database level and not at the
entire SQL Server instance level, like SQL Server failover clustering
■ Like log shipping, database mirroring only applies to changes that are captured in the
trans-action log or the initial full backup of the principal database Any database objects such as
logins, jobs, maintenance plans, SSIS packages, and linked servers that reside outside the
mirrored database need to be manually created on the mirror server
■ Unlike log shipping, database mirroring does not support having multiple copies for the same
principal database This means you can only have one mirror database for each principal
database
■ The mirror database name needs to be same as the principal database name
■ If the mirror database fails, the transaction log space on the principal database cannot be
reused even if you are taking transaction log backup This means you need to either have
enough space for the transaction log to grow, and bring the mirror database online before the
log fills up the available disk space and brings the principal database to a halt, or break
the database mirroring
■ Depending on the workload, your environment, and the database mirroring configuration,
database mirroring may affect application performance It can also place a large demand on the
network while the transaction log records are being sent
If these drawbacks are acceptable, database mirroring can be an excellent choice for high database
avail-ability, disaster recovery, and/or reporting It is highly recommended that you thoroughly test database
Trang 3mirroring with your application and hardware, and validate your SLAs (service-level agreements), before
implementing it in production
Defining Database Mirroring
Although database mirroring appears to be similar to log shipping, it is not the same As explained
in Chapter 46, log shipping involves periodically restoring a transaction log backup from the primary
server to a warm standby server, making that server ready to recover at a moment’s notice Database
mirroring continuously transfers the transaction log records (not the transaction log backups) from the
principal database and applies them to the mirror database
Database mirroring normally involves three SQL Servers: a principal server, a mirror server, and an
optional witness server, as shown in Figure 47-1
FIGURE 47-1
Sample database mirroring configuration
DB1
DB2
DB1
DB2
Transaction log records
Transaction log records
Principal Server Mirror Server
Witness Server (Optional)
■ The principal server is the main production SQL Server to which clients connect This server
contains the database for which you want to create a duplicate (also called a hot standby
or mirror copy) The initial full database backup is taken on this server, which should be a high-quality server with redundant disk drives
Trang 4■ The mirror server is the hot standby SQL Server If the principal server fails, the mirror
server becomes the new principal server This server should be capable of meeting the
min-imum performance requirements during a short-term crisis If your business does not allow
any performance degradation, then the mirror server should be comparable to (same CPU and
memory configuration) the principal server
The principal server and mirror server are often referred to as partners in a database mirroring
session
■ The witness server is an optional separate SQL Server and is required only when automatic
failover is required The witness server helps create a quorum to ensure that only one SQL
Server — either the principal server or the mirror server — owns the database that is
accessi-ble by the clients The witness controls automatic failure to the mirror if the principal becomes
unavailable
One witness server can be used for multiple database mirroring sessions, each for different
databases and different partners.
Transaction log records are transferred from the principal server to the mirror server synchronously
or asynchronously based on the transaction safety level that you select for the database mirroring
session Database mirroring has two transaction safety levels,SAFETY FULLandSAFETY OFF, as
detailed in Table 47-1 The failover options are described in the section ‘‘Role Switching’’ later in
this chapter
TABLE 47-1
Database Mirroring Safety Levels and Failover Options
Safety Level Operating Mode Failover Mode Witness Server Required
FULL Synchronous Database Mirroring Automatic and Manual Yes
SAFETY FULLis often referred to as synchronous database mirroring or high-safety mode In this mode,
the mirror database is in sync with the principal database at all times and provides full data safety The
following steps, shown in Figure 47-2, describe the sequence of events that occurs when you choose
SAFETY FULL:
1 The client submits a transaction to the principal database The principal server writes the
transaction log records to the transaction log buffer
2 The transaction log buffer is written to disk (also referred to as hardening of the log) and
simultaneously transfers the transaction log records from the buffer to the mirror server The
principal server waits for a confirmation from the mirror Because the principal waits for an
acknowledgment from the mirror, application response time increases and transaction
through-put is reduced slightly The actual performance impact depends on various factors, such as
your network latency, the disk subsystem, the application, and more
Trang 5There are no specific restrictions on the network for database mirroring, but the net-work connection between the servers is critical The process of determining a failover in synchronous database mirroring is based on the network connection If there is a problem with the
network, mirroring will failover or deny access to the database because of the quorum requirement.
Although mirroring is working as designed, this behavior may come as a surprise to new database
mir-roring users, because with a regular standalone server, the database is still available It is recommended
that you have a dedicated network of high quality and high bandwidth As a rule of thumb, network
bandwidth should be three times the maximum log-generation rate.
3 The mirror server writes the transaction log records to the transaction log buffer The
transac-tion log buffer is then written to disk
4 The mirror server acknowledges that the transaction has been written.
5 The commit is reported to the client.
FIGURE 47-2
Synchronous database mirroring mode
DB Log
2 5
1
SQL Server
DB Log
SQL Server
Client
Principal Server
Mirror Server
Witness Server Mirror is always
redoing–it remains current
If you chooseSAFETY FULLand have a witness server in the database mirroring configuration, then
you can achieve automatic failover This means if the principal database has a failure or is unavailable,
the witness server and the mirror server will form a quorum and the mirror server will perform an
automatic failover The mirror server will become the new principal server and will recover the database
Trang 6and start servicing the clients This operating mode is also referred to as high-safety mode with automatic
failover.
If you chooseSAFETY FULLand you do not have a witness server in the database mirroring
configura-tion, then you cannot achieve automatic failover because if the principal database fails, the mirror server
cannot form a quorum, as there is no witness server In this configuration, you need to perform a
man-ual failover This operating mode is also referred to as high-safety mode without automatic failover.
Synchronous database mirroring (high-safety mode) is supported by SQL Server 2008
Enter-prise, Developer, and Standard Editions If you implement synchronous database
mirror-ing usmirror-ing SQL Server 2008 Standard Edition, then you cannot create a database snapshot on the mirror
database for reporting purposes, as database snapshots are not supported by SQL Server 2008 Standard
Edition.
SAFETY OFFis often referred to as asynchronous database mirroring or high-performance mode This safety
level provides high performance with possible data loss In this mode, the communication between the
principal and mirror databases is asynchronous The sequence of events when you chooseSAFETY OFF
is shown in Figure 47-3
FIGURE 47-3
Asynchronous database mirroring mode
DB Log
2 3
1
SQL Server
DB Log
SQL Server
Client
Principal Server
Mirror Server
Mirror is busy keeping up with the principal
Trang 7The transaction log records are written to the principal database transaction log and sent to the mirrored
database transaction log in the same way as in synchronous mirroring mode The main difference is that
the principal does not wait for the mirror to acknowledge that the transaction has been written to disk
The transactions on the principal database commit as soon as they are written on the principal database
transaction log This increases application performance but creates a heavy load on the principal
database, or a network delay could cause the principal database transaction log, which is waiting to be
sent to the mirror database, to grow; and in the event of a failure of the principal, the unsent transaction
log records may be lost Automatic and manual failover are not enabled in high performance mode due
to possible data loss Only a forced failover is allowed in this mode
Asynchronous database mirroring (high-performance mode) is only supported by SQL Server 2008 Enterprise or Developer Editions.
Best Practice
Do not configure a witness server in high-performance operating mode because there is no use of a
witness server In fact, if you use a witness server and for some reason the witness server and mirror
server both become unavailable, the principal server will not be able to form a quorum and the principal
database will not be accessible to the clients even though the principal server is available and does not have
any issues
Configuring database mirroring
Database mirroring can be configured using one of two methods: either by using SQL Server
Manage-ment Studio or by using system-stored procedures
Pre-database mirroring configuration
With either method of configuration, the following prerequisites need to be completed before
configur-ing database mirrorconfigur-ing:
■ The principal, mirror, and witness servers all must have the same version of SQL Server (SQL Server 2005 or 2008)
■ The principal and the mirror server must have the same edition of SQL Server (Enterprise or Standard Edition)
■ The edition of the witness server (if you are configuring high-safety mode with automatic failover) can be SQL Server Express, Workgroup, Standard, or Enterprise Edition
■ The recovery model of the principal database must be set tofull
■ Ensure that there is enough disk space for the mirror database on the mirror server
■ Create the mirror database To do this, take a full database backup of the principal database and subsequent transaction log backups; copy the backups to the mirror server, and restore it
on the mirror serverWITH NORECOVERYto put it into a state that allows inserting transaction log records The name of the mirror database should be the same as the principal database
Trang 8Before you start mirroring, take a transaction log backup on the principal database and restore
it on the mirror databaseWITH NORECOVERY Do not restore the transaction log backups
WITH STANDBY— even though it’s a loading state, database mirroring will not work
Best Practice
It is recommended (but not required) that the principal and mirror databases have the same directory
structure If the directory structure is different, adding and removing file operations on the principal
database will not be allowed without suspending database mirroring
For more information about backup and restore, refer to Chapter 41, ‘‘Recovery Planning.’’
■ Communication between the SQL Servers in a database mirroring configuration is
accom-plished over TCP (Transmission Control Protocol) endpoints Each server participating in
database mirroring requires its own dedicated database mirroring endpoint Each endpoint
listens on a unique TCP/IP port
■ All the SQL Servers in a database mirroring configuration need to trust one another If they
are on the same domain, you need to ensure that each SQL Server login can connect to the
mirroring SQL Server and haveCONNECTpermission on the endpoints If the SQL Servers do
not trust one another, then you need to use certificates for the communication between the
servers
Best Practice
Use a private high-speed network between the principal and mirror servers to reduce the network
bandwidth and impact on other users SQL Server 2008 helps reduce the network bandwidth with the
log compression feature
Configuring database mirroring using Management Studio
The following steps configure database mirroring using SQL Server Management Studio:
1 In the Object Explorer on the principal server in SQL Server Management Studio, right-click
on the principal database and select Properties
2 On the Options page, verify that the recovery model isfull
3 On the Mirroring page, shown in Figure 47-4, click Configure Security button to launch the
Configure Database Mirroring Security Wizard Click Next to begin the wizard This wizard
enables you to configure the security of the principal, mirror, and witness (optional) servers
Trang 9FIGURE 47-4
Database Properties Mirroring page
4 On the Include Witness Server page, shown in Figure 47-5, click Yes if you want to operate
database mirroring in synchronous (high-safety) mode with automatic failover For other operating modes (high-safety without automatic failover and high-performance mode), click No
5 On the Choose Servers to Configure page, shown in Figure 47-6, ensure that the Witness
server instance check box is checked Click Next to continue If you selected No in the previous step, you will not see this page
6 The next page is the Principal Server Instance page, shown in Figure 47-7 As discussed
earlier, communication between the servers participating in database mirroring is accomplished over TCP endpoints Each server requires its own, dedicated database mirroring endpoint
Each endpoint listens on a unique TCP/IP port The default port shown in Figure 47-7 is
5022 For security reasons, it is recommended to use a non-default port Also, notice that by
default the check box for Encrypt data sent through this endpoint is selected It is recommended
that you leave this checkbox selected to ensure that the data transferred across the network
is encrypted If for some reason you do not need encryption, uncheck this box You can also change the endpoint name on this page Click Next to continue
Trang 10FIGURE 47-5
Selecting the witness server
FIGURE 47-6
Selecting the witness server to save the security configuration