Microsoft SQL Server 2008 R2 Unleashed- P71 pot

CHAPTER 20 Database Mirroring The ALTER DATABASE and DROP ENDPOINT SQL commands break mirroring on the principal and remove the endpoint: ALTER DATABASE AdventureWorks set partner off go

CHAPTER 20 Database Mirroring

The ALTER DATABASE and DROP ENDPOINT SQL commands break mirroring on the principal

and remove the endpoint:

ALTER DATABASE AdventureWorks set partner off

go

DROP ENDPOINT EndPoint4DBMirroring1430

go

From the mirror server instance (not the principal!), you run the DROP DATABASE and DROP

ENDPOINT SQL commands, as follows:

DROP DATABASE AdventureWorks

go

DROP ENDPOINT EndPoint4DBMirroring1440

go

From the witness server instance, you remove the endpoint as follows:

DROP ENDPOINT EndPoint4DBMirroring1450

go

To verify that you have removed these endpoints from each server instance, you simply

run the following SELECT statements:

select name,type_desc,port,ip_address from sys.tcp_endpoints

select name,role_desc,state_desc from sys.database_mirroring_endpoints

All references to the endpoints and roles are removed

You can also take a peek at the SQL Server log entries being made as you remove

data-base mirroring:

02/05/2009 13:06:42,spid55,Unknown,The Database

Mirroring protocol transport is disabled or not configured

02/05/2009 13:06:40,spid55,Unknown,The Database Mirroring

protocol transport has stopped listening for connections

02/05/2009 12:52:55,spid19s,Unknown,Database mirroring

connection error 4 ‘An error occurred while receiving

data: ‘64(The specified network name is no longer

available.)’.’ for ‘TCP:// REM1233 :1440’

02/05/2009 12:52:55,spid19s,Unknown,Error: 1474

<c/> Severity: 16<c/> State: 1

02/05/2009 12:52:55,spid19s,Unknown,Database mirroring

connection error 4 ‘An error occurred while

receiving data: ‘64(The specified network name is

no longer available.)’.’ for ‘TCP://REM1233 :1450’

02/05/2009 12:52:55,spid19s,Unknown,Error: 1474

FIGURE 20.23 Testing failover of a mirrored database

FIGURE 20.24 The failover message for database mirroring

<c/> Severity: 16<c/> State: 1

02/05/2009 12:51:14,spid21s,Unknown,Database mirroring

has been terminated for database ‘AdventureWorks’

These are all informational messages only No user action is required As you can see from

these messages, you are now in a state of no database mirroring You have to completely

build up database mirroring again if you want to mirror the database again

Testing Failover from the Principal to the Mirror

From the SSMS, you can easily fail over from the principal to the mirror server instance

(and back again) by using the Failover button on the Database Properties Mirroring page,

as shown in Figure 20.23

You must test this failover at some point to guarantee that it works When you click the

Failover button for this database mirroring configuration, you are prompted to continue

with the failover by clicking Yes or No, as in the dialog shown in Figure 20.24

ptg CHAPTER 20 Database Mirroring

FIGURE 20.25 Server instances switch roles following a failover

Remember that clicking Yes closes all connections to the principal server instance that are

currently connected to this database Later, we show you how to make your clients aware

of both the principal and mirror server instances so that they can just pick up and run

against either server instance, by design

Now, if you look at the Database Properties Mirroring page (see Figure 20.25), you see that

the principal and mirror listener port values have switched: the principal instance is now

port value 1440, and the mirror instance is port value 1430 The server instances have

completely switched their roles You must now go to the server instance playing the

princi-pal role to fail over back to the original operating mode If you try to open the current

mirror server instance database, you get an error stating that you cannot access this database

because it is in restore mode

You can also manually run an ALTER DATABASE command to force failover to the mirrored

server as follows:

ALTER DATABASE AdventureWorks set partner FAILOVER;

This command has the same effect as using SSMS or even shutting down the principal

SQL Server instance service

One last note with mirroring a database is that you cannot bring the principal offline as

you would be able to do in an unmirrored configuration

FIGURE 20.26 A client connection string configuration identifying the failover partner

Client Setup and Configuration for Database Mirroring

Microsoft has enhanced the client connection capabilities to become mirroring aware In

other words, a client application is now able to connect to either partner in a mirrored

configuration The client would, of course, be connecting only to the server instance that

is the current principal With the help of an extension to the client connection

configura-tion file, all NET applicaconfigura-tions can easily add both partners to their connecconfigura-tion string

information, and when a principal fails, they can automatically establish a connection to

the new principal (in a mirrored configuration) Figure 20.26 shows the added connection

string information that you provide in the configuration file (app.config) for your

appli-cation This enhancement uses the Failover Partner= addition that identifies the proper

failover server instance for this mirrored configuration

As a bonus, we have provided a small NET C# client application that you can easily use to

test client connections in a database mirroring configuration This C# solution file, SQL

Client DB Mirroring Test.zip, is included in the Chapter 20 code samples on the CD

supplied with this book When you expand this file, it builds a complete NET solution

directory with all code needed for this test application With Visual Studio, you just open

the WindowsApplication4.sln file (solution file), and the entire application comes up in

Visual Studio Figure 20.27 shows this simple application in Visual Studio

This simple test program displays data from the Product table in the AdventureWorks

data-base (which you are mirroring), along with the exact date and time of the data retrieval,

the name of the server instance the data came from, and the SQL process ID (SPID) of the

current server instance This way, you can easily see which physical server the data is

coming from If you are trying to use this program, all you have to do is update the

app.config file connection string entry with your two partner server instance names

(REM12374333\SQL08DE01 and REM12374333\SQL08DE02, in this example):

ConnectionString=

“Server= REM12374333\SQL08DE01;

Failover Partner= REM12374333\SQL08DE02;

Database=AdventureWorks; ”

Then you execute the test application This application automatically connects to the

current principal database (AdventureWorks on the REM12374333\SQL08DE01 server

instance, in this example), as you can see in Figure 20.28

ptg CHAPTER 20 Database Mirroring

FIGURE 20.28 A SQL client test against the current principal server instance

FIGURE 20.27 A SQL client test program for database mirroring in Visual Studio

Next, you can fail over the principal to the mirror server, using the Database Properties

Mirroring page’s Failover button (refer to Figure 20.22) After you have failed this server

over to its mirror (that is, switched roles), you simply click the Retrieve button at the

bottom of the client test program to access the data in the AdventureWorks database again

Figure 20.29 shows this subsequent data retrieval The test application shows the same

data rows, along with the date and time of this data retrieval and the name of the server

instance from which it got its data

In this case, the data came from the other partner server instance (AdventureWorks on the

REM12374333\SQL08DE02 server instance, in this example) The test application simply uses

the added connection information to reestablish its connection to the failed-over server

instance (that is, the mirror server), completely transparently to the application

FIGURE 20.29 A SQL client test against the current principal server instance (formerly the

mirror server) after failover

Migrate to Database Mirroring 2008 as Fast as

You Can

During our ramp-up on SQL Server 2008, we decided to conduct a benchmark that pitted

SQL Server 2005 database mirroring against the exact same configuration with SQL Server

2008 database mirroring Microsoft had described some performance improvements and

other added features that sounded like viable reasons to upgrade to SQL Server 2008 At

the heart of our benchmark we would be seeing how much performance improvement

was possible with the changes that Microsoft has made to compression of the transaction

log records on the principal side, their transmission to the mirror, and the restore to the

mirror Using identical servers, we conducted a fully loaded test with heavy transaction

rates—first on SQL Server 2005 and then the exact same database mirroring configuration

and transaction load on SQL Server 2008 database mirroring The results may astound

you! First, we ran a transaction sequence of 100,000 iterations of complex update and

insert processing against the SQL Server 2005 database mirroring configuration that we

built up in this chapter Figure 20.30 shows the overall load and elapsed time that

execu-tion took on SQL Server 2005

As you can see from Figure 20.30, the load was heavy, and it took 6 hours and 5 minutes

to complete the 100,000 transactions on the SQL Server 2005 database mirroring

configu-ration We then upgraded the exact same machines to SQL Server 2008 and ran the same

transaction load No other changes of any kind were made Figure 20.31 shows the overall

load and elapsed time of that identical transaction load (100,000 transactions) on SQL

Server 2008

As you can see, the exact same transaction load took 3 hours and 34 minutes to complete

This result is nearly 50% faster and is completely transparent from the database and

trans-action point of view Truly remarkable This translates into being roughly 50% faster in

high availability and failover We think this example provides more than enough

justifica-tion to upgrade to SQL Server 2008 as fast as you can

ptg CHAPTER 20 Database Mirroring

FIGURE 20.31 Transaction benchmark against SQL Server 2008 database mirroring

FIGURE 20.30 Transaction benchmark against SQL Server 2005 database mirroring

Summarizing, the benchmark results are as follows:

Overall send rate 41% faster (2008 versus 2005)

Overall restore rate 52% faster (2008 versus 2005)

Overall availability topology inherits the restore rate yielding ~50% more availability

We would like to thank the Peace Health database team of John Martin and Jason

Riedberger for flawless benchmarking on both of these topologies

SQL Server 2008

Publisher

Principal

Server

SQL Server 2008

Mirror Server

SQL Server 2008

Distributor

Principal Server

SQL Server 2008

Witness

Server

SQL Server 2008

Subscriber

SQL Server 2008

Subscriber

SQL Server 2008

Mirror Server

FIGURE 20.32 Rolling out database mirroring failover within data replication for scalability,

availability, and fault tolerance

Using Replication and Database Mirroring Together

SQL Server 2008 allows you to use combinations of options to achieve higher availability

levels A prime example would be to combine data replication with database mirroring to

provide maximum availability of data, scalability to users, and fault tolerance via failover,

potentially at each node in a replication topology By starting with the publisher and

perhaps the distributor, you make them both database mirror failover configurations

Figure 20.32 shows a possible data replication and database mirroring configuration

(data-base mirroring of the publisher and data(data-base mirroring of the distributor) For further

explanation of a transactional replication topology, see Chapter 19, “Replication.”

Using database mirroring and replication together is essentially the best of both worlds:

you get the super-low latency of database mirroring for fault tolerance, and you get high

ptg CHAPTER 20 Database Mirroring

SQL Server 2008

SQL

Server

Copy of original pages for snapshot only when a page is changed

System Catalog

of changed pages

Data Pages

Adventure

Works DB

Snapshot AdventureWorks DB

FIGURE 20.33 Database snapshots and the original database share pages and are managed

within the system catalog of SQL Server 2008

availability (and scalability) of data through replication The downside of this type of

combined capability is that it requires additional servers (for mirroring of the databases)

The upside is the increased scalability and resilience of your applications

Using Database Snapshots from a Mirror for Reporting

A powerful configuration to help offload reporting workload is to use database snapshots

with database mirroring A database snapshot is a highly efficient feature of SQL Server

2008 that allows for the generation and use of a read-only, stable view of a database at a

moment in time (hence, it’s called a snapshot) The database snapshot is also created

without the overhead of creating a complete copy of the database or having completely

redundant storage A database snapshot is simply a reference point of the pages used in

the database (that is defined in the system catalog) When pages are updated, a new page

chain is started that contains the data pages changed since the database snapshot was

taken, as illustrated in Figure 20.33

SQL Server 2008

Principal

Server

Adventure Works DB translog

SQL Server 2008

Witness

SQL Server 2008

Mirror Server

Adventure Works DB translog

Network

Reporting Users

Repor tin g Use rs

Rep orting Users

Database Snapshot

FIGURE 20.34 A database snapshot defined from a mirror server for reporting use

As the original database diverges from a snapshot, the snapshot gets its own copy of

origi-nal pages when they are modified The copy-on-write technology used for database

mirroring also enables a database snapshot When a database snapshot is created on a

database (a mirror database, in this case), all writes check the system catalog of changed

pages first; if the snapshot is not there, the original page is copied (using copy-on-write)

and is put in a place for reference by the database snapshot (because the snapshot must be

kept intact) In this way, a database snapshot and the original database share the data

pages that have not changed

Unlike a mirror database, a database snapshot can be accessed by a reporting client in

read-only mode, as shown in Figure 20.34 As long as the mirror server is communicating

to the principal, reporting clients can access the snapshot database

If the principal fails over to the mirror server, the connections to the snapshot database

are disconnected during the database restart process (which makes the mirror server the

new principal server) It is possible to reconnect the reporting clients to the database

snap-shot after a failover is completed, but you must remember that now both the transactional

clients and reporting clients are connected to a single SQL Server instance This may not

be acceptable from a performance point of view Also, it is always a good idea to keep the

number of snapshots to a minimum when creating them against a database mirror

Chapter 32, “Database Snapshots,” covers how to create database snapshots