SQL Server 2005 - Using Database Snapshots

SQL Server 2005 - Using Database Snapshots

In this tutorial you will learn about Using Database Snapshots in SQL Server 2005, Effect of the Update Pattern on Database Snapshot Growth, Metadata About Database Snapshots, Limitations on the Source Database, Limitations on Database Snapshots, Database Snapshots with Offline Filegroups and Best Practices for Creating Database Snapshots.

Snapshots are read only static views of the database. This is a new feature introduced into SQL Server 2005 Enterprise edition to enable DBAs report on the database or revert to the source database if required so that data loss is confined to the point at which the snapshot was created. A database snapshot can exist in the same server as the database and each snapshot is transactionally consistent with the source database at the point of its creation. When a snapshot is created, the source database is likely to have some transactions which are open and as yet uncommitted. These transactions are rolled back in the snapshot to make it transactionally consistent.

The snapshot also persists till it is specifically dropped by the DBA. The database snapshot is not related to snapshot backups, snapshot isolation of transactions or snapshot replication.

Snapshots operate at a data-page level and the original page is copied from the source database using the copy-on-write operation. Updates to the database subsequently made do not modify the snapshot. These pages are stored in sparse files (an NTFS feature) which are empty files that contain no user data and do not have disk space for user data allocated to it as yet. However, sparse files can grow in size and occupy disk space as the snapshots get stored into it.

Effect of the Update Pattern on Database Snapshot Growth

Enterprises which have large databases should replace the old snapshot with a new snapshot at regular predetermined intervals. The ideal interval will have to be decided by the DBA on the basis of the growth rate of the snapshot and the disk space available in the sparse file. If the disk drive fills up the write operations to all snapshots will fail. Therefore, the DBA should study the typical update patterns for the database and plan the amount of space required and also plan for the lifespan of the snapshot.

Metadata About Database Snapshots

The metadata relating to database snapshots is stored in the sys.databases catalog view. The snapshot does not expose metadata on its own, but exposes the metadata from the source database. The syntax for viewing the metadata is as under:

USE < database_snapshot > SELECT * FROM sys.database_files

However, when the source database uses full text search or database mirroring, it disables itself in a snapshot and alters some values in the snapshot’s database.

Limitations on the Source Database

The source database cannot be dropped, detached or restored so long as the database snapshot exists. Database performance also is drastically reduced due to I/O operations to the snapshot every time a page is updated.

Limitations on Database Snapshots

A database snapshot must be created on the same server as the source database. The snapshot captures the data at a point in time and does not commit any uncommitted transactions that may be in the pipeline at that time. If a page being updated on the source database is pushed to a snapshot, the snapshot runs out of disk space, the snapshot is likely to be corrupted and hence to be deleted. The other limitations of a snapshot are:

1. Snapshots are read only
2. Snapshots of model, master and temp databases cannot be made
3. Specifications of the database snapshots cannot be changed
4. Files cannot be dropped from a snapshot.
5. Snapshots cannot be backed up or restored.
6. Snapshots cannot be attached or detached.
7. Snapshots of FAT32 file system or RAW partitions cannot be created.
8. Snapshots do not support full text indexing
9. The snapshot inherits the security constraints of the source database at the point of its creation.
10. The state of filegroups at the point of creation alone is reflected in the snapshot.
11. When the source database becomes RECOVERY_PENDING, the database snapshots become inaccessible till the source is recovered.
12. Read only filegroups and compressed file groups do not support reverting.
13. Disk Space Requirements

Snapshots are space efficient as it requires only space for storage of pages that change during its lifetime. Since they are also kept only for a limited period of time size is not a major problem. It must be remembered that if a database snapshot runs out of disk space, the snapshot will have to be deleted.

Database Snapshots with Offline Filegroups

Snapshots are affected by offline filegroups in the source database when an attempt is made to create a snapshot. Though the snapshot is created Sparse files are not created for offline filegroups. The existing database snapshot is not impacted even when an online filegroup is brought online. A filegroup remains online in database snapshots (even if taken offline) if it was online at the time of creation. However, queries using the snapshot are likely to fail if it was taken offline. The reverting of the source database to the snapshot requires that all the filegroups which were online at the time of creation are online.

Best Practices for Creating Database Snapshots

1. Naming Database Snapshots should be well designed and thought of. The name of the snapshot must incorporate information identifying the source database, the creation date and time and sequence number or such other information as would be useful to the administrator.

2. Limiting the Number of Database Snapshots is advisable, as snapshots persist till they are specifically dropped.

3. Client Connections to a Database Snapshot must be able to locate the snapshot. Users can connect to the snapshot using the SQL server Management Studio or though a programmatic solution that directs report writing clients to the latest snapshot.