Microsoft SQL Server 2008 R2 Unleashed- P69 docx

As you can see, no server network addresses are set up for database mirroring of any kind, and the mirroring status says “This Database Has Not Been Configured for Mirroring.” Next, we l

FIGURE 20.2 Trying to mirror a database that is not using the full database recovery model

advise that you use something that is repeatable, such as SQL scripts, and you can easily

generate SQL scripts by using the new wizard It’s not fun to have to re-create or manage a

database mirroring configuration in the middle of the night Having this whole process in

a script reduces almost all errors

Getting Ready to Mirror a Database

Before you start setting up and configuring a database mirroring environment, it is always

best to run through a simple checklist of basic requirements:

1 Verify that all server instances are at the same service pack level In addition, the

SQL Server edition you have must support database mirroring

2 Verify that you have as much or more disk space available on the mirror server as on

the principal server You also need the same room for growth on both

3 Verify that you have connectivity to each server from the others You can most

easily do this by trying to register each SQL Server instance in SSMS If you can

regis-ter the server, the server can be used for database mirroring Do this for the

princi-pal, mirror, and witness servers

4 Verify that the principal server database that is to be mirrored is using the full

data-base recovery model Right-click on the datadata-base you intend to mirror, choose Tasks,

and then Mirroring This brings you to the database mirroring properties dialog

where you can configure mirroring If you try to start configuring database mirroring

and the database recovery model is not full for the principal database, you get a

nasty message to that effect (see Figure 20.2) Because database mirroring is

transac-tion log based, it makes sense to be using the full database recovery model: all

trans-actions are written to the transaction log and are not truncated, as with other

database recovery models

Before you go any further, you must establish the endpoints for each of the servers that

will be a part of the database mirroring configuration You can use the Configure Security

option of the wizard to do this, but getting into the practice of using SQL scripts is really

the best approach Using SQL scripts is very easy, as you will soon see

FIGURE 20.3 The Database Properties Mirroring page: mirroring network addressing and

mirroring status

Endpoints utilize TCP/IP addressing and listening ports for all communication between

the servers Within a server, the endpoint is given a specific name (that is, an endpoint

name) for easy reference and to establish the partner roles that this server (endpoint) will

possibly play In addition, a connection GRANT is needed for access to be allowed from

each server to the other, and a service account should be used for this This service

account is usually a particular login that is known to the domain and is to be used for all

connections in the database mirroring topology Figure 20.3 shows the mirroring database

properties of the AdventureWorks database on a SQL Server instance named SQL08DE01 As

you can see, no server network addresses are set up for database mirroring of any kind,

and the mirroring status says “This Database Has Not Been Configured for Mirroring.”

Next, we look at how to set up high safety with automatic failover mode

(high-availabil-ity mode) database mirroring with principal, mirror, and witness servers For this, you

can mirror the old reliable AdventureWorks database that Microsoft provides with SQL

Server 2008

Figure 20.4 illustrates the database mirroring configuration to set up

The initial principal server is the SQL Server instance named SQL08DE01, the initial mirror

server is the SQL Server instance named SQL08DE02, and the witness server is the SQL

Server instance named SQL08DE03

You need to establish a local endpoint named EndPoint4DBMirroring9xxx on each of these

SQL Server instances and identify the TCP listening port that will be used for all database

mirroring communication We also like to embed the port number as part of the endpoint

name, such as EndPoint4DBMirroring1430 for the endpoint that will be listening on port

1430 In our configuration, the principal server will be listening on Port 1430, the mirror

server on Port 1440, and the witness server on Port 1450 These port numbers must be

unique within a single server machine, and the machine name and port combination

must be unique within the network An example of the fully qualified network address

name of this server and the listing port is TCP://REM1237433.ads.autodesk.com:1430,

where REM1237433.ads.autodesk.com is the machine name within the domain, and 1430

is the listening port created with the endpoint In addition, each server’s initial role needs

to be specified The SQL08DE01 instance can play any partner role (that is, a mirror and/or

principal), the SQL08DE02 instance can play any partner role as well, and the SQL08DE03

instance should play the witness role only

We have included three SQL script templates with this book (in the Chapter 20 code

direc-tory on the CD) that have working examples of creating the endpoints, granting

connec-tion permissions to a login for the endpoints, verifying that the endpoints were created,

SQL Server 2008

Principal

Server

Adventure Works DB translog

SQL Server 2008

Witness Server MSDB DB

SQL Server 2008

Mirror Server

Adventure Works DB translog

Instance: SQL08DE01

Endpoint name: “EndPoint4DBMirroring1430”

Role: PARTNER

Instance: SQL08DE03 Endpoint name: “EndPoint4DBMirroring1450”

Role: WITNESS

TCP: Listener_Port:1430 TCP: Listener_Port:1440

TCP: Listener_Port:1450

Instance: SQL08DE02 Endpoint name: “EndPoint4DBMirroring1440”

Role: PARTNER

FIGURE 20.4 A high-availability database mirroring configuration with the AdventureWorks

database

altering the endpoints, backing up and restoring databases, and backing up and restoring

transaction logs

The first ones to look at are 2008 Create EndPoint Partner1.SQL, 2008 Create EndPoint

Partner2.SQL, and 2008 Create EndPoint Witness.SQL You can leverage these templates

to start the setup process if you are not using the Configure Security Wizard

Now that we’ve verified all aspects of our planned mirroring topology, let’s configure full

database mirroring!

Creating the Endpoints

Each server instance in the database mirroring configuration must have an endpoint

defined so that the other servers can communicate with it This is sort of like a private

phone line to your friends Let’s use the scripts provided as opposed to using the

Configure Security Wizard The first endpoint script is in the file 2008 Create EndPoint

Partner1.SQL

From SSMS, you need to open a new query connection to your principal database by

selecting File, New and in the New Query dialog, selecting Query with Current

Connection Open the SQL file for the first endpoint

The following CREATE ENDPOINT T-SQL creates the endpoint named

EndPoint4DBMirroring1430, with the listener_port value of 1430, and the database

mirroring role Partner:

create endpoint for principal server

CREATE ENDPOINT [EndPoint4DBMirroring1430]

STATE=STARTED

AS TCP (LISTENER_PORT = 1430, LISTENER_IP = ALL)

FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE

, ENCRYPTION = REQUIRED ALGORITHM RC4)

After this T-SQL runs, you should quickly run the following SELECT statements to verify

that the endpoint has been correctly created:

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

SELECT db.name, m.mirroring_role_desc

FROM sys.database_mirroring m

JOIN sys.databases db

ON db.database_id = m.database_id

WHERE db.name = N’AdventureWorks’;

select name,role_desc,state_desc from sys.database_mirroring_endpoints;

Figure 20.5 shows the desired result set from these queries

If you also look at the database properties for the AdventureWorks database on the

princi-pal server (SQL08DE01, in this example), you see the server network address for the

princi-pal server automatically appear now when you look at the Database Properties Mirroring

page (see Figure 20.6)

Starting with the sample SQL scripts 2008 Create EndPoint Partner2.SQL and 2008

Create EndPoint Witness.SQL, you need to repeat the endpoint creation process for the

mirror server (using a listener_port value of 1440) and the witness server (using a

listener_port value of 1450) by opening a query connection to each one of these servers

and running the following CREATE ENDPOINT commands:

create endpoint for mirror server

CREATE ENDPOINT [EndPoint4DBMirroring1440]

STATE=STARTED

AS TCP (LISTENER_PORT = 1440, LISTENER_IP = ALL)

FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE

, ENCRYPTION = REQUIRED ALGORITHM RC4)

For the witness server (notice that the role is now Witness), you run the following:

FIGURE 20.5 Verifying that an endpoint is created for database mirroring

FIGURE 20.6 The Mirroring page of the AdventureWorks database on the principal server.

create endpoint for witness server

CREATE ENDPOINT [EndPoint4DBMirroring1450]

STATE=STARTED

AS TCP (LISTENER_PORT = 1450, LISTENER_IP = ALL)

FOR DATA_MIRRORING (ROLE = WITNESS, AUTHENTICATION = WINDOWS NEGOTIATE

, ENCRYPTION = REQUIRED ALGORITHM RC4)

Granting Permissions

It is possible to have an AUTHORIZATION [login] statement in the CREATE ENDPOINT

command that establishes the permissions for a login account to the endpoint being

defined However, separating this out into a GRANT greatly stresses the point of allowing

this connection permission From each SQL query connection, you run a GRANT to allow a

specific login account to connect on the ENDPOINT for database mirroring If you don’t

have a specific login account to use, default it to [NT AUTHORITY\SYSTEM]

First, from the principal server instance (SQL08DE01), you run the following GRANT

(substi-tuting [DBARCHLT\Paul Bertucci] with your specific login account to be used by database

mirroring):

GRANT CONNECT ON ENDPOINT::EndPoint4DBMirroring1430 TO [DBARCHLT\Paul Bertucci];

Then, from the mirror server instance (SQL08DE02), you run the following GRANT:

GRANT CONNECT ON ENDPOINT:: EndPoint4DBMirroring1440 TO [DBARCHLT\Paul Bertucci];

Then, from the witness server instance (SQL08DE03), you run the following GRANT:

GRANT CONNECT ON ENDPOINT:: EndPoint4DBMirroring1450 TO [DBARCHLT\Paul Bertucci];

Creating the Database on the Mirror Server

When the endpoints are configured and roles are established, you can create the database

on the mirror server and get it to the point of being able to mirror You must first make a

backup copy of the principal database (AdventureWorks, in this example) This backup

will be used to create the database on the mirror server You can use SSMS tasks or use

SQL scripts to do this The SQL scripts (DBBackupAW2008.sql), which are easily repeatable,

are used here

On the principal server, you make a complete backup as follows:

BACKUP DATABASE [AdventureWorks]

TO DISK = N’C:\Program Files\Microsoft SQL

Server\MSSQL.2\MSSQL\Backup\AdventureWorks4Mirror.bak’

WITH FORMAT

GO

Next, you copy this backup file to a place where the mirror server can reach it on the

network When that is complete, you can issue the following database RESTORE

command to create the AdventureWorks database on the mirror server (using the WITH

NORECOVERY option):

use this restore database(with NoRecovery option)

to create the mirrored version of this DB

RESTORE FILELISTONLY

FROM DISK = ‘C:\Program Files\Microsoft SQL

Server\MSSQL.2\MSSQL\Backup\AdventureWorks4Mirror.bak’

go

RESTORE DATABASE AdventureWorks

FROM DISK = ‘C:\Program Files\Microsoft SQL

Server\MSSQL.2\MSSQL\Backup\AdventureWorks4Mirror.bak’

WITH NORECOVERY,

MOVE ‘AdventureWorks_Data’ TO ‘C:\Program Files\Microsoft SQL

Server\MSSQL.4\MSSQL\Data\AdventureWorks_Data.mdf’, MOVE ‘AdventureWorks_Log’ TO ‘C:\Program Files\Microsoft SQL

Server\MSSQL.4\MSSQL\Data\AdventureWorks_Log.ldf’

GO

Because you don’t necessarily have the same directory structure on the mirror server,

you use the MOVE option as part of this restore to place the database files in the location

The restore process should yield something that looks like the following result set when

restoring the AdventureWorks database that is shipped with SQL Server 2008:

Processed 21200 pages for database ‘AdventureWorks’,

file ‘AdventureWorks_Data’ on file 1

Processed 2 pages for database ‘AdventureWorks’,

file ‘AdventureWorks_Log’ on file 1

RESTORE DATABASE successfully processed 21202 pages

in 14.677 seconds (11.833 MB/sec)

Basically, this result set says you are not ready to get into the mirroring business yet You

must now apply at least one transaction log dump to the mirror database This brings the

mirror database to a point of synchronization with the principal and leaves the mirror

database in the Restoring state At this database recovery point, you can run through the

mirroring wizard and start mirroring for high availability

From the principal server, you dump (that is, back up) a transaction log as follows:

BACKUP LOG [AdventureWorks] TO

DISK = N’C:\Program Files\Microsoft SQL

Server\MSSQL.2\MSSQL\Backup\AdventureWorksLog.bak’

Go

Processed 8 pages for database ‘AdventureWorks’, file ‘AdventureWorks_Log’ on file 2

Then you move this backup to a place where it can be reached by the mirror server When

that is done, you restore the log to the mirror database From the mirror server, you

restore the transaction log as follows Note the following WITH FILE = statement; the file

number must match the value in the backup log results (see the on file 2 reference in

the previous code):

RESTORE LOG [AdventureWorks]

FROM DISK = N’C:\Program Files\Microsoft SQL

Server\MSSQL.4\MSSQL\Backup\AdventureWorksLog.bak’

WITH FILE = 2, NORECOVERY

GO

The restore log process should yield something that looks like the following result set:

RESTORE LOG successfully processed 8 pages

in 0.034 seconds (9.396 MB/sec)

NOTE

You might need to update the FILE = x entry in the RESTORE LOG command to

corre-spond to the “on file” value given during the log backup

You are now ready to mirror the database in high-availability mode

Identifying the Other Endpoints for Database Mirroring

To get each node in the topology to see each other, you have to identify the endpoints

and listener port values to the databases involved in the database mirroring configuration

(the principal and mirror) This also activates database mirroring This process requires

altering the database by using either the SET PARTNER or SET WITNESS statements within

the ALTER DATABASE command The Database Mirroring Wizard can also do this step for

you, but doing it manually is easy

We identify the unique endpoint listening port values for each endpoint that are unique

within the server They are port values 1430, 1440, and 1450 in our example

Remember, you will be doing this after you create the AdventureWorks database on the

mirror server side After creating that database, you can run the following ALTER DATABASE

command on the mirror server to identify the principal for the mirror to partner with:

From the Mirror Server Database: identify the principal server endpoint

ALTER DATABASE AdventureWorks

SET PARTNER = ‘ TCP://REM1237433.ads.autodesk.com:1430’

GO

Now, you are ready for the final step From the principal server, you identify the mirror

and witness After you complete these step, the database mirroring topology tries to

synchronize itself and begin database mirroring The following statements identify the

mirror server endpoint and witness server endpoint to the principal server’s database:

From the Principal Server Database: identify the mirror server endpoint

ALTER DATABASE AdventureWorks

SET PARTNER = ‘TCP://REM1237433.ads.autodesk.com:1440’

GO

From the Principal Server Database: identify the witness server endpoint

ALTER DATABASE AdventureWorks

SET WITNESS = ‘TCP://REM1237433.ads.autodesk.com:1450’

GO

You do not have to alter any database from the witness server

When this process completes successfully, you are mirroring! Yes, in fact, with this

config-uration, you are in automatic failover mode

If you have issues or just want to start over, you can drop an endpoint or alter an endpoint

quite easily To drop and existing endpoint, you use the DROP ENDPOINT command In this

example, the following command would drop the endpoint you just created:

To DROP an existing endpoint

DROP ENDPOINT EndPoint4DBMirroring1430;

Altering an endpoint (for example, to change the listener_port value) is just as easy as

dropping one The following example shows how to alter the currently defined endpoint

FIGURE 20.7 The Mirror option for the principal database server (AdventureWorks)

because we use the port in the endpoint name, it might have been best to just drop and

create a new endpoint to fit the naming convention Either way, you can easily

manipu-late these endpoints to fit your networking needs.)

To ALTER an existing endpoint

ALTER ENDPOINT EndPoint4DBMirroring1430

STATE = STARTED

AS TCP( LISTENER_PORT = 1435 )

FOR DATABASE_MIRRORING (ROLE = PARTNER)

Configuring Database Mirroring by Using the Wizard

After you have the endpoints created, the roles established, the connections to the

endpoints granted, and the mirror database restored on the mirror server, you could easily

run through the final short steps in the Database Mirroring Wizard to enable and start

mirroring Figure 20.7 shows the Mirror option from the AdventureWorks database

(reached by right-clicking the database name) from what will be the principal server

Because this database is not enabled for mirroring yet, you must run through the

Configure Security option on the top portion of the Mirroring page (refer to Figure 20.6)

At this point, you can probably see only the network server address of the principal server

Don’t worry; the rest (mirror and witness network server addresses) will be established and

identified during the Configure Database Mirroring Security Wizard steps