Question

I have a system that needs to snapshot specific tables at certain points in time.

At present the process that takes the snapshot queries the data in the table, and puts the output into a Temp table (like a stage table not an in memory table).

Many of these processes can be running at the same time in parallel (100+ per hour). And the tables to be copied can run into GBs worth of data.

I am considering the use of database snapshots, so each process can take its own snapshot and work with it.

What are the pros and cons of this approach?

Is there a better way to approach this?

Answer 1

I would certainly consider using snapshots, but there are a couple of things you need to consider before you decide one way or the other:

• Snapshots use sparse files to store data, effectively only storing the changes to each table from the time of its creation. The more rows in your table that change, the smaller the disk saving over a simple replication.
• Snapshots happen to the entire database, rather than just one table. Therefore, if your DB is huge, and need 100+ copies of your DB per hour, that’s going to cost you a lot of disk space and performance. On the other hand, if you’re happy with one snapshot per hour for all your processes and the data doesn’t change too much, snapshots may be exactly what you need.
• Snapshots will have a performance overhead on your original DB, as the snapshots need to be kept up to date with what data has changed. If you’re already tight on performance, this may be an issue.

There are certainly some other things to consider, but that’s not a bad starting point. Books OnLine has a fairly detailed article regarding the use of Snapshots, which I would read before deciding. http://msdn.microsoft.com/en-us/library/ms175158%28v=SQL.90%29.aspx There’s also a section in there on limitations: http://msdn.microsoft.com/en-us/library/ms189940%28v=SQL.90%29.aspx

Hope this helps.