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.
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).
Note
Database snapshots cannot be used for any of SQL Server’s internal databases—tempdb, master, msdb, or model. Also, database snapshots are supported only in the Enterprise Edition of SQL Server 2008.