ptg 1054 CHAPTER 32 Database Snapshots SQL Server 2008 Source Server BEFORE TEST Snapshot Testing Users Restore from the BEFORE snashot after testing cycle is complete and can continue with next test. Adventure Works DB Database Snapshot FIGURE 32.8 Establishing a baseline testing database snapshot before running tests and then reverting when finished. Providing a Testing (or Quality Assurance) Starting Point (Baseline) In testing and the QA phases of your development life cycle, you often need to conduct tests over and over. These are either logic tests or even performance tests. To aid testing and QA, database snapshots can be made of a test database prior to full testing (create a testing baseline database snapshot) and then the test database can be reverted back to its original state at a moment’s notice, using that baseline snapshot. This procedure can be done any number of times. Figure 32.8 shows how easy it is to simply create a testing reference point (or synchronization point) with a database snapshot. You then just run your test scripts or do any manual testing—as much as you want—and then revert back to this starting point rapidly. Then you run more tests again. Providing a Point-in-Time Reporting Database If what you really need is a true point-in-time reporting database from which you can run ad hoc or canned reports, often a database snapshot can serve this purpose much better than resorting to log shipping or data replication. Key to determining when you can use this database snapshot technique is whether the reporting load on this database server instance can easily support the reporting workload and whether the update transactions against this database are adversely affected by the database snapshot overhead of each Download from www.wowebook.com ptg 1055 When to Use Database Snapshots 32 transaction. Figure 32.9 shows the typical database snapshot configuration for one or more database snapshots that are to be used for reporting. Remember, this is a point-in-time snapshot of the source database. How frequently you need to create a new snapshot is dictated by your reporting requirements for data latency (how old the data can be in these reports). Providing a Highly Available and Offloaded Reporting Database from a Database Mirror If you are using database mirroring to improve your availability, you can also create a database snapshot against this mirrored database and expose the snapshot to your report- ing users. Even though the mirrored database cannot be used for any access whatsoever (it is in constant restore mode), SQL Server allows a snapshot to be created against it (as shown in Figure 32.10). This is a very powerful configuration in that a database snapshot against a mirror does not impact the load of the principal server—guaranteeing high performance against the principal server. Also, when the database snapshot is isolated over to the mirror server, the performance of the reporting users is also more predictable SQL Server 2008 Source Server Transactional Users Point-in-time Reporting Users (Read-Only) 6:00AM Reporting Snapshot 12:00PM Reporting Snapshot 6:00PM Reporting Snapshot 12:00AM Reporting Snapshot Adventure Works DB translog Database Snapshot Database Snapshot Database Snapshot Database Snapshot FIGURE 32.9 A point-in-time reporting database via a database snapshot. Download from www.wowebook.com ptg 1056 CHAPTER 32 Database Snapshots SQL Server 2008 Principal Server If this server node becomes the mirror. Adventure Works DB translog SQL Server 2008 Witness Server MSDB DB SQL Server 2008 Mirror Server Adventure Works DB translog Network Reporting Users Reporting Users Reporting Users Database SnapshotDatabase Snapshot FIGURE 32.10 Creating a database snapshot for reporting against a mirrored database to offload the reporting impact on the principal server. because they are not competing with the transactional users for resources on the principal server. The only real issues arise when the principal server fails over to the mirror data- base. You now have both transactional and reporting users using the same database server instance, and the performance of them all is affected. A possible solution to this situation would be to automatically (or manually) drop the database snapshot on the mirror server if it becomes the principal and create a new snap- shot on the old principal server if it is available (it is now the mirror). You then just point all your reporting users to this new database snapshot. This task can be handled fairly easily in an application server layer. This solution is basically a reciprocal principal/mirror reporting configuration approach that always tries to get the database snapshot that is used for reporting to be on the server that is the mirror server. You would never really want to have active database snapshots on both the principal server and mirror server at the same time. This is way too much overhead for both servers. You want just the data- base snapshots to be on the mirror server. For a full explanation of all the capabilities of a database mirroring configuration, refer to Chapter 20. Setup and Breakdown of a Database Snapshot You might actually be surprised to find out how easily you can set up a database snapshot. This simplicity is partly due to the level at which database snapshots are created: at the database level and not at the table level. Setting up a database snapshot only entails Download from www.wowebook.com ptg 1057 Setup and Breakdown of a Database Snapshot 32 running a CREATE DATABASE with the AS SNAPSHOT OF statement. You cannot create data- base snapshots from SQL Server Management Studio or from any other GUI or wizard for that matter. All must be done using SQL scripts. All SQL scripts for this chapter are avail- able to you as a download from the Sams Publishing website for this book title (www. samspublishing.com) and on this book’s CD. The script file, named DBSnapshotSQL2008.sql, also contains a variety of other useful SQL statements to help you better manage a database snapshot environment. Creating a Database Snapshot One of the first things you must figure out before you create a database snapshot is whether your source database data portion has more than one physical file in its alloca- tion. All these file references must be accounted for in the snapshot. You execute the system stored procedure sp_helpdb with the source database name as the parameter, as shown here: EXEC SP_HELPDB AdventureWorks Go The detailed file allocations of this database are as follows: Name FileID File Name AdventureWorks_Data 1 C:\Server\ MSSQL10.SQL08DE01\MSSQL\DATA\AdventureWorks_Data.mdf AdventureWorks_Log 2 C:\Server\ MSSQL10.SQL08DE01\MSSQL\DATA\AdventureWorks_Log.ldf You need to worry about only the data portion of the database for the snapshot: CREATE DATABASE SNAP_AdventureWorks_6AM ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:\Server\ MSSQL10.SQL08DE01\MSSQL\DATA\SNAP_AW_data_6AM.snap’ AS SNAPSHOT OF AdventureWorks go Creating the database snapshot is really that easy. Now let’s walk through a simple example showing how to create a series of four database snapshots against the AdventureWorks source database that represent snapshots six hours apart (refer to Figure 32.6). Here is the next snapshot to be run at 12:00 p.m.: CREATE DATABASE SNAP_AdventureWorks_12PM ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:\Server\ MSSQL10.SQL08DE01\MSSQL\DATA\SNAP_AW_data_12PM.snap’) AS SNAPSHOT OF AdventureWorks go Download from www.wowebook.com ptg 1058 CHAPTER 32 Database Snapshots These represent snapshots at equal time intervals and can be used for reporting or reverting. NOTE We use a simple naming convention for the database names for snapshots and for the snapshot files themselves. The database snapshot name is the word SNAP, followed by the source database name, followed by a qualifying description of what this snapshot represents, all separated with underscores. For example, a database snapshot that represents a 6:00 a.m. snapshot of the AdventureWorks database would have this name: ”SNAP_AdventureWorks_6AM” The snapshot file-naming convention is similar. The name would start with the word SNAP, followed by the database name that the snapshot is for (AdventureWorks, in our example), followed by the data portion indication (for example, data, data1), a short identification of what this snapshot represents (for example, 6AM), and then the file- name extension .snap to distinguish it from .mdf and .ldf files. For example, the snapshot filename for the preceding database snapshot would look like this: ”SNAP_AdventureWorks_data_6AM.snap” We use the AdventureWorks database for this example. AdventureWorks currently uses only a single data file allocation for its data portion. Here’s how you create the first snapshot, to reflect a 6:00 a.m. snapshot: 1. Create the snapshot on the source database AdventureWorks: Use [master] go CREATE DATABASE SNAP_AdventureWorks_6AM ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:\Program Files\ Microsoft SQL Server\ MSSQL10.SQL08DE01\MSSQL\DATA\ SNAP_AdventureWorks_data_6AM.snap’) AS SNAPSHOT OF AdventureWorks Go 2. Look at this newly created snapshot from the SQL Server instance point of view, using a SQL query against the sys.databases system catalog, as follows: Use [master] go SELECT name, database_id, source_database_id, — source DB of the snapshot create_date, snapshot_isolation_state_desc FROM sys.databases Go Download from www.wowebook.com ptg 1059 Setup and Breakdown of a Database Snapshot 32 This shows the existing source database and the newly created database snapshot: name database_id source_database_id create_date snapshot_ isolation_state_desc AdventureWorks 7 NULL 2009-02-17 23:37:02.763 OFF SNAP_AdventureWorks_6AM 9 7 2009-12-05 06:18:36.597 ON Note that source_database_id for the newly created database snapshot contains the database ID of the source database. Of course, you can also look at the database snapshot properties by using SQL Server Management Studio, as shown in Figure 32.11. 3. Look at the newly created physical file for the sparse file (for the database snapshot) by querying the sys.master_files system catalog: SELECT database_id, file_id, name, physical_name FROM sys.master_files WHERE Name = ‘AdventureWorks_data’ FIGURE 32.11 Using SQL Server Management Studio to view the database snapshot properties. Download from www.wowebook.com ptg 1060 CHAPTER 32 Database Snapshots and is_sparse = 1 go Note that we are focusing on only the sparse files for the newly created database snap- shot (that is, the is_sparse = 1 qualification). This query results in the following: database_id file_id name physical_name 9 1 AdventureWorks_Data C:\Prog \DATA\ SNAP_AdventureWorks_data_6AM.snap 4. To see the number of bytes that a snapshot sparse file is burning up, you can issue a series of SQL statements against system catalog views/tables by using fn_virtualfilestats and sys.master_files. However, the following is a quick-and- dirty stored procedure that should make this task much easier. Just create this stored procedure on your SQL Server instance (in the master database), and you can use it to see the sizes of any database snapshot sparse file on your server (also available in the downloadable SQL script file for this chapter): CREATE PROCEDURE SNAP_SIZE_UNLEASHED2008 @DBDATA varchar(255) = NULL AS if @DBDATA is not null BEGIN SELECT B.name as ‘Sparse files for Database Name’, A.DbId, A.FileId, BytesOnDisk FROM fn_virtualfilestats (NULL, NULL) A, sys.master_files B WHERE A.DbID = B.database_id and A.FileID = B.file_id and B.is_sparse = 1 and B.name = @DBDATA END ELSE BEGIN SELECT B.name as ‘Sparse files for Database Name’, A.DbId, A.FileId, BytesOnDisk FROM fn_virtualfilestats (NULL, NULL) A, sys.master_files B WHERE A.DbID = B.database_id and A.FileID = B.file_id and B.is_sparse = 1 END Go When the SNAP_SIZE_UNLEASHED2008 stored procedure is created, you run it with or without the name of the data portion of the database for which you have created a snapshot. If you do not supply the data portion name, you see all sparse files and Download from www.wowebook.com ptg 1061 Setup and Breakdown of a Database Snapshot 32 their sizes on the SQL Server instance. The following example shows how to execute this stored procedure to see the sparse file current size for the AdventureWorks_data portion: EXEC SNAP_SIZE_UNLEASHED2008 ‘AdventureWorks_Data’ Go This results in the detail bytes that the sparse file is using on disk: Sparse files for Database Name DbId FileId BytesOnDisk AdventureWorks_Data 9 1 196608 Currently, the sparse file is very small (196KB) because it was recently created. Little to no source data pages have changed, so it is basically empty right now. It will start growing as data is updated in the source database and data pages are copied to the sparse file (by the copy-on-write mechanism). You can use the SNAP_SIZE_UNLEASHED2008 stored procedure to keep an eye on the sparse file size. 5. Believe it or not, the database snapshot is ready for you to use. The following SQL statement selects rows from this newly created database snapshot for a typical point- in-time–based query against the CreditCard table: Use [SNAP_AdventureWorks_6AM] go SELECT [CreditCardID] ,[CardType] ,[CardNumber] ,[ExpMonth] ,[ExpYear] ,[ModifiedDate] FROM [SNAP_AdventureWorks_6AM].[Sales].[CreditCard] WHERE CreditCardID = 1 go This statement delivers the correct, point-in-time result rows from the database snap- shot: CreditCardID CardType CardNumber ExpMonth ExpYear ModifiedDate —————— ————————————————————————— 1 SuperiorCard 33332664695310 1 2010 2009-12-03 00:00:39.560 You can take a look at how this all looks from SQL Server Management Studio. Figure 32.12 shows the database snapshot database SNAP_AdventureWorks_6AM along with the source database AdventureWorks. It also shows the results of the system queries on these database object properties. Download from www.wowebook.com ptg 1062 CHAPTER 32 Database Snapshots FIGURE 32.12 SSMS snapshot properties, system query results, and snapshot isolation state. You are now in the database snapshot business! Breaking Down a Database Snapshot If you want to get rid of a snapshot or overlay a current snapshot with a more up-to-date snapshot, you simply use the DROP DATABASE command and then create it again. The DROP DATABASE command immediately removes the database snapshot entry and all sparse file allocations associated with the snapshot. It’s very simple indeed. The following example drops the database snapshot just created: Use [master] go DROP DATABASE SNAP_AdventureWorks_6AM go If you’d like, you can also drop (delete) a database snapshot from SQL Server Management Studio by right-clicking the database snapshot entry and choosing the Delete option. However, it’s best to do everything with scripts so that you can accurately reproduce the same action over and over. Reverting to a Database Snapshot for Recovery If you have a database snapshot defined for a source database, you can use that snapshot to revert the source database to that snapshot’s point-in-time milestone. In other words, you consciously overlay a source database with the point-in-time representation of that database (which you got when you created a snapshot). You must remember that you will lose all data changes that occurred from that point-in-time moment and the current state of the source database. However, this may be exactly what you intend. Download from www.wowebook.com ptg 1063 Reverting to a Database Snapshot for Recovery 32 Reverting a Source Database from a Database Snapshot Reverting is just a logical term for using the DATABASE RESTORE command with the FROM DATABASE_SNAPSHOT statement. It effectively causes the point-in-time database snapshot to become the source database. Under the covers, much of this is managed from the system catalog metadata level. However, the results are that the source database will be in exactly the same state as the database snapshot. When you use a database snapshot as the basis of a database restore, all other database snapshots that have the same source database must first be dropped. Again, to see what database snapshots may be defined for a particular database, you can execute the following query: Use [master] go SELECT name, database_id, source_database_id, — source DB of the snapshot create_date, snapshot_isolation_state_desc FROM sys.databases Go This query shows the existing source database and the newly created database snapshot, as follows: name database_id source_database_id create_date snapshot_isolation_ state_desc AdventureWorks 7 NULL 2009-02-17 23:37:02.763 OFF SNAP_AdventureWorks_6AM 9 7 2009-12-05 06:01:36.597 ON SNAP_AdventureWorks_12PM 10 7 2009-12-05 12:00:36.227 ON In this example, there are two snapshots against the AdventureWorks database. The one you don’t want to use when reverting must be dropped first. Then you can proceed to restore the source database with the remaining snapshot that you want. These are the steps: 1. Drop the unwanted snapshot(s): Use [master] go DROP DATABASE SNAP_AdventureWorks_12PM go 2. Issue the RESTORE DATABASE command with the remaining snapshot: USE [master] Download from www.wowebook.com . Database Snapshots SQL Server 2008 Principal Server If this server node becomes the mirror. Adventure Works DB translog SQL Server 2008 Witness Server MSDB DB SQL Server 2008 Mirror Server Adventure. FileID File Name AdventureWorks_Data 1 C: Server MSSQL10 .SQL0 8DE01MSSQLDATAAdventureWorks_Data.mdf AdventureWorks_Log 2 C: Server MSSQL10 .SQL0 8DE01MSSQLDATAAdventureWorks_Log.ldf You need. ‘C:Program Files Microsoft SQL Server MSSQL10 .SQL0 8DE01MSSQLDATA SNAP_AdventureWorks_data_6AM.snap’) AS SNAPSHOT OF AdventureWorks Go 2. Look at this newly created snapshot from the SQL Server instance