Microsoft SQL Server 2008 R2 Unleashed- P113 doc

ptg 1064 CHAPTER 32 Database Snapshots go RESTORE DATABASE AdventureWorks FROM DATABASE_SNAPSHOT = ‘SNAP_AdventureWorks_6AM’ go When this process is complete, the source database and snapshot are essentially the same point-in-time database. But the source database quickly diverges, as updates begin to flow in again. Using Database Snapshots with Testing and QA Reverting to a “golden” copy of a database via a database snapshot is going to be popular going forward because of the simplicity that creating and reverting provides. Testing and QA groups will thrive on this feature, and this will directly affect the velocity of testing in your organization. With the increase in the frequency and stability of your testing and QA environments, a direct improvement in the quality of your application should be attainable. Essentially, these are the steps: 1. Create the golden database snapshot before you run your testing: Use [master] go CREATE DATABASE SNAP_AdventureWorks_GOLDEN ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:\Program Files\ Microsoft SQL Server\ MSSQL10.SQL08DE01\MSSQL\DATA\ SNAP_AdventureWorks_data_GOLDEN.snap’) AS SNAPSHOT OF AdventureWorks Go 2. Run tests or QA to your heart’s content. 3. Revert to the golden copy when the testing is completed so that the process can be repeated again, regression testing can be run, stress testing can be done, performance testing can be started, or further application testing can be done: USE [master] go RESTORE DATABASE AdventureWorks FROM DATABASE_SNAPSHOT = ‘SNAP_AdventureWorks_GOLDEN’ go Setting Up Snapshots Against 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. Doing so further enhances the overall database availability to all end users Download from www.wowebook.com ptg 1065 Setting Up Snapshots Against a Database Mirror 32 (transactional and reporting users). In addition, it serves to isolate the reporting users from the transactional users. The reporting users are connected to the mirror server’s version of the database (via a database snapshot of the mirrored database), and their reporting queries do not impact the principal server in any way. Remember that the mirrored data- base is not usable for any access whatsoever (it is in constant restore mode). SQL Server allows a snapshot to be created against it (refer to Figure 32.10). As mentioned previously, the only real issues arise when the principal server fails over to the mirror database. When the mirror server takes over for the principal, the database snapshot terminates its report- ing user connections. The reporting users only need to reconnect to pick up where they left off. However, you now have both transactional and reporting users using the same database server instance, and performance of 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 process can be handled fairly easily in an application server layer. This 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. Reciprocal Principal/Mirror Reporting Configuration The following steps outline the method to create the snapshot on the mirror, drop it when the mirror becomes the principal, and create a new snapshot against the old princi- pal (now the mirror): 1. Create the database snapshot on a mirrored database server for reporting on the mirror server (REM12374333\SQL08DE02): Use [master] go CREATE DATABASE SNAP_AdventureWorks_REPORTING ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:\Program Files\ Microsoft SQL Server\MSSQL10.SQL08DE02\MSSQL\DATA\ SNAP_AdventureWorks_data_REPORTING.snap’) AS SNAPSHOT OF AdventureWorks Go As you can see in Figure 32.13, this would be the live configuration of the principal server (REM12374333\SQL08DE01), the mirror server (REM12374333\SQL08DE02), and the reporting database snapshot (SNAP_AdventureWorks_REPORTING), as shown from SQL Server Management Studio. Download from www.wowebook.com ptg 1066 CHAPTER 32 Database Snapshots FIGURE 32.13 SQL Server Management Studio, showing database mirroring with a database snapshot for reporting configuration. If the principal fails over to the mirror, you would drop the database snapshot that is currently created off that database and create a new one on the old principal (now the mirror), as shown in the following steps. 2. Drop the reporting database snapshot on the new principal server (the principal is now REM12374333\SQL08DE02): Use [master] go DROP DATABASE SNAP_AdventureWorks_REPORTING go 3. Create the new reporting database snapshot on the new mirrored database server (the mirror is now REM12374333\SQL08DE01): Use [master] go CREATE DATABASE SNAP_AdventureWorks_REPORTING ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:\Program Files\ Microsoft SQL Server\ MSSQL10.SQL08DE01\MSSQL\DATA\ SNAP_AdventureWorks_data_REPORTING.snap’) AS SNAPSHOT OF AdventureWorks Go That’s it. You now have your reporting users completely isolated away from your principal server (and the transactional users) again. Life can return to normal very quickly. Download from www.wowebook.com ptg 1067 Database Snapshots Maintenance and Security Considerations 32 Database Snapshots Maintenance and Security Considerations With regard to database snapshots, several things need to be highly managed: snapshot sparse file size management, data latency management that corresponds to your users’ needs, the location of the sparse files within your physical deployment, the sheer number of database snapshots you are willing to support against a single database instance, and the security and access needs of users of database snapshots. Security for Database Snapshots By default, you get the security roles and definitions that you have created in the source database available to you within the database snapshot except for roles or individual permissions that you have in the source database used for updating data or objects. This is referred to as “inherited from the source database.” These updating rights are not available to you in a database snapshot. A database snapshot is a read-only database! If you have specialized roles or restrictions you want to be present in the database snapshot, you need to define them in the source database, and you get them instantly. You manage from a single place, and everyone is happy. Snapshot Sparse File Size Management Sparse file size is probably the most critical aspect to deal with when managing database snapshots. It is imperative that you keep a close watch on the growing size of any (and all) database snapshot sparse files you create. If your snapshot runs out of space because you didn’t manage file size well, it becomes suspect and is not available to use. The only path out of this scenario is to drop the snapshot and re-create it. Following are some issues to consider for sparse files: . Monitor sparse files regularly. Make use of stored procedures such as the SNAP_SIZE_UNLEASHED2008 stored procedure to help with this situation. . Pay close attention to the volatility of the source database. This rate of change directly translates to the size of the sparse file and how fast it grows. The rule of thumb is to match your drop and re-create of a database snapshot frequency to when the sparse file is at around 30% of the size of the source database. Your data latency user requirements may demand a faster rate of drop/re-create. . Isolate sparse files away from the source database data files. You do not want to com- pete with disk arm movement in any way. Always work to get disk I/O as parallel as possible. Number of Database Snapshots per Source Database In general, you shouldn’t have too many database snapshots defined on a database because of the copy-on-write overhead each snapshot requires. However, this all depends on the volatility of the source database and a server’s capacity. If there is low volatility and Download from www.wowebook.com ptg 1068 CHAPTER 32 Database Snapshots the server is not using much CPU, memory, and disk capacity, this database could more readily support many separate database snapshots at once. If the volatility is high and CPU, memory, and perhaps disk capacity are saturated, you should minimize drastically the number of database snapshots. Summary Database snapshots can be thought of as an enabling capability with many purposes. They are great for fulfilling point-in-time reporting requirements easily, reverting a database to a point in time (recoverability and availability), insulating a database from issues that may arise during mass updates, and potentially reducing the processing impact of querying against the primary transactional databases (via database mirroring and database snap- shots). You must remember that database snapshots are point in time and read-only. The only way to update a snapshot is to drop it and re-create it. Data latency of this point-in- time snapshot capability must always be made very clear to any of its users. Database snapshots are snapshots of the entire database, not a subset. This clearly makes data snapshots very different from alternative data access capabilities such as data replica- tion and materialized views. This feature has been made possible via a major breakthrough from Microsoft called copy-on-write technology. This is certainly an exciting extension to SQL Server but is not to be used as a substitute for good old database backups and restores. This is one capability that we recommend you consider using as soon as possible. Chapter 33, “Database Maintenance,” provides a detailed explanation of the best practices surrounding maintaining a database. Download from www.wowebook.com ptg CHAPTER 33 Database Maintenance IN THIS CHAPTER . What’s New in Database Maintenance . The Maintenance Plan Wizard . Managing Maintenance Plans Without the Wizard . Executing a Maintenance Plan . Maintenance Without a Maintenance Plan . Database Maintenance Policies Database maintenance is an essential part of database administration needed to keep databases healthy. It includes tasks performed after your database is created to ensure the integrity of the data in the database, provide performance improvements, and help keep your database safe. This chapter examines some of the key tasks that should be included in your database maintenance plan. It discusses the means for creating these plans, including tools such as the Maintenance Plan Wizard that is part of SQL Server 2008. These tools make the creation of a solid database maintenance plan easier and provide a framework that allows you to create the plan once and let automation do the rest of the work. What Needs to Be Maintained The core tasks related to the maintenance of a SQL Server database are backing up the database and log, rebuilding indexes, updating statistics, and running integrity checks against the database. These ongoing, repetitive tasks are best run on a scheduled basis and are the backbone of the maintenance plan. Other tasks related to maintenance involve managing access by the users, maintaining data files, and monitoring performance. These tasks are more apt to be per- formed on an ad hoc basis when the need arises. Download from www.wowebook.com ptg 1070 CHAPTER 33 Database Maintenance What’s New in Database Maintenance The required database maintenance tasks in SQL Server 2008 have remained the same as in earlier versions, and the tools to perform that maintenance are generally the same as they were in SQL Server 2005. Maintenance plans are still the core tool for performing database maintenance. These plans and the tools to create the plans (such as the Maintenance Plan Wizard) look and behave much like they did in SQL Server 2005. Enhancements to the maintenance plans that were introduced in SQL Server 2005 service packs have been carried on to SQL Server 2008. One new feature related to database maintenance in SQL Server 2008 is the introduction of Database Maintenance Policies (a subset of the Policy-Based Management feature intro- duced in SQL Server 2008). Policy-Based Management is discussed in detail in Chapter 22, “Administering Policy-Based Management.” In this chapter, we briefly cover the basics of using policies for performing database maintenance. The Maintenance Plan Wizard The Maintenance Plan Wizard is a tool that is available in SSMS. It provides an automated means for creating the basic tasks needed to maintain a database. It does not include all the tasks available for use in a maintenance plan but is a great starting point that allows you to quickly generate the basic elements of a good plan. You launch the Maintenance Plan Wizard by expanding the Management node in SSMS and then right-clicking Maintenance Plans and selecting Maintenance Plan Wizard. The Maintenance Plan Wizard is like most other Microsoft wizards in that it presents sequen- tial dialog boxes that allow you to incrementally provide the information needed to create the wizard’s objective. The Maintenance Plan Wizard first displays an introductory dialog box. When you click Next, it displays a dialog box (like the one shown in Figure 33.1) that allows you to specify the name and a description for your maintenance plan. You should choose a naming convention that will allow you to easily identify a maintenance plan and the type of maintenance it is performing. The name is displayed in the Object Explorer tree, and a good naming convention will make it easier to locate the plan you want. The Select Plan Properties screen also allows you to specify the schedule for the mainte- nance plan. This schedule will be tied to the corresponding scheduled job that is created when the Maintenance Plan Wizard completes. You will find that the scheduling dialog that appears when you click on the Change button is very flexible and consistent with other places in SQL Server where a schedule can be defined. After you name the maintenance plan and specify the schedule, you can click Next. The dialog box that appears next allows you to select the maintenance tasks you would like to perform on the server. Figure 33.2 shows the Select Maintenance Tasks dialog, with the tasks that are available from the wizard. You can select more than one task for a given plan. As mentioned earlier, the tasks listed in the wizard are not all the tasks available in a maintenance plan. Download from www.wowebook.com ptg 1071 The Maintenance Plan Wizard FIGURE 33.1 Setting the Maintenance Plan Properties using the Maintenance Plan Wizard. 33 The dialog box that appears next, as shown in Figure 33.3, allows you to specify the order in which the tasks are executed. Obviously, the order of the tasks can be a critical factor and is dependent on the type of tasks you are running. You can click the Move Up and Move Down buttons to change the order of the tasks. FIGURE 33.2 Selecting maintenance tasks in the Maintenance Plan Wizard. Download from www.wowebook.com ptg 1072 FIGURE 33.3 Selecting the order of the maintenance tasks in the Maintenance Plan Wizard. The dialog boxes discussed so far are consistent for all the maintenance plans. The dialog boxes that follow are dependent on the tasks selected for the plan. Each task has a rele- vant set of properties that are displayed for entry in a subsequent dialog box. The follow- ing sections cover some of the common maintenance tasks and the wizard screens that relate to them. Backing Up Databases Backing up databases is the most basic element of a maintenance plan—and probably the most important part. The importance of backups and the role they play are discussed in detail in Chapter 14, “Database Backup and Restore,” but basically, backups are needed to help limit the amount of data loss. For example, in the event of a disk drive failure, data- base backups can be used to restore the database data that was located on that drive. The database backup options available via a maintenance plan include full, differential, and transaction log backups. The type of backup you select for a plan is heavily dependent on the type of environment you are maintaining and the type of database you are backing up. Databases that have very few changes may only need a nightly full backup and do not require transaction log or differential backups. In most cases, it is a good idea to take a full backup of your system and user databases each night. Figure 33.4 shows the backup options the wizard displays for a full backup. To set the properties for a full backup, you need to first define the databases you want to back up. You select the databases by using the Databases drop-down at the top of the screen. This drop-down is unique in that it gives you a variety of radio button options CHAPTER 33 Database Maintenance Download from www.wowebook.com ptg 1073 FIGURE 33.4 Full backup options in the Maintenance Plan Wizard. The Maintenance Plan Wizard 33 rather than just a simple list. You can choose to back up all databases, all system data- bases, or all user databases, or you can select specific databases. After you select the database(s) you want to back up, you must select a destination for the backup files. The destination includes the type of media (that is, tape or disk) and the file or files on that medium. The option Back Up Databases Across One or More Files allows you to specify one or more fixed files that the database backup will always be written to. With this option, you can choose to append each backup to the file(s) or overwrite the contents of the file(s) each time the backup is performed. If you choose to overwrite the backup each time, you have only the latest backup available for restoration. If you choose to append to the file, older backups are retained on this file, and the file continues to grow with each subsequent backup. The preferred option for creating full backups with the wizard is the option Create a Backup File for Every Database. This option creates a separate file for each database in the maintenance plan. The backup file that is created has the database name as the first part of the filename, followed by _backup_ and then a time stamp that indicates when the backup was created. For example, a backup named AdventureWorks2008_backup_200608231402.bak would be a backup file created using this Download from www.wowebook.com . much like they did in SQL Server 2005. Enhancements to the maintenance plans that were introduced in SQL Server 2005 service packs have been carried on to SQL Server 2008. One new feature related. SNAP_AdventureWorks_REPORTING ON ( NAME = AdventureWorks_Data, FILENAME= ‘C:Program Files Microsoft SQL Server MSSQL10 .SQL0 8DE02MSSQLDATA SNAP_AdventureWorks_data_REPORTING.snap’) AS SNAPSHOT OF AdventureWorks Go As. the principal server (REM12374333 SQL0 8DE01), the mirror server (REM12374333 SQL0 8DE02), and the reporting database snapshot (SNAP_AdventureWorks_REPORTING), as shown from SQL Server Management