For more information on all the performance counters available for database mirroring, refer to the SQL Server 2008 Books Online resource ‘‘SQL Server, Database Mirroring Object’’: http:
Trang 1FIGURE 47-15
Monitoring a database mirroring session
Monitoring using System Monitor
Apart from using the Database Mirroring Monitor, you can also use System Monitor (previously referred
to as Performance Monitor) to monitor database mirroring performance TheSQLServer:Database
Mirroringobject contains the database mirroring performance counters The following list describes
some of the key counters
Key principal server counters:
■ Log Bytes Sent/sec: Indicates the rate at which the principal is transferring transaction log records to the mirror
■ Log Send Queue KB: Indicates the total number of transaction log kilobytes that have not been sent to the mirror yet
■ Transaction Delay: Indicates the delay in milliseconds spent waiting for the commit acknowl-edgment from the mirror This counter is useful for determining whether database mirroring is impacting performance on the principal server
Trang 2FIGURE 47-16
Database mirroring history
FIGURE 47-17
Setting warning thresholds
Trang 3FIGURE 47-18
Database mirroring warnings
■ Log Compressed Bytes Sent/sec: Indicates the number of compressed bytes of transaction log sent in the last second To find the factor by which the transaction log stream has been
compressed, also referred to as log compression ratio, divide the Log Bytes Sent/sec by Log
Compressed Bytes Sent/sec
■ Log Bytes Sent from Cache/sec: Indicates how much of the transaction log bytes being sent from the principal to the mirror is being read from the principal’s in-memory transaction log cache
Key mirror server counters:
■ Redo Bytes/sec: Indicates the rate at which log bytes are being rolled forward on the mirror database
■ Redo Queue KB: Indicates the total number of transaction log kilobytes that have not been rolled forward to the mirror database yet To estimate the time it will take the mirror to redo the log, divide Redo Queue KB by Redo Bytes/sec
Trang 4■ Log Bytes Received/sec: Indicates the rate at which the log bytes are received from the
principal To estimate the time it will take the mirror to catch up with the principal, divide
Log Send Queue KB by Log Bytes Received/sec
■ Log Compressed Bytes Received/sec: Indicates the number of compressed transaction log
bytes received in the last second
■ Log Bytes Redone from Cache/sec: Indicates the number of redone transaction log bytes that
were read from the mirror’s in-memory transaction log cache
For more information on all the performance counters available for database mirroring,
refer to the SQL Server 2008 Books Online resource ‘‘SQL Server, Database Mirroring
Object’’: http://msdn.microsoft.com/en-us/library/ms189931.aspx
Monitoring using SQL Server Profiler
To capture the time taken to switch from the principal to the mirror, launch the SQL Server Profiler tool
as follows:
1 From the Start menu, select Programs➪ Microsoft SQL Server 2008 ➪ Performance Tools ➪
SQL Server Profiler
2 Select New Trace from the File menu.
3 This is will bring up the Connect to Server dialog Enter the principal server information and
click Connect
4 On the Trace Properties dialog, enter the trace name in the General tab.
5 On the Trace Properties dialog, click the Events Selection tab Select the Show all events check
box Expand the Database event and select the Database Mirroring State Change check box
Select the columns TextData (gives a description of the database mirroring state change) and
StartTime (indicates the time at which the event started).
6 Click Run to start the capture.
Pausing or Removing Database Mirroring
After configuring database mirroring you can pause, resume, or remove database mirroring If database
mirroring is affecting your application’s performance, you may want to pause a database mirroring
ses-sion Pausing a database mirroring session causes the mirroring state to change toSUSPENDED During
this time, the principal will not send any transactions to the mirror, and its principal database’s
transac-tion log will continue to grow even if you have scheduled transactransac-tion log backups The transactransac-tion log
will not be truncated because it has to send the transactions to the mirror once the database mirroring
session is resumed
To pause a database mirroring session 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 Mirroring page (refer to Figure 47-13), click the Pause button.
Trang 53 You will be prompted for confirmation Click Yes This will pause the database mirroring
session, changing the Pause button to Resume
4 Click the Resume button to resume the database mirroring session.
To pause the database mirroring session for theAdventureWorksdatabase in code, connect to either
the principal or mirror server and execute the following:
ALTER DATABASE AdventureWorks SET PARTNER SUSPEND;
To resume the database mirroring session for theAdventureWorksdatabase in code, connect to either
the principal or mirror server and execute the following:
ALTER DATABASE AdventureWorks SET PARTNER RESUME;
To remove a database mirroring session 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 Mirroring page (refer to Figure 47-13), click the Remove Mirroring button.
3 You will be prompted for confirmation Click Yes to confirm, which removes the database
mirroring session This means that the relationship between the partners and witness will be removed and each partner will be left with a separate copy of the database The mirroring database will be left in theRESTORINGstate, as the database was created using theRESTORE WITH NORECOVERYcommand
4 To resume a database mirroring session after removing it, you need to configure a new
database mirroring session as explained earlier in this chapter
To remove the database mirroring session for theAdventureWorksdatabase in code, connect to either
the principal or mirror server and execute the following:
ALTER DATABASE AdventureWorks SET PARTNER OFF;
Role Switching
Role switching in database mirroring is the process of changing the principal and mirror roles Three
types of role switching exist based on the database mirroring operating mode: automatic failover, manual
failover, and forced failover
Automatic failover is available only in synchronous mode with failover In this mode, if the principal
database becomes unavailable due to any failure and the mirror and witness servers are still connected
and the mirroring state isSYNCHRONIZED, automatic failover will occur Here is a high-level sequence
of events that occur in an automatic failover scenario:
1 The principal database becomes unavailable due to some failure.
2 If the principal server is still available, the state of the principal database is changed to
DISCONNECTEDand all the clients are disconnected from the principal database
3 The mirror and the witness server detect the failure.
Trang 6The default timeout for communication between the principal, mirror, and witness servers
is 10 seconds If the principal does not respond within the timeout period, it is considered
to be down If you are using high-safety mode, you can change the timeout period using the ALTER
DATABASE SET PARTNER TIMEOUT command The default timeout of 10 seconds works well for most
environments If you do want to change the timeout period, then it is recommended not to set it below
10 seconds, as this may cause false failures.
4 The mirror server recovers the mirror database.
5 The mirror server forms a quorum with the witness server.
6 The mirror server becomes the new principal server and it brings the mirror database online
as the new principal database
7 The old principal server, when it is back online, takes the mirror role and the old principal
database becomes the new mirror database and starts synchronizing with the new principal
database
Manual failover is available only in synchronous mode with and without failover As the name suggests,
you decide whether to switch the roles of the servers and manually failover the database Manual failover
is used for planned downtime (for example, during hardware or software upgrades) Manual failover is
allowed only when the partners are connected and the mirroring state isSYNCHRONIZED During a
manual failover, the clients are disconnected from the principal database and the roles of the partners
are switched
To perform a manual failover 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 Mirroring page (refer to Figure 47-13), click the Failover button.
3 When prompted for confirmation, click Yes to perform a manual failover.
To perform a manual failover for the AdventureWorksdatabase in code, connect to the principal
server and execute the following:
ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;
Forced failover, also referred to as forced service (with possible data loss) is available only in synchronous
mode without failover and asynchronous mode If the principal server is lost, the principal database will
be unavailable to the clients You can make the database available by manually forcing service on the
mirror server by executing the following command on the mirror server:
ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;
This will bring the database online on the mirror server, which becomes the new principal server
When the old principal server becomes available, it will automatically assume the mirror role but the
database mirroring session will be suspended To resume the database mirroring session, follow the steps
discussed earlier in the chapter
After any type of failover, clients must reconnect to the new principal database If your applications use
Microsoft ADO.NET or SQL Native Client to connect to a database, then in case of a database
mirror-ing failover, the applications can automatically redirect the clients to the current principal database You
Trang 7must specify the initial principal server and database and failover partner server in the connection string.
The failover partner in the connection string is used as an alternate server name if the connection to the
initial principal server fails If your applications do not use Microsoft ADO.NET or SQL Native Client
automatic redirection, you need to use other methods such as network load balancing (NLB), a Domain
Name System (DNS) alias, or custom code that will enable your application to failover
After the role-switching process is completed, verify that any database objects such as logins, jobs,
main-tenance plans, SSIS packages, and linked servers that reside outside the mirror database are created on
the mirror server For example, if the logins are not created on the mirror server, then users will not be
able to connect and you will still have a server down situation
Best Practice
Ihighly recommend thoroughly executing the role-switching steps and documenting them prior to needing
to failover to the mirror server Failure to do this can significantly increase downtime and complexity
when you actually need to failover to the mirror server
Summary
Database mirroring is an inexpensive software-based solution to achieve high database availability
Database mirroring works by transferring transaction log records from the production database on one
SQL Server to a mirror database on another SQL Server over the network, either synchronously or
asynchronously Asynchronous database mirroring provides the best performance but has the potential
for data loss and does not support automatic failover Synchronous database mirroring provides a higher
level of data protection than asynchronous mode and provides automatic and manual failover options at
the cost of reduced application performance
At first glance, database mirroring may appear to be better than log shipping but it is not a replacement
for log shipping Each solution has unique features, and depending on your business requirements you
may need to select one or both solutions For example, log shipping supports multiple copies of the
production databases, but database mirroring allows only one copy of the production database If you
need multiple copies of the production database and the features of database mirroring, then you can
implement database mirroring and log shipping Database mirroring also complements existing failover
clustering implementations
As with any other solution, take a performance baseline of your environment before and after
config-uring database mirroring, and use your performance data to help you determine whether you should
use database mirroring or whether you should use synchronous mode or asynchronous mode in your
production environment
The next chapter discusses failover clustering, which is the only Microsoft SQL Server 2008
high-availability solution that provides both high high-availability for an entire instance of SQL Server and the
automatic failover option
Trang 8IN THIS CHAPTER
Understanding SQL Server
2008 failover clustering Enhancements in SQL Server
2008 failover clustering Installing a SQL Server 2008 failover cluster
Performing rolling upgrade and patching
Maintaining and troubleshooting a SQL Server
2008 failover cluster
Remember the sitcoms in the 1970s with identical twins? They could
switch clothes and fool the teacher, or wear the same clothes and switch
boyfriends halfway through a date I’ve wondered what life would
have been like if I had a twin I suspect that we would have gotten in more
trouble together than I got into alone Having twins brings a whole new set of
‘‘opportunities.’’
SQL Server failover clustering is like having identical twin SQL Servers They
share the same clothes, and look exactly alike When one gets into trouble, the
other can step right in and continue the job with barely a hiccup Similarly, like
human twins, SQL Server failover clusters bring their own set of challenges This
chapter introduces the SQL Server twins and walks through all their twin tricks
so you won’t be caught by their jokes
SQL Server 2008 Failover Clustering
Basics
SQL Server 2008 failover clustering is built on top of Windows failover
cluster-ing to provide high availability for the entire SQL Server 2008 instance A
high-availability SQL Server solution masks the effects of a hardware or software failure
and maintains the availability of SQL Server so that any downtime for users is
minimized
Achieving 100 percent uptime is desirable but virtually impossible, if for no other
reason than that at certain times, a security patch or service pack must be applied
to the production server to make it secure and stable This is where the concept
of ‘‘nines’’ comes into play The percentage of uptime all companies should strive
for is some variation of 99.x percent where x is the specified number of nines.
Five nines is 99.999 percent uptime for your server, which is considered to be
Trang 9the ultimate in availability, as it means about five minutes of total downtime in a calendar year Note
that not all downtime is planned We all know that even with the best storage subsystems, disks fail or
network interface cards fail or there is a power failure Also, memory leaks in the application or bugs in
the OS or SQL Server can cause a failure Three nines, which means about nine hours of downtime in a
calendar year, is a more practical number to strive for
What’s New in SQL Server 2008 failover clustering?
SQL Server 2008 failover clustering has changed considerably to provide better supportability and reliability
and higher availability The setup architecture has changed completely to enable features that were not
possible in earlier versions of SQL Server There is a completely new setup user interface that supports both
SQL Server and Analysis Services failover clustering
Here are some of the key new features in SQL Server 2008 failover clustering These features are discussed
in detail in the section ‘‘Enhancements in SQL Server 2008 failover clustering.’’
■ Reliable setup experience
■ Reduced downtime with rolling upgrade and patching
■ High availability with Add/Remove node operations
■ Integrated with Windows Server 2008 failover cluster features
■ Positioned to enable Sysprep and slipstream
SQL Server 2008 failover clustering, shown in Figure 48-1, consists of the following:
■ Two or more cluster servers, known as nodes
■ Shared disk storage
■ Two or more networks
■ Virtual SQL IP address and SQL Network Name for clients to connect
■ Windows Server 2003/2008 Failover Clustering
A SQL Server 2008 failover clustering instance appears on the network as a stand-alone SQL Server
2008 instance, but it has functionality that provides failover from one node to another if the current
node becomes unavailable The failover is handled by the Windows Server failover cluster, which detects
that the current node is no longer available and then accordingly handles the failover of the SQL Server
to another node All clients are disconnected during the failover and need to reconnect following it
However, they connect to the same ‘‘virtual SQL network name’’ or ‘‘virtual SQL IP address’’ as before
Before investing in a SQL Server 2008 failover cluster solution it is very important to know how it
works, what it can do, and what it cannot do Many DBAs are familiar with Oracle clustering and may
have different expectations from Microsoft failover clustering Microsoft failover clustering provides the
following benefits:
■ High availability: Microsoft Windows failover clustering provides protection from machine-level failures such as hardware and software failures, service failures, and site-machine-level failures such
Trang 10as hurricanes, fires, and so on When a system or application in the cluster fails, the cluster
software detects the failure and automatically restarts the failed application on a surviving
server It also allows software/hardware upgrades with minimum downtime
■ Improved manageability: It enables managing services within the entire cluster, as if
man-aging a single computer Applications can be moved to different servers within the cluster
You can manually balance the server workload and free servers for planned maintenance
Using the Cluster Administrator tool in Windows 2003 Failover Cluster or the Failover Cluster
Management tool in Windows 2008 Failover Cluster, you can monitor the status of the cluster,
all nodes, and resources from anywhere on the network
■ Increased scalability: The cluster can grow to meet increased demands For example, when
the load for an application exceeds the resources of the cluster node, it supports the addition
of processors, memory, and nodes if required
■ Instance-level redundancy and automatic failover for SQL Server instances: When
a node or resource (disk, IP address, or network name) fails, Windows failover clustering
detects it and automatically restarts the entire SQL server instance on the other node SQL
Server failover clustering is the only high-availability option offered by Microsoft that
pro-vides instance-level redundancy Database mirroring, log shipping, and replication all provide
database redundancy, not instance-level redundancy
FIGURE 48-1
Typical SQL Server 2008 failover cluster
Node1
SQLVS1
192.168.100.14 192.168.100.15SQLVS2 192.168.100.16SQLVS3
Client PCs Public Network
Node2 Node3 Node4
Redundant
Fibre Channel
Switched
Fabric
Shared Disk Storage
Cluster Nodes Private Network