Database Snapshot

Database snapshot is a read-only view of a database. It is taken from the source database and resides on the same server as the database. A snapshot uses a sparse file to store original pages from the source database. A sparse file is empty when a snapshot is taken. Whenever a page is changed in the source database, the Database Engine copies the original page to the sparse file in the snapshot before updating the page in the source database. The same process is repeated whenever a page of the source database is changed. The snapshot is used to recover data by reapplying the pages from the snapshot to the source database. Database snapshot is not available if its source database is disconnected for any reason. Following is a list of advantages associated with snapshots: 1. They provide a convenient, read-only point-in-time copy of your data. 2. When you query a snapshot, you will not experience blocking due to update/insert operations that you might have to contend with when querying the source database (assuming snapshot isolation is not in use). 3. Initially the snapshot data files are small and are very quick to create. They should only become large if your database is subject to frequent modifications. Three of the commonly stated uses for snapshots which I find are not that advantageous:

Offload Reporting Protect against user/DBA error Maintain historical data

Offloading Reporting Below are what I consider the main advantages and disadvantages of using snapshots for offloading reporting: Advantages: 1. You have a read-only point-in-time copy of your data. 2. You will not be contending with blocking due to update/insert operations (let's assume snapshot isolation is not in use). 3. Initially the snapshot data files are small. Disadvantages: 1. You cannot grant a new user access to the data in a snapshot. 2. You can not backup the snapshots so if you have to restore your source database your reporting snapshots are lost.

Database Snapshot Article Code: ACE-08028

By Kishori Naik Page 1 of 8

3. Where data pages have not changed you will be accessing the source database file which may cause contention at the file level since both the source database and the snapshot will be accessing the same MDF. 4. Full text indexes are not available on snapshots so if you require full text searching for your reporting then snapshots are not an option. Additionally, you should bear in mind that snapshots have to be on the same server as the source database: you do not have a physical dedicated, reporting server. Therefore, physical resources on the database server, such as CPU and memory, still have to be shared. One other thing to note is that NTFS sparse files grow in 64kb increments and these increments are likely to occur at different times. As such, it's highly likely that a populated sparse file will not be contiguous at the NTFS level. The effect of this on reporting could lead to significant strain on your disks. Ultimately, the main thing that would stop me from using snapshots for report offloading is the likelihood of increased physical resource contention. Maintaining Historical Data Below are what I consider the advantages and disadvantages. Advantages: 1. Potentially, you can maintain a significant amount of history with little disk space usage. Disadvantage: 1. If the drive hosting the snapshot runs out of space causing an update to fail, the snapshot is marked suspect and can not be recovered. 2. Defragmenting your indexes negates the benefits associated with sparse files (if they are kept for a period of time). 3. Every update/insert transaction on the source server potentially bears the overhead of the page copy operation to maintain the snapshot(s). 4. You can not backup your snapshots. Although maintaining historical data is listed as a typical use I would never use snapshots for this simply because I can not back them up. Protecting from User or Administrator Error In theory, you could use a snapshot to restore a database to a point before a user or administrator error occurred simply by issuing: RESTORE DATABASE andrew_test from DATABASE_SNAPSHOT = andrew_test_snapshot_250206_1800'
Database Snapshot Article Code: ACE-08028 By Kishori Naik Page 2 of 8

Below are what I consider the advantages and disadvantages. Advantages: 1. The snapshot process is very quick. 2. The data and code is available immediately for restoration. Disadvantages: 1. The snapshot is at a point in time so is unlikely to be suitable for data recovery. 2. If you restore a snapshot you can't then restore any transaction logs so you potentially lose a large amount of data. 3. When you restore a snapshot all other snapshots of the database have to be deleted which would be a problem if you are maintaining reporting snapshots. 4. If your administrative error involved damage to a physical file (say a drive was accidentally wiped) the snapshot will not help you. To get any real value from snapshots in this area, you would have to take several snapshots throughout the day. I feel that the benefits of snapshots in this scenario will be far outweighed by the overhead of maintaining multiple snapshots, especially when considering other available options such as log shipping or even restoring from backup. It goes without saying (but here it is anyway) that snapshots should not be considered as part of or a replacement for a proper backup. To use them in this way would be disastrous when you consider their limitations, such as their dependency on the source database. Two scenarios where I do believe that snapshots can provide a real benefit for enterprise systems:

System upgrades Materializing data on standby servers

Performing System Upgrades The scenario that I consider a real winner for snapshots has to be when performing a system upgrade. Typically a system upgrade involves a release of code that changes the underlying schema and or data. It may also involve updating related application code. When performing such an upgrade the system administrator will ensure that full backups are taken of everything that will change as part of the upgrade, including the database. This process can be time consuming and requires additional space to store the backups, whilst the upgrade is in progress. By creating a snapshot, the database "backup" time is reduced to seconds and you only require the amount of space required might be very small, assuming only a small amount of data is changing. Once the system upgrade is complete, and after performing system checks, if you should you find yourself in the unfortunate position where you must restore to the point prior to the
Database Snapshot Article Code: ACE-08028 By Kishori Naik Page 3 of 8

upgrade the recovery is greatly speeded and simplified. To restore your database to the point prior to the upgrade you would issue the RESTORE T-SQL command shown previously. The restore time is likely to be less than a minute, depending on how much data changed, as opposed to potentially hours when restoring a large database. I have to point out though that there will still be some system upgrades where I would want a full backup prior to starting work. Upgrading the operating system is such an example but with most upgrades a snapshot will suffice. I will also state that I am assuming the last full backup and transaction logs up until the upgrade are available should the worst happen when using the snapshot approach. Materializing Data on your Standby Servers The other winner for me is using snapshots to "materialize" (make available for querying/reporting) data on your standby servers. Due to business requirements, or to avoid connections interfering with log shipping, you may have chosen to keep your log shipped database in NORECOVERY mode. This means you cannot read from the database. By creating a snapshot of your log shipped database, you can read the data and effectively use the standby server to offload reporting requirements. More importantly, this technique also works with mirrored databases and since a mirror destination can only ever be in NORECOVERY mode, it's an excellent way to access the mirrored data for the purpose of reporting. However there is always a trade off and the key point to keep in mind when using snapshots on a mirrored database is that, in synchronous mode, transactions have to commit on both servers before SQL can mark the transaction as complete. By introducing the snapshot we have introduced a third step before a transaction will commit. Why? Well below are the steps you now have to take if you have a snapshot: 1. Write transaction on server A source database. 2. Write transaction on server B destination database. 3. Copy page on server B destination database to server B snapshot. Without the snapshot you only have to do steps one and two. Of course, all this assumes that snapshots work smoothly and seamlessly with high availability solutions such as log shipping and database mirroring.

Database Snapshot Article Code: ACE-08028

By Kishori Naik Page 4 of 8

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 File groups 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 transitionally 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 transitionally 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.

How to Create a SQL Server 2005 Database Snapshot

Microsoft SQL Server administrators have a new feature with the SQL Server 2005 Edition which is database snapshots. Database snapshots are new with SQL Server 2005 and only available with Microsoft SQL Server 2005 Enterprise Edition. SQL Server database administration and development with SQL Server especially for sql reporting will be easier with ms sql server database snapshots. A database snapshot can be described as a photo of a database. Snapshots are read-only so we can easily say that their main usage areas cover mostly the reporting applications. Database snapshots are one to one the same of the original database at the time when the snapshot is created. After a snapshot is created it stays as a static view of the original database at the time of snapshot creation. A snapshot can persist until it is dropped. Also multiple snapshots can be created with different names of a database called as source database. In order to create a database snapshot, CREATE DATABASE statement is used. Here is a sample database snapshot create script of the sample database AdventureWorks

Database Snapshot Article Code: ACE-08028

By Kishori Naik Page 5 of 8

First, in order to place the data files of the snapshot, we should define the physical path of the container folder We can use the source database's data folder for the same purpose for snapshot database SELECT physical_name FROM sys.database_files WHERE file_id = 1 The above query will display where the .mdf file exists. So we can use the same folder. I'm going to use "D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\" Considering the below note from Books online; When you create a database snapshot, the CREATE DATABASE statement cannot reference log files, offline files, restoring files, and defunct files. I run the below select statement to get a list of data files that I should reference SELECT name FROM sys.database_files WHERE type_desc = 'ROWS' The returned row set only contains the "AdventureWorks_Data" Now, we are ready to create a snapshot of the source database. CREATE DATABASE AdventureWorks_SS ON ( NAME = AdventureWorks_Data, FILENAME = 'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorks_Data.ss' ) AS SNAPSHOT OF AdventureWorks After the above command is completed successfully, we can see the snapshot database in the Database Snapshots folder of the SQL Server Instance

Database Snapshot Article Code: ACE-08028

By Kishori Naik Page 6 of 8

In order to delete or remove a database snapshot after it is not needed any more, you can DROP it by using the DROP DATABASE command DROP DATABASE AdventureWorks_SS Note that if database snapshot creation fails, the snapshot is in suspect status and it should be deleted or dropped.

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 snapshots 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. 2. 3. 4. 5. 6. Snapshots are read only Snapshots of model, master and temp databases cannot be made Specifications of the database snapshots cannot be changed Files cannot be dropped from a snapshot. Snapshots cannot be backed up or restored. Snapshots cannot be attached or detached.
By Kishori Naik Page 7 of 8

Database Snapshot Article Code: ACE-08028

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 file groups 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 file groups 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 Snapshot Article Code: ACE-08028

By Kishori Naik Page 8 of 8