SQL Server 2008 R2 : Database Snapshots - Limitations and Restrictions of Database Snapshots, Copy-on-Write Technology

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 set up database snapshots with this GUI or a wizard; it must all be done using T-SQL statements (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. 

As you can see in Figure 1, 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.

Figure 1. Using the copy-on-write technology with database snapshots.

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).