|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Monday, September 17, 2012 10:19 AM
Points: 71,
Visits: 49
|
|
It is not true that a snapshot consumes less disk space than a disk backup. It could actually consume more. The space taken by the snapshot database is EXACTLY the same as the original database data files, minus the log file. If the database has a lot of available space, then the backup will consume less.
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Monday, December 17, 2012 3:53 AM
Points: 135,
Visits: 77
|
|
Snapshot database and Snapshot backups are two things. Snapshot database is always <= Original database becasue it only contains the changed data. Snapshot backup is more complex subject not direclty relevant to the database snapshot.
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Monday, September 17, 2012 10:19 AM
Points: 71,
Visits: 49
|
|
A snapshot database is NOT <= Original. It will be = Original minus the log. See proof below. Commands in black, results in red. exec sp_helpdb UPSRC -- show size of original database (approx 301 GB) name db_size owner --------------- ------------- -------------------- UPSRC 301718.13 MB RAINBIRD\PSAdmin name fileid filename size --------------- ------ ----------------------------- ------------- rbprod_data 1 F:\mssql\data\UPSRC_Data.mdf 253744832 KB rbprod_log 2 F:\mssql\data\UPSRC_Log.ldf 55214528 KB CREATE DATABASE UPSRC_Snap ON (NAME = rbprod_data, FILENAME = 'f:\mssql\data\upsrc_snap.ss') AS SNAPSHOT OF UPSRC exec sp_helpdb UPSRC_Snap -- show size of snapshot database (approx 301GB) name db_size ------------- -------------- UPSRC_Snap 301718.13 MB name fileid filename size --------------- ------ ------------------------------ -------------- rbprod_data 1 F:\mssql\data\UPSRC_Data.mdf 253744832 KB rbprod_log 2 F:\mssql\data\UPSRC_Log.ldf 55214528 KB
dir f:\mssql\data (show size of database files on disk) 11/27/2006 07:13 PM 259,834,707,968 UPSRC_Data.mdf 11/27/2006 07:13 PM 56,539,676,672 UPSRC_Log.ldf 12/11/2006 04:12 PM 259,834,707,968 upsrc_snap.ss
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Monday, December 17, 2012 3:53 AM
Points: 135,
Visits: 77
|
|
sp_helpdb shows you the maximum size of the file not the size actually used by the data in the files. To find out the actual size of a sparse file
To learn the number of bytes each sparse file of the snapshot is currently using on disk, you can use the fn_virtualfilestats system table-valued function, which returns the current number of bytes in a file in the BytesOnDisk column. This function takes database_id and file_id as values. The database ID of the snapshot and the file IDs of each of its sparse files are displayed in the sys.master_files catalog view. For more information, see sys.master_files (Transact-SQL) and fn_virtualfilestats (Transact-SQL).
Alternatively, to see the disk space used by a sparse file, you can right-click the file in Microsoft Windows, click Properties, and look at the Size on disk value.
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Monday, September 17, 2012 10:19 AM
Points: 71,
Visits: 49
|
|
Bimal, Thanks for the clarification. I went so far as to examine the properties of the drive and found that after dropping the snapshot, that available space went up on the drive by exactly the amount shown in the "size on disk" property of the snapshot file. This was very helpful. I had abandoned use of the snapshot months ago when it looked like it was consuming the same space as the original. We had noticed the performance hit in our testing and together with the perceived hit on disk space gave up. Dang... I hate it when I am wrong. Dave
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Monday, September 17, 2012 10:19 AM
Points: 71,
Visits: 49
|
|
Bimal, Thanks for the clarification. I went so far as to examine the properties of the drive and found that after dropping the snapshot, that available space went up on the drive by exactly the amount shown in the "size on disk" property of the snapshot file. This was very helpful. I had abandoned use of the snapshot months ago when it looked like it was consuming the same space as the original. We had noticed the performance hit in our testing and together with the perceived hit on disk space gave up. Dang... I hate it when I am wrong. Dave
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Monday, March 09, 2009 1:35 PM
Points: 60,
Visits: 12
|
|
I am using database snapshots. It is one of the first features we made use of. I automate a job process to allow (certain trusted) users (processes) to request a snapshot. They would add a entry to a table in a database that they had access to - snapshot name, retention time (not to exceed 2 hours) , status. The job would run every 15 minutes checking the table. When a request came through a snapsot was created with the named request and the job then set the status to 'available'. They had a remote job check the table for a status change, do its queries, and then set the status to 'delete'. My job had a second step that looked for any 'delete' status and would delete those snapshots. If their process happen to fail before it could mark the snapshot status as 'delete' then the snapshot was deleted after exceeding the retention time. We used stored procedures to add entries to and make changes to the request table.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Monday, September 13, 2010 9:08 PM
Points: 1,
Visits: 41
|
|
Hi, Just wonder, is it possible to have snapshot on certain tables in a database instead of entire database?
Christopher.css
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Monday, September 14, 2009 7:57 AM
Points: 62,
Visits: 17
|
|
Christopher (11/26/2007) Hi, Just wonder, is it possible to have snapshot on certain tables in a database instead of entire database?
Christopher.css
Nope. A snapshot is created on database level. Could be a nice feature but I think this is done to preserve referential integrity. Otherwise it could get messy. ;)
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Thursday, March 07, 2013 5:45 PM
Points: 184,
Visits: 1,029
|
|
To alleviate some of the snapshot reads occurring on the source database, you can use mirroring to extend the architecture out.
ProdDB ----> MirrorDB ----> Snapshot.
By taking snapshots of the mirror database, you can help alleviate the load caused by DSS types of operations. I've done some proof of concept work with this setup and as long as the mirror db is on fairly fast spindles, it's difficult (but not impossible) to cause the production database a performance impact by large read operations on the snapshot (which in turn are reading from the source db).
This is one way I've found to make snapshots useful in production operations and not cause a performance impact when the snapshot read has to go back to the source database for the data - as most DSS operations against an OLTP system are likely to do.
Your friendly High-Tech Janitor... :)
|
|
|
|