Microsoft SQL Server 2008 R2 Unleashed- P112 ppsx

CHAPTER 32 Database Snapshots SQL Server 2008 Source Server BEFORE TEST Snapshot Testing Users Restore from the BEFORE snashot after testing cycle is complete and can continue with nex

CHAPTER 32 Database Snapshots

SQL Server 2008

Source

Server

BEFORE TEST Snapshot

Testing Users

Restore from the BEFORE snashot

after testing cycle is complete and can

continue with next test.

Adventure Works DB

Database Snapshot

FIGURE 32.8 Establishing a baseline testing database snapshot before running tests and

then reverting when finished

Providing a Testing (or Quality Assurance) Starting Point (Baseline)

In testing and the QA phases of your development life cycle, you often need to conduct

tests over and over These are either logic tests or even performance tests To aid testing

and QA, database snapshots can be made of a test database prior to full testing (create a

testing baseline database snapshot) and then the test database can be reverted back to its

original state at a moment’s notice, using that baseline snapshot This procedure can be

done any number of times Figure 32.8 shows how easy it is to simply create a testing

reference point (or synchronization point) with a database snapshot

You then just run your test scripts or do any manual testing—as much as you want—and

then revert back to this starting point rapidly Then you run more tests again

Providing a Point-in-Time Reporting Database

If what you really need is a true point-in-time reporting database from which you can run

ad hoc or canned reports, often a database snapshot can serve this purpose much better

than resorting to log shipping or data replication Key to determining when you can use

this database snapshot technique is whether the reporting load on this database server

instance can easily support the reporting workload and whether the update transactions

against this database are adversely affected by the database snapshot overhead of each

transaction Figure 32.9 shows the typical database snapshot configuration for one or

more database snapshots that are to be used for reporting

Remember, this is a point-in-time snapshot of the source database How frequently you

need to create a new snapshot is dictated by your reporting requirements for data latency

(how old the data can be in these reports)

Providing a Highly Available and Offloaded Reporting Database from

a Database Mirror

If you are using database mirroring to improve your availability, you can also create a

database snapshot against this mirrored database and expose the snapshot to your

report-ing users Even though the mirrored database cannot be used for any access whatsoever (it

is in constant restore mode), SQL Server allows a snapshot to be created against it (as

shown in Figure 32.10) This is a very powerful configuration in that a database snapshot

against a mirror does not impact the load of the principal server—guaranteeing high

performance against the principal server Also, when the database snapshot is isolated over

to the mirror server, the performance of the reporting users is also more predictable

SQL Server 2008

Source

Server

Transactional Users

Point-in-time Reporting Users (Read-Only)

6:00AM Reporting Snapshot 12:00PM Reporting Snapshot

6:00PM Reporting Snapshot

12:00AM Reporting Snapshot

Adventure Works DB translog

Database Snapshot

Database Snapshot

Database Snapshot

Database Snapshot

FIGURE 32.9 A point-in-time reporting database via a database snapshot

CHAPTER 32 Database Snapshots

SQL Server 2008

Principal

Server

If this server node becomes the mirror.

Adventure Works DB translog

SQL Server 2008

Witness Server MSDB DB

SQL Server 2008

Mirror Server

Adventure Works DB translog

Network

Rep orting Users

R ep

or tin

g U

se rs

Reporting Users

Database Snapshot Database Snapshot

FIGURE 32.10 Creating a database snapshot for reporting against a mirrored database to

offload the reporting impact on the principal server

because they are not competing with the transactional users for resources on the principal

server The only real issues arise when the principal server fails over to the mirror

data-base You now have both transactional and reporting users using the same database server

instance, and the performance of them all is affected

A possible solution to this situation would be to automatically (or manually) drop the

database snapshot on the mirror server if it becomes the principal and create a new

snap-shot on the old principal server if it is available (it is now the mirror) You then just point

all your reporting users to this new database snapshot This task can be handled fairly

easily in an application server layer This solution is basically a reciprocal principal/mirror

reporting configuration approach that always tries to get the database snapshot that is

used for reporting to be on the server that is the mirror server You would never really

want to have active database snapshots on both the principal server and mirror server at

the same time This is way too much overhead for both servers You want just the

data-base snapshots to be on the mirror server For a full explanation of all the capabilities of a

database mirroring configuration, refer to Chapter 20

Setup and Breakdown of a Database Snapshot

You might actually be surprised to find out how easily you can set up a database snapshot

This simplicity is partly due to the level at which database snapshots are created: at the

database level and not at the table level Setting up a database snapshot only entails

running a CREATE DATABASE with the AS SNAPSHOT OF statement You cannot create

data-base snapshots from SQL Server Management Studio or from any other GUI or wizard for

that matter All must be done using SQL scripts All SQL scripts for this chapter are

avail-able to you as a download from the Sams Publishing website for this book title (www

samspublishing.com) and on this book’s CD The script file, named

DBSnapshotSQL2008.sql, also contains a variety of other useful SQL statements to help

you better manage a database snapshot environment

Creating a Database Snapshot

One of the first things you must figure out before you create a database snapshot is

whether your source database data portion has more than one physical file in its

alloca-tion All these file references must be accounted for in the snapshot You execute the

system stored procedure sp_helpdb with the source database name as the parameter, as

shown here:

EXEC SP_HELPDB AdventureWorks

Go

The detailed file allocations of this database are as follows:

Name FileID File Name

AdventureWorks_Data 1 C:\Server\

MSSQL10.SQL08DE01\MSSQL\DATA\AdventureWorks_Data.mdf

AdventureWorks_Log 2 C:\Server\

MSSQL10.SQL08DE01\MSSQL\DATA\AdventureWorks_Log.ldf

You need to worry about only the data portion of the database for the snapshot:

CREATE DATABASE SNAP_AdventureWorks_6AM

ON

( NAME = AdventureWorks_Data,

FILENAME= ‘C:\Server\ MSSQL10.SQL08DE01\MSSQL\DATA\SNAP_AW_data_6AM.snap’

AS SNAPSHOT OF AdventureWorks

go

Creating the database snapshot is really that easy Now let’s walk through a simple

example showing how to create a series of four database snapshots against the

AdventureWorks source database that represent snapshots six hours apart (refer to

Figure 32.6) Here is the next snapshot to be run at 12:00 p.m.:

CREATE DATABASE SNAP_AdventureWorks_12PM

ON

( NAME = AdventureWorks_Data,

FILENAME= ‘C:\Server\ MSSQL10.SQL08DE01\MSSQL\DATA\SNAP_AW_data_12PM.snap’)

AS SNAPSHOT OF AdventureWorks

go

CHAPTER 32 Database Snapshots

These represent snapshots at equal time intervals and can be used for reporting or reverting

NOTE

We use a simple naming convention for the database names for snapshots and for

the snapshot files themselves The database snapshot name is the word SNAP,

followed by the source database name, followed by a qualifying description of what

this snapshot represents, all separated with underscores For example, a database

snapshot that represents a 6:00 a.m snapshot of the AdventureWorks database

would have this name:

”SNAP_AdventureWorks_6AM”

The snapshot file-naming convention is similar The name would start with the word

SNAP, followed by the database name that the snapshot is for (AdventureWorks, in our

example), followed by the data portion indication (for example, data, data1), a short

identification of what this snapshot represents (for example, 6AM), and then the

file-name extension snap to distinguish it from mdf and ldf files For example, the

snapshot filename for the preceding database snapshot would look like this:

”SNAP_AdventureWorks_data_6AM.snap”

We use the AdventureWorks database for this example AdventureWorks currently uses only

a single data file allocation for its data portion Here’s how you create the first snapshot,

to reflect a 6:00 a.m snapshot:

1 Create the snapshot on the source database AdventureWorks:

Use [master]

go

CREATE DATABASE SNAP_AdventureWorks_6AM

ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:\Program Files\

Microsoft SQL Server\ MSSQL10.SQL08DE01\MSSQL\DATA\

SNAP_AdventureWorks_data_6AM.snap’)

AS SNAPSHOT OF AdventureWorks

Go

2 Look at this newly created snapshot from the SQL Server instance point of view,

using a SQL query against the sys.databases system catalog, as follows:

Use [master]

go

SELECT name,

database_id,

source_database_id, — source DB of the snapshot

create_date,

snapshot_isolation_state_desc

FROM sys.databases

Go

This shows the existing source database and the newly created database snapshot:

name database_id source_database_id create_date snapshot_

isolation_state_desc

-AdventureWorks 7 NULL 2009-02-17 23:37:02.763

OFF SNAP_AdventureWorks_6AM 9 7 2009-12-05 06:18:36.597

ON

Note that source_database_id for the newly created database snapshot contains the

database ID of the source database Of course, you can also look at the database

snapshot properties by using SQL Server Management Studio, as shown in

Figure 32.11

3 Look at the newly created physical file for the sparse file (for the database snapshot)

by querying the sys.master_files system catalog:

SELECT database_id, file_id, name, physical_name

FROM sys.master_files

WHERE Name = ‘AdventureWorks_data’

FIGURE 32.11 Using SQL Server Management Studio to view the database snapshot

properties

CHAPTER 32 Database Snapshots

and is_sparse = 1

go

Note that we are focusing on only the sparse files for the newly created database

snap-shot (that is, the is_sparse = 1 qualification) This query results in the following:

database_id file_id name physical_name

- -

-9 1 AdventureWorks_Data C:\Prog \DATA\

SNAP_AdventureWorks_data_6AM.snap

4 To see the number of bytes that a snapshot sparse file is burning up, you can issue a

series of SQL statements against system catalog views/tables by using

fn_virtualfilestats and sys.master_files However, the following is a

quick-and-dirty stored procedure that should make this task much easier Just create this stored

procedure on your SQL Server instance (in the master database), and you can use it to

see the sizes of any database snapshot sparse file on your server (also available in the

downloadable SQL script file for this chapter):

CREATE PROCEDURE SNAP_SIZE_UNLEASHED2008

@DBDATA varchar(255) = NULL

AS

if @DBDATA is not null

BEGIN

SELECT B.name as ‘Sparse files for Database Name’,

A.DbId, A.FileId, BytesOnDisk FROM fn_virtualfilestats (NULL, NULL) A,

sys.master_files B WHERE A.DbID = B.database_id

and A.FileID = B.file_id

and B.is_sparse = 1

and B.name = @DBDATA

END

ELSE

BEGIN

SELECT B.name as ‘Sparse files for Database Name’,

A.DbId, A.FileId, BytesOnDisk FROM fn_virtualfilestats (NULL, NULL) A,

sys.master_files B WHERE A.DbID = B.database_id

and A.FileID = B.file_id

and B.is_sparse = 1

END

Go

When the SNAP_SIZE_UNLEASHED2008 stored procedure is created, you run it with or

without the name of the data portion of the database for which you have created a

snapshot If you do not supply the data portion name, you see all sparse files and

their sizes on the SQL Server instance The following example shows how to execute

this stored procedure to see the sparse file current size for the AdventureWorks_data

portion:

EXEC SNAP_SIZE_UNLEASHED2008 ‘AdventureWorks_Data’

Go

This results in the detail bytes that the sparse file is using on disk:

Sparse files for Database Name DbId FileId BytesOnDisk

-AdventureWorks_Data 9 1 196608

Currently, the sparse file is very small (196KB) because it was recently created Little

to no source data pages have changed, so it is basically empty right now It will start

growing as data is updated in the source database and data pages are copied to the

sparse file (by the copy-on-write mechanism) You can use the

SNAP_SIZE_UNLEASHED2008 stored procedure to keep an eye on the sparse file size

5 Believe it or not, the database snapshot is ready for you to use The following SQL

statement selects rows from this newly created database snapshot for a typical

point-in-time–based query against the CreditCard table:

Use [SNAP_AdventureWorks_6AM]

go

SELECT [CreditCardID]

,[CardType]

,[CardNumber]

,[ExpMonth]

,[ExpYear]

,[ModifiedDate]

FROM [SNAP_AdventureWorks_6AM].[Sales].[CreditCard]

WHERE CreditCardID = 1

go

This statement delivers the correct, point-in-time result rows from the database

snap-shot:

CreditCardID CardType CardNumber ExpMonth ExpYear

ModifiedDate

—————— —————————————————————————

-1 SuperiorCard 333326646953 -10 -1 20 -10

2009-12-03 00:00:39.560

You can take a look at how this all looks from SQL Server Management Studio Figure

32.12 shows the database snapshot database SNAP_AdventureWorks_6AM along with the

source database AdventureWorks It also shows the results of the system queries on these

database object properties

CHAPTER 32 Database Snapshots

FIGURE 32.12 SSMS snapshot properties, system query results, and snapshot isolation

state

You are now in the database snapshot business!

Breaking Down a Database Snapshot

If you want to get rid of a snapshot or overlay a current snapshot with a more up-to-date

snapshot, you simply use the DROP DATABASE command and then create it again The DROP

DATABASE command immediately removes the database snapshot entry and all sparse file

allocations associated with the snapshot It’s very simple indeed The following example

drops the database snapshot just created:

Use [master]

go

DROP DATABASE SNAP_AdventureWorks_6AM

go

If you’d like, you can also drop (delete) a database snapshot from SQL Server Management

Studio by right-clicking the database snapshot entry and choosing the Delete option

However, it’s best to do everything with scripts so that you can accurately reproduce the

same action over and over

Reverting to a Database Snapshot for Recovery

If you have a database snapshot defined for a source database, you can use that snapshot

to revert the source database to that snapshot’s point-in-time milestone In other words,

you consciously overlay a source database with the point-in-time representation of that

database (which you got when you created a snapshot) You must remember that you will

lose all data changes that occurred from that point-in-time moment and the current state

of the source database However, this may be exactly what you intend

Reverting a Source Database from a Database Snapshot

Reverting is just a logical term for using the DATABASE RESTORE command with the FROM

DATABASE_SNAPSHOT statement It effectively causes the point-in-time database snapshot to

become the source database Under the covers, much of this is managed from the system

catalog metadata level However, the results are that the source database will be in exactly

the same state as the database snapshot When you use a database snapshot as the basis of

a database restore, all other database snapshots that have the same source database must

first be dropped Again, to see what database snapshots may be defined for a particular

database, you can execute the following query:

Use [master]

go

SELECT name,

database_id,

source_database_id, — source DB of the snapshot

create_date,

snapshot_isolation_state_desc

FROM sys.databases

Go

This query shows the existing source database and the newly created database snapshot, as

follows:

name database_id source_database_id create_date snapshot_isolation_

state_desc

-AdventureWorks 7 NULL 2009-02-17 23:37:02.763

OFF SNAP_AdventureWorks_6AM 9 7 2009-12-05 06:01:36.597

ON SNAP_AdventureWorks_12PM 10 7 2009-12-05 12:00:36.227

ON

In this example, there are two snapshots against the AdventureWorks database The one you

don’t want to use when reverting must be dropped first Then you can proceed to restore

the source database with the remaining snapshot that you want These are the steps:

1 Drop the unwanted snapshot(s):

Use [master]

go

DROP DATABASE SNAP_AdventureWorks_12PM

go

2 Issue the RESTORE DATABASE command with the remaining snapshot:

USE [master]