Database Snapshot

Some of my typical uses for Database Snapshots include:

• Supporting small data changes in Production by providing a hot restore option. (No need to take a database backup when a Snapshot can be used to store just the delta of changed data.)
• In conjunction with Database Mirroring, can be used to provide read access to the Mirrored database data.(Useful in typical query/reporting offloading scenarios but not as flexible as a Replicated DB, which permits local optimisations such as workload specific indexes).

I use database snapshots in development, when testing ideas or performing restructuring-by-brainstorming. I start off making a snapshot, go wild and crazy in a development database, and then use the snapshot to go back to the original state when I'm finished playing/testing ideas. That way, I don't need to take a copy of a database just to go bananas with it.

A database snapshot is initially an empty sparse file. It's an allocation of disk space, but the file itself is empty. As the original datafile changes, Windows will fill the sparse-file with the original data. So if you create a snapshot, and then change or delete a datapage, Windows will first write the original datapage to the sparse-file, and then change/delete the datapage.

The way it's implemented, creating a database snapshot is very, very quick, as Windows won't really copy data, it will just create some meta-data about the data. Restoring/reverting from a snapshot is also a quick process (if only little data has been changes since creating the snapshot), since only the changed pages are restored.

Some reading on database snapshots in SQL Server 2005: http://msdn.microsoft.com/en-us/library/ms175158(v=SQL.90).aspx