Microsoft SQL Server 2008 R2 Unleashed- P111 ppt

SQL Server 2008 Source AS SNAPSHOT OF AdventureWorks Transactional Users Point-in-time Reporting Users Read-Only ---Reverting---if needed---RESTORE DB AdventureWorks FROM DATABASE_SNAP

the primary transactional database, without any data loss impact whatsoever This is a

very powerful reporting and availability configuration

What’s New with Database Snapshots

With SQL Server 2005, everything about database snapshots was new because this was a

completely new feature for SQL Server With SQL Server 2008, there is little new to this

feature other than under-the-cover improvements to the copy-on-write mechanisms and

three more years of production implementations under their belt One hundred percent of

the SQL code you have set up for creating and managing snapshots will work perfectly

with SQL Server 2008 No upgrade pain here

Database snapshots have solved many companies’ reporting, data safeguarding, and

performance issues and directly contributed to higher availability across the board Be

aware, though, there are plenty of restrictions with doing database snapshots In fact,

these restrictions may prohibit you from using snapshots at all We talk about these

restrictions and when you can safely do database snapshots in a bit

NOTE

The examples in this chapter are based on the SQL Server 2005 version of the

AdventureWorks database rather than the newer AdventureWorks2008 or

AdventureWorks2008R2 sample databases used for many of the examples in the other

chapters in this book The reason for this is because of the examples presented that

create a snapshot from a Database Mirror Database Mirroring cannot be implemented

on a database that is also configured for FILESTREAM storage The 2008 and 2008R2

versions of the AdventureWorks database make use of FILESTREAM storage

Fortunately, the 2005 version of the AdventureWorks database can be installed using

the same installer that installs the AdventureWorks2008 or AdventureWorks2008R2

database If you didn’t install AdventureWorks when you installed either of these

sample databases, simply relaunch the installer and choose to install the

AdventureWorks OLTP database

For more information on downloading and installing the AdventureWorks sample

data-bases, see the Introduction chapter

What Are Database Snapshots?

Microsoft has kept up its commitment of providing a database engine foundation that can

be highly available 7 days a week, 365 days a year Database snapshots contribute to this

goal in several ways:

They decrease recovery time of a database because you can restore a troubled

data-base with a datadata-base snapshot—referred to as reverting.

They create a security blanket (safeguard) prior to running mass updates on a critical

database If something goes wrong with the update, the database can be reverted in

a very short amount of time

SQL Server 2008

Source

AS SNAPSHOT OF AdventureWorks

Transactional Users

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

-Reverting -if

needed -RESTORE DB AdventureWorks

FROM DATABASE_SNAPSHOT = ‘xyz’

Adventure Works DB translog

Database Snapshot

FIGURE 32.1 Basic database snapshot concept: a source database and its database

snap-shot, all on a single SQL Server instance

They provide a read-only, point-in-time reporting database for ad hoc or canned

reporting needs quickly (thus, increasing reporting environment availability)

They create a read-only, point-in-time reporting and off-loaded database for ad hoc

or canned reporting needs quickly from a database mirror (again, increasing

report-ing environment availability and also offloadreport-ing reportreport-ing impact away from your

production server/principal database server)

As a bonus, database snapshots can be used to create testing or QA synchronization

points to enhance and improve all aspects of critical testing (thus decreasing bad

code from going into production that directly affects the stability and availability of

that production implementation)

A database snapshot is simply a point-in-time full database view It’s not a copy—at least

not a full copy when it is originally created We talk about this more in a moment Figure

32.1 shows conceptually how a database snapshot can be created from a source database

on a single SQL Server instance

This point-in-time view of a database’s data never changes, even though the data (data

pages) in the primary database (the source of the database snapshot) may change It is

truly a snapshot at a point in time For a snapshot, it always simply points to data pages

that were present at the time the snapshot was created If a data page is updated in the

SQL Server 2008

SQL

Server

Empty Sparse file

of a Snapshot just created (no updates to original data pages have occurred yet)

Source Data Pages

Sparse File Pages

Source

Adventure

AdventureWorks DB

FIGURE 32.2 Source database data pages and the sparse file data pages that comprise the

database snapshot

source database, a copy of the original source data page is moved to a new page chain

termed the sparse file This utilizes copy-on-write technology Figure 32.2 shows the sparse

file that is created, alongside the source database itself

A database snapshot really uses the primary database’s data pages up until the point that

one of these data pages is updated (changed in any way) As already mentioned, if a data

page is updated in the source database, the original copy of the data page (which is

refer-enced by the database snapshot) is written to the sparse file page chain as part of an

update operation, using the copy-on-write technology It is this new data page in the

sparse file that still provides the correct point-in-time data to the database snapshot that it

serves Figure 32.3 illustrates that as more data changes (updates) occur in the source

data-base, the sparse file gets larger and larger with the old original data pages

Eventually a sparse file could contain the entire original database if all data pages in the

primary database were changed As you can also see in Figure 32.3, which data pages the

database snapshot uses from the original (source) database and which data pages are used

SQL Server 2008

SQL

Server

Copy of original pages for snapshot only when a page is changed (Copy-on-write)

Source Data Pages

Source

Adventure

AdventureWorks DB

System Catalog

of changed pages

Sparse File Pages

FIGURE 32.3 Data pages being copied to the sparse file for a database snapshot as pages

are being updated in the source database

from the sparse file are all managed by references in the system catalog for the database

snapshot This setup is incredibly efficient and represents a major breakthrough of

provid-ing data to others Because SQL Server is usprovid-ing the copy-on-write technology, a certain

amount of overhead is used during write operations This is one of the critical factors you

must sort through if you plan on using database snapshots Nothing is free The overhead

includes the copying of the original data page, the writing of this copied data page to the

sparse file, and then the subsequent metadata updating to the system catalog that

manages the database snapshot data page list Because of this sharing of data pages, it

should also be clear why database snapshots must be within the same instance of a SQL

Server: both the source database and snapshot start out as the same data pages and then

diverge as source data pages are updated In addition, when a database snapshot is created,

SQL Server rolls back any uncommitted transactions for that database snapshot; only the

committed transactions are part of a newly created database snapshot And, as you might

expect of something that shares data pages, database snapshots become unavailable if the

source database becomes unavailable (for example, if it is damaged or goes offline)

NOTE

You might plan to do a new snapshot after about 30% of the source database has

changed to keep overhead and file sizes in the sparse file at a minimum The most

fre-quent problem that occurs with database snapshots is related to sparse file sizes and

available space Remember, the sparse file has the potential of being as big as the

source database itself (if all data pages in the source database eventually get

updat-ed) Plan ahead for this situation!

There are, of course, alternatives to database snapshots, such as data replication, log

ship-ping, and even materialized views, but none are as easy to manage and use as database

snapshots

The most common terms associated with database snapshots are

database is a collection of data pages It is the fundamental data storage mechanism

that SQL Server uses

any one source database All snapshots must reside in the same SQL Server instance

origi-nal source database data pages when updates occur to the source database data

pages One sparse file is associated with each database data file If you have a source

database allocated with one or more separate data files, you have corresponding

sparse files of each of them

particular database snapshot that was done at a point in time, you are reverting You

are actually doing a database RESTORE operation with a FROM DATABASE_SNAPSHOT

statement

data-base, a copy of the source database data page is written to a sparse file so that the

database snapshot can be served correctly (that is, still see the data page as of the

snapshot point in time)

As Figure 32.4 illustrates, any data query using the database snapshot looks at both the

source database data pages and the sparse file data pages at the same time And these data

pages always reflect the unchanged data pages at the point in time the snapshot was

created

Limitations and Restrictions of Database Snapshots

Many restrictions or limitations are involved with using database snapshots in SQL Server

Some of them are pretty restrictive and may determine whether you can consider using

snapshots With the current release of SQL Server Management Studio, you cannot even

SQL Server 2008

SQL

Server

Source Data Pages

Source

Adventure

Works DB

Snapshot AdventureWorks DB

System Catalog

of changed pages

Sparse File Pages

Snapshot Users SELECT…data…

FROM AdventureWorks SNAPSHOT

FIGURE 32.4 A query using the database snapshot touches both source database data

pages and sparse file data pages to satisfy a query

set up database snapshots with this GUI or a wizard; it must all be done using T-SQL

state-ments (which is not that bad a deal) The following are some of the other restrictions:

You must drop all other database snapshots when using a database snapshot to

revert a source database

You lose visibility to the source database’s uncommitted transactions in the database

snapshot when it is created

The more updates to pages in the source database, the bigger your database snapshot

sparse files become

A database snapshot can be done only for an entire database, not for a subset of

the database

No additional changes can be made to a database snapshot It is read-only and can’t

even have additional indexes created for it to make reporting queries run faster

Additional overhead is incurred on update operations on the source database due to

the copy-on-write technique (not with SELECT statements)

If you’re using a database snapshot to revert (restore) a source database, neither

the snapshot nor source database is available

The source database cannot be dropped, detached, or restored until the database

snapshot is dropped first

Files on the source database or the snapshot cannot be dropped

For the database snapshot to be used, the source database must also be online

(unless the source database is a mirrored database)

The database snapshot must be on the same SQL Server instance as the source

database

Snapshots are read-only

Database snapshot files must be on NTFS only (not FAT 32 or RAW partitions)

Full-text indexing is not supported

If a source database ever goes into a RECOVERY_PENDING status, the database snapshot

also becomes unavailable

If a database snapshot ever runs out of disk space, it must be dropped; it is actually

marked as SUSPECT

This may seem like a lot of restrictions—and it is But look to Microsoft to address many

of these restrictions in future releases These current restrictions may disqualify many folks

from getting into the database snapshot business Others will thrive in its use out of the

box

Copy-on-Write Technology

The copy-on-write technology that Microsoft first introduced with SQL Server 2005 is at

the core of both database mirroring and database snapshot capabilities How it is used in

database mirroring is explained in Chapter 20 In this section, we walk through a typical

transactional user’s update of data in a source database

As you can see in Figure 32.5, an update transaction is initiated against the

AdventureWorks database (labeled A) As the data is being updated in the source database’s

data page and the change is written to the transaction log (labeled B), the copy-on-write

technology also copies the original source database data page in its unchanged state to the

sparse data file (also labeled B) and updates the metadata page references in the system

catalog (also labeled B) with this movement

The original source data page is still available to the database snapshot This adds extra

overhead to any transaction that updates, inserts, or deletes data from the source database

After the copy-on-write technology finishes its write on the sparse file, the original

update transaction is properly committed, and acknowledgment is sent back to the user

(labeled C)

SQL Server 2008

SQL

Server

Data Pages

Snapshot Users Transactional

Users

Source

System Catalog

of changed pages

Sparse File Pages

Copy of original pages for snapshot only when a page

is changed (Copy-on-write)

B B

A C

B

Adventure Works DB translog B

Snapshot AdventureWorks DB

FIGURE 32.5 Using the copy-on-write technology with database snapshots

NOTE

Database snapshots cannot be used for any of SQL Server’s internal databases—

tempdb, master, msdb, or model Also, database snapshots are supported only in the

Enterprise Edition of SQL Server 2008

When to Use Database Snapshots

As mentioned previously, there are a few basic ways you can use database snapshots

effec-tively Each use is for a particular purpose, and each has its own benefits After you have

factored in the limitations and restrictions mentioned earlier, you can consider these uses

Let’s look at each of them separately

SQL Server 2008

Source

set xyz = … FROM AWSnapshot6:00AM.tableX

All Users

Restore from

Any Point-in-time

Snapshot if needed

6:00AM Snapshot

12:00PM Snapshot

6:00PM Snapshot

12:00AM Snapshot

Adventure Works DB translog

Database Snapshot

Database Snapshot

Database Snapshot

Database Snapshot

FIGURE 32.6 Basic database snapshot configuration: a source database and one or more

database snapshots at different time intervals

Reverting to a Snapshot for Recovery Purposes

Probably the most basic usage of database snapshots is decreasing recovery time of a

data-base by restoring a troubled datadata-base with a datadata-base snapshot—referred to as reverting As

Figure 32.6 shows, one or more regularly scheduled snapshots can be generated during a

24-hour period, effectively providing you with data recovery milestones that can be

rapidly used As you can see in this example, four database snapshots are six hours apart

(6:00 a.m., 12:00 p.m., 6:00 p.m., and 12:00 a.m.) Each is dropped and re-created once

per day, using the same snapshot name Any one of these snapshots can be used to

recover the source database rapidly in the event of a logical data error (such as rows

deleted or a table being dropped) This technique is not supposed to take the place of a

good maintenance plan that includes full database backups and incremental transaction

log dumps However, it can be extremely fast to get a database back to a particular

milestone

To revert to a particular snapshot interval, you simply use the RESTORE DATABASE

command with the FROM DATABASE_SNAPSHOT statement This is a complete database

restore; you cannot limit it to just a single database object In addition, you must drop all

other database snapshots before you can use one of them to restore a database

As you can also see in Figure 32.6, a targeted SQL statement variation from a complete

database restore from a snapshot could be used instead if you knew exactly what you

wanted to restore at the table and row level You could simply use SQL statements (such as

an UPDATE SQL statement or an INSERT SQL statement) from one of the snapshots to

selec-tively apply only the fixes you are sure need to be recovered (reverted) In other words,

you don’t restore the whole database from the snapshot, you only use some of the

snap-shots’ data with SQL statements and bring the messed-up data row values back in line

with the original values in the snapshot This is at the row and column level and usually

requires quite a bit of detailed analysis before it can be applied to a production database

It is also possible to use a snapshot to recover a table that someone accidentally dropped

There is a little data loss since the last snapshot, but it is a simple INSERT INTO statement

from the latest snapshot before the table drop So be careful here, but consider the value

as well

Safeguarding a Database Prior to Making Mass Changes

Often, you plan regular events against your database tables that result in some type of mass

update being applied to big portions of the database If you do a quick database snapshot

before any of these types of changes, you are essentially creating a nice safety net for rapid

recovery in the event you are not satisfied with the mass update results Figure 32.7

illus-trates this type of safeguarding technique

If you are not satisfied with the entire update operation, you can use RESTORE DATABASE

from the snapshot and revert it to this point Or, if you are happy with some updates but

not others, you can use the SQL statement UPDATE to selectively update (restore) particular

values back to their original values using the snapshot

SQL Server 2008

Source

set xyz = … FROM AWSafeguard6:00AM.tableX SAFEGUARD Snapshot (Before the mass changes)

All Users Generating

Mass Changes

Restore from snapshot

(if changes are not correct)

Adventure Works DB

Database Snapshot

FIGURE 32.7 Creating a before database snapshot prior to scheduled mass updates to a

database