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]
go
RESTORE DATABASE AdventureWorks FROM DATABASE_SNAPSHOT =
'SNAP_AdventureWorks_6AM'
go
|
When
this process is complete, the source database and snapshot are
essentially the same point-in-time database. But the source database
quickly diverges, as updates begin to flow in again.
Using Database Snapshots with Testing and QA
Reverting to a “golden” copy of a database via a
database snapshot is going to be popular going forward because of the
simplicity that creating and reverting provides. Testing and QA groups
will thrive on this feature, and this will directly affect the velocity
of testing in your organization. With the increase in the frequency and
stability of your testing and QA environments, a direct improvement in
the quality of your application should be attainable. Essentially, these
are the steps:
1. | Create the golden database snapshot before you run your testing:
Use [master]
go
CREATE DATABASE SNAP_AdventureWorks_GOLDEN
ON ( NAME = AdventureWorks_Data, FILENAME= 'C:\Program Files\
Microsoft SQL Server\ MSSQL10.SQL08DE01\MSSQL\DATA\
SNAP_AdventureWorks_data_GOLDEN.snap')
AS SNAPSHOT OF AdventureWorks
Go
|
2. | Run tests or QA to your heart’s content.
|
3. | Revert
to the golden copy when the testing is completed so that the process
can be repeated again, regression testing can be run, stress testing can
be done, performance testing can be started, or further application
testing can be done:
USE [master]
go
RESTORE DATABASE AdventureWorks
FROM DATABASE_SNAPSHOT = 'SNAP_AdventureWorks_GOLDEN'
go
|
