Esoteric : SQL Architecture

Some notes on database snapshots

arvindsh — Wed, 31 Dec 2008 10:29:35 GMT

Overview

I recently conducted some tests to double check the exact behavior of database snapshots when:

Snapshots are created on volumes which are much smaller than the actual database size
Metadata-only operations such as DROP TABLE are executed
DDL operations execute on the main database and the snapshot runs out of disk space

Here is my testing methodology and the customary summary of observations.

Scenario

Drive C: contains the original data file for database TestSS. Data file size = 1.95GB
TestSS.dbo.T1 is a table which contains 1GB of data
TestSS_1 is a snapshot which was created on TestSS after the 1GB data insert was completed.

Test Case A: Can we create a snapshot on volume smaller than the database size?

The snapshot TestSS_1 was created on volume T: which is 10MB in size.
Size on disk for snapshot at creation = 192KB
The snapshot creation succeeded without any errors.

If you are curious as to what I mean by 'size on disk', please refer to this snapshot:

It is a property of the NTFS sparse file that the actual space occupied on disk is much lesser initially than the 'Size' which is displayed for that file in Explorer.

Test Case B: Metadata-only operations and snapshot files

Next, I executed a DROP TABLE T1 on TestSS, which returned immediately without any errors. At this time the snapshot did not have a large ‘on disk size’ – just 1.48MB
At this time the data is accessible through the snapshot just fine. If you do a select count(1) from testSS..T1 it fails (as expected). So the main operation (DROP TABLE) worked just fine.

How is this possible? It turns out that certain operations such as TRUNCATE TABLE, DROP TABLE etc. directly operate on the IAM chain and possibly other internal allocation pages to efficiently 'clean up' data and metadata. In such cases the copy-on-write to the snapshot is deferred till such time that the actual data page and extent are touched.

Test Case 3: What effect does failure to write to the snapshot have on the main database?

Next, I reverted the database TestSS to the snapshot TestSS_1 and then dropped the TestSS_1 snapshot. How do you revert a database to a snapshot? You use the RESTORE DATABASE ... command like this: RESTORE DATABASE TestSS FROM DATABASE_SNAPSHOT = TestSS_1
I recreated TestSS_1 immediately using the CREATE DATABASE ... AS SNAPSHOT ...
Next, I executed DELETE T1 to force a logged data operation and it executed for some time before finally returning these errors:

Msg 5128, Level 17, State 2, Line 1
Write to sparse file 't:\Data\testss_1.ss' failed due to lack of disk space.
Msg 5128, Level 17, State 2, Line 1
Write to sparse file 't:\Data\testss_1.ss' failed due to lack of disk space.
Msg 5128, Level 17, State 2, Line 1
Write to sparse file 't:\Data\testss_1.ss' failed due to lack of disk space.

Though, interestingly the main DELETE did not fail; all rows from the table T1 have been deleted. It is by-design that any failures to write to the snapshot are not going to affect the primary operation on the database.

Summary

So in conclusion this is what we can learn from the above. Most of it is logical when you think about it, but it is better to be sure than to guess!

Database snapshots can most definitely be created on volumes which are much smaller than the original database size
Metadata only operations initially do not affect the snapshot. Only when the underlying pages are really 'cleaned up' by subsequent system processes, will the copy of the affected pages be moved into the database snapshot's sparse file
Failures to write to the snapshot will never affect the original database on which the DDL is being executed

Additional Reading

Please also refer to the excellent white paper on Database Snapshots Performance Considerations Under IO Intensive Workloads for some more information on snapshots and their effect on performance.
Paul Randal's blogs about snapshots.
Good information on snapshot internals is at the SQL CAT Team website.

Resources from TechEd sessions

arvindsh — Thu, 15 Jun 2006 06:20:00 GMT

Several attendees have asked for the resources section from our presentations at TechEd India. Enjoy!

Blogs
SQLCAT: http://blogs.msdn.com/sqlcat
WINCAT: http://blogs.msdn.com/wincat
Slava Oks’ blog: http://blogs.msdn.com/slavao

Product Feedback
http://lab.msdn.microsoft.com/productfeedback/

External Links:
NUMA FAQ: http://lse.sourceforge.net/numa/faq

Books:
Inside Microsoft SQL Server 2005: Query Processing and Optimization (Volume 3)
The Guru's Guide to SQL Server Architecture and Internals (SQL Server 2000)

SQL Server 2005 – Operations
http://www.microsoft.com/technet/prodtechnol/sql/2005/library/operations.mspx

Whitepapers
Troubleshooting Performance Problems in SQL Server 2005 (http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx)
Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005(http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
Statistics Used by the Query Optimizer in SQL Server 2005 (http://www.microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx)
SQL Server 2000 I/O Basics (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx)

Webcasts
Troubleshooting Performance Problems In SQL Server 2005 (http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032275646&EventCategory=5&culture=en-US&CountryCode=US)
Performance Diagnosis in SQL Server 2005 (http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032275586&EventCategory=5&culture=en-US&CountryCode=US)
Supportability features for SQL Server 2005
(http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032275593&EventCategory=5&culture=en-US&CountryCode=US)

PASS 2005 PSS Service Center Labs
http://www.microsoft.com/downloads/details.aspx?FamilyID=9b8098a7-e75f-462a-b296-e80199c9f323&displaylang=en

Database Snapshots

arvindsh — Wed, 07 Jun 2006 07:18:00 GMT

DB Snapshots are a very useful new feature in SQL Server 2005 Enterprise Edition. They provide us the ability to preserve a consistent picture of the database as it was at a point in time. Both metadata and data are captured in the snapshot.

The main uses of snapshots are for preserving views of the database for reporting purposes, and also to easily recover data affected by user error. Snapshots also provide a means to view the data in the mirror database.

DB Snapshots use "sparse files", which means that the actual snapshot size on disk will be very small initially and would only grow by recording the the changes to the database using a copy-on-write scheme.

Another cool feature of snapshots for recovering from administrative or user error is the ability to revert a database back to a snapshot. This is potentially much quicker than restoring a full backup, as we only copy the changed pages from the snapshot back into the data files. But there are other implications of reverting to a snapshot - most important being the fact that we rebuild the log in such cases. To ensure recoverability of all transactions committed after the snapshot was taken, be sure to backup the log prior to using this feature.