Microsoft SQL Server 2008 R2 Unleashed- P112 ppsx

ptg
1054
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
Download from www.wowebook.com
ptg
1055
When to Use Database Snapshots
32
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.
Download from www.wowebook.com
ptg
1056
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
Reporting Users
Reporting Users
Reporting Users
Database SnapshotDatabase 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

Download from www.wowebook.com
ptg
1057
Setup and Breakdown of a Database Snapshot
32
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
Download from www.wowebook.com
ptg
1058
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
Download from www.wowebook.com
ptg
1059
Setup and Breakdown of a Database Snapshot

32
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.
Download from www.wowebook.com
ptg
1060
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
Download from www.wowebook.com
ptg
1061
Setup and Breakdown of a Database Snapshot
32
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 33332664695310 1 2010
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.
Download from www.wowebook.com
ptg
1062
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.
Download from www.wowebook.com
ptg
1063
Reverting to a Database Snapshot for Recovery
32
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]
Download from www.wowebook.com