ptg 1084 CHAPTER 33 Database Maintenance Managing Maintenance Plans Without the Wizard You can create or modify maintenance plans in SQL Server 2008 without using the Maintenance Plan Wizard. To create a new maintenance plan without the wizard, you right-click the Maintenance Plan node in the Object Explorer and select New Maintenance Plan. You are prompted for a maintenance plan name and then taken to the Design tab for the maintenance plan. The Design tab consists of a properties section at the top of the screen and a plan designer surface that is empty for a new maintenance plan. Existing maintenance plans are displayed in the Design tab when you right-click the plan and select Modify. Figure 33.13 shows the Design tab for a maintenance plan that was created with the Maintenance Plan Wizard to back up the system databases. The Design tab represents a significant difference from the way maintenance plans were managed in SQL Server 2000. The plan designer surface on the Design tab has drag-and- drop capabilities that allow you to add maintenance tasks to your plan. The available tasks are located in the Toolbox component. The Toolbox and the related tasks are shown in Figure 33.13 in the middle portion of the screen. To add a tool from the Toolbox, you drag the item from the Toolbox to the plan designer surface. Alternatively, you can double-click the task, and the task appears on the plan designer surface. FIGURE 33.13 The maintenance plan Design tab. Download from www.wowebook.com ptg 1085 Managing Maintenance Plans Without the Wizard 33 On the plan designer surface, you can move each of the tasks around, link them to other tasks, and edit them by double-clicking them. You can also right-click a task to edit it, group it with other tasks, autosize it, and gain access to other task options. You can right- click an empty section of the plan designer surface to add annotations or comments that provide additional information about the task or the overall plan. NOTE The dialog boxes displayed when you edit a task are unique for each task. The avail- able maintenance plan tasks display an options screen like the one displayed during the execution of the Maintenance Plan Wizard. This provides consistency that is in place regardless of where the task is defined. Adding a task to an existing maintenance plan is a good starting point to become familiar with the workings of the Design tab. Consider, for example, the maintenance plan shown in Figure 33.13. This plan, which was initially created with the Maintenance Plan Wizard, is used to create full database backups of all the system databases. One critical aspect that is missing from this plan is a task to remove older database backups. The task that can help you with this is the Maintenance Cleanup task. If you double-click that task in the Toolbox, the task is added to the plan designer surface, as shown in Figure 33.14. FIGURE 33.14 Adding a task to the plan designer surface. Download from www.wowebook.com ptg 1086 CHAPTER 33 Database Maintenance After you add a task to the plan designer surface, you need to configure it. Note that a small red X icon appears on the right side of the task if the task has not yet been config- ured. To configure the Maintenance Cleanup task, you double-click it on the plan designer surface. Figure 33.15 shows the screen that appears so you can configure the Maintenance Cleanup task. You can use the Maintenance Cleanup task to clean up old backup files or maintenance plan text reports. The deletion of older backup files is particularly important because data- base backups tend to be large files and can use up a significant amount of disk space. The File Location section of the screen enables you to delete a specific file, or you can delete files in a folder based on search criteria. In most cases, you want to search the folder to delete older files. When cleaning up database backup files, you typically specify the file extension .bak. If you chose to write each database’s backups to a separate folder, you should choose the Include First-Level Subfolders options, which allows you to search all first-level subfolders that exist under the folder specified. This simplifies the cleanup process and eliminates the need to have a separate cleanup task for each subfolder. In the last section of the configuration screen for the Maintenance Cleanup task, you specify how old a file must be in order to be deleted. The default is four weeks, but you FIGURE 33.15 Configuring the Maintenance Cleanup task. Download from www.wowebook.com ptg 1087 Managing Maintenance Plans Without the Wizard 33 can adjust this setting to the desired time frame by using the related drop-downs. If you uncheck Delete Files Based on the Age of the File at Task Run Time, all files in the folder or subfolders are deleted, regardless of age. NOTE The deletion of database backup files is not based on the file dates or the name of the backup file. The Maintenance Cleanup task uses a procedure named xp_delete_file that examines the database backup and time the backup was created. Renaming the database backup file does not affect its inclusion in the deletion process. After configuring the options for the Maintenance Cleanup task, you can click the View T- SQL button at the bottom of the screen. This feature reveals what is going on behind the scenes when the plan executes. Prior to SQL Server 2005, you had to obtain this kind of information by using the Profiler. When you click OK, the task is ready to use in the maintenance plan. The task runs in parallel with the other tasks defined in the plan unless a precedence or link is established between the tasks. To establish a link between the tasks, you select the first task that you want to execute. When the task is selected, a green arrow is shown at the bottom of the task’s box in the plan designer surface. You click the green arrow and drag it to the task that you want to run next. The green arrow is then connected to the other task. If you double-click the green arrow (or right-click and choose Edit), the Precedence Constraint Editor appears, as shown in Figure 33.16. The paragraph at the top of the Precedence Constraint Editor gives a good description of what a precedence constraint is. In short, it can link tasks together based on the results of their execution. For example, if a backup database task succeeds, a Maintenance Cleanup FIGURE 33.16 The Precedence Constraint Editor. Download from www.wowebook.com ptg 1088 CHAPTER 33 Database Maintenance task can be defined to run next. You can also set the constraint value so that the next task will run only if the first task fails, or you can have the next task run based on the prior task’s completion, regardless of whether if succeeds or fails. In addition, you can link multiple tasks together with precedence. You define the logical relationship between tasks in the Multiple Constraints section of the Precedence Constraint Editor. The workflow and relationships that can be defined between tasks for a maintenance plan are extensive and beyond the scope of this chapter. Many of the workflow concepts are similar to those of the DTS designer in SQL Server 2000 and the SSIS designer in SQL Server 2008. Executing a Maintenance Plan Maintenance plans that have been scheduled run automatically according to the schedule defined. You can also run maintenance plans manually by right-clicking a maintenance plan and selecting Execute or by selecting the SQL Server Agent job associated with the maintenance plan and starting the job. The execution behavior is different, depending on the means you use. If you choose to run the maintenance plan from the Management node, the SSIS package is launched, and the Execute Maintenance Plan window displays the current status of the plan execution. If you run the SQL Server Agent job to execute the maintenance plan, a dialog box indi- cating the execution status of the job appears. The dialog does not indicate success for the maintenance plan until the entire maintenance plan has completed. The dialog box for the job can be closed, and the job will still continue to run. The Execute Maintenance Plan window, on the other hand, does not have an option to close it, and it must stay open until the plan completes. There are two other means for monitoring the execution of maintenance plans. The Job Activity Monitor shows a status of executing while a maintenance plan is executing. You can set the refresh settings on the Job Activity Monitor to auto-refresh for the desired increment. You can also monitor the execution by establishing a connection to the SSIS server in SSMS. To establish an SSIS connection in SSMS, you click the Connect drop- down in the Object Explorer and choose Integration Services. Figure 33.17 shows an example of the Object Explorer with an Integration Services connection. The Integration Services connection in the Object Explorer shows the packages that are running in addition to the packages that have been created. If you expand the Stored Packages node and navigate to the MSDB node, you see a node named Maintenance Plans that shows all the SSIS packages that have been created. You can also edit the package with BIDS, but that topic is beyond the scope of this chapter. See Chapter 52 for more information. Download from www.wowebook.com ptg 1089 Maintenance Without a Maintenance Plan 33 FIGURE 33.17 The Object Explorer with an Integration Services connection. NOTE SSIS does not need to be installed on the SQL Server machine to be able to create and execute maintenance plans. In the initial release of SQL Server 2005, this was a requirement but was changed with SQL Server 2005 SP2. This change carried over to SQL Server 2008, and maintenance plans are now fully functional with the SQL Server Database Services installation. Maintenance Without a Maintenance Plan You can perform database maintenance without the use of the built-in maintenance plans that come with SQL Server. The additional complexity in SQL Server 2008 may steer some people away from the use of these plans. In addition, these plans cannot be scripted, so deployment to multiple environments is not straightforward. Database maintenance that is performed without a maintenance plan is often performed using custom scripts or stored procedures that execute the T-SQL commands to perform the maintenance. Other methods include manually executing the SQLMAINT utility to perform various maintenance tasks such as database backups and consistency checks. Often these maintenance commands or custom scripts are then scheduled to run on a regular basis by manually setting up jobs within the SQL Server Agent job scheduler in SQL Server Management Studio. (For more information on setting up and scheduling jobs in SQL Server Agent, see Chapter 16, “SQL Server Scheduling and Notification.”) Setting up maintenance tasks manually is a viable option, especially for the more experi- enced DBA because it requires additional development work and familiarity with the maintenance commands and options. However, even the experienced DBA should consider using maintenance plans because maintenance tasks set up manually may lack the integration with other SQL Server components that is offered with the SQL Server 2008 maintenance plans. Download from www.wowebook.com ptg 1090 CHAPTER 33 Database Maintenance Database Maintenance Policies Policy-Based Management, a new management feature introduced in SQL Server 2008, allows you to manage your SQL Server instances through clearly defined policies, reducing the potential for administrative errors or oversight. The policy-based framework imple- ments the policies you defined via a Policy Engine, SQL Server Agent jobs, SQLCLR, DDL triggers, and Service Broker. You can choose to have the policies you defined be applied or evaluated against a single server or a group of servers, thus improving the scalability of monitoring and administration. Policy-Based Management allows you to prescribe the way you want your databases main- tained, and the system will help ensure things stay that way. Essentially, Policy-Based Management allows you to define rules for one or more SQL Servers and evaluate them. The goal of this feature is to make it easier for you to manage one or more servers by noti- fying you when servers are out of compliance with the database maintenance policies you have defined. For example, you could define a policy to ensure that transaction log backups are being performed on the appropriate intervals on your OLTP databases. Policy-Based Management allows you to determine when one of your databases is not in compliance with your log backup policy. You can set up this policy to be evaluated on demand or via a schedule. For more information on defining and using policies, see Chapter 22. Summary Establishing a database maintenance plan is important. Just like your car or your home, a database needs maintenance to keep working properly. The powerful features available with the SQL Server 2008 maintenance plans and Maintenance Plan Wizard make the creation of a robust maintenance plan relatively easy. If you establish your maintenance plans early in the life of your databases, you will save yourself time and aggravation in the long run. Chapter 34 delves further into the importance of indexes and their relationship to perfor- mance. It expands on the optimization of indexes mentioned in this chapter and describes the role that indexes play in keeping databases running fast. Download from www.wowebook.com ptg CHAPTER 34 Data Structures, Indexes, and Performance IN THIS CHAPTER . What’s New for Data Structures, Indexes, and Performance . Understanding Data Structures . Database Files and Filegroups . Database Pages . Understanding Table Structures . Understanding Index Structures . Data Modification and Performance . Index Utilization . Index Selection . Evaluating Index Usefulness . Index Statistics . SQL Server Index Maintenance . Index Design Guidelines . Indexed Views . Indexes on Computed Columns . Filtered Indexes and Statistics . Choosing Indexes: Query Versus Update Performance . Identifying Missing Indexes . Identifying Unused Indexes A number of factors affect SQL Server performance. One of the key factors is your table and index design; poor table and index design can result in excessive I/O and poor performance. To aid in developing a good table and index design in an effort to improve SQL Server performance by minimizing I/O, you need to have a good understanding of SQL Server data structures and indexes. Proper table and index design is a key issue in achieving optimum SQL Server application performance. For example, you can often realize substantial performance gains in your SQL Server applications by creating the proper indexes to support the queries and operations being performed. At the same time, it’s important to keep in mind that although many indexes on a table can help improve response time for queries and reports, too many indexes can hurt the performance of inserts, updates, and deletes due to the overhead required to maintain the index and data rows. Additionally, other index design decisions, such as which column(s) to create a clustered index on, might be influ- enced as much by how the data is inserted and modified and what the possible locking implications might be as they are by the query response time alone. In this chapter, you learn about the underlying structures of databases, tables, rows, and indexes and how SQL Server maintains index and data structures because this informa- tion provides a basis for understanding the performance of your tables and indexes. This chapter discusses the storage structures in SQL Server and how these storage structures are maintained and managed. The chapter also discusses how SQL Server evaluates and uses indexes to improve query response time. Using this information, you should have a better understanding of the issues and factors that influence good table and index design. Download from www.wowebook.com ptg 1092 CHAPTER 34 Data Structures, Indexes, and Performance What’s New for Data Structures, Indexes, and Performance SQL Server 2008 provides a number of new features related to data structures, indexes, and performance. Among these new features are filtered indexes and statistics. Filtered indexes utilize a WHERE clause that filters or limits the number of rows included in the index. The smaller filtered index allows queries run against rows containing data values in the index to run faster. These filtered indexes can also save on the disk space used by the index. A well-designed filtered index can improve query performance, reduce index maintenance costs, and reduce index storage costs compared with full-table indexes. Also new to SQL Server 2008 is the capability to compress data in indexes and tables to reduce the amount of storage space required and, in turn, reduce the I/O needed for these objects. Page-level data compression helps to reduce both storage and memory requirements as the data is compressed both on disk and when brought into the SQL Server data cache. Row-level compression isn’t true data compression but implements a more efficient storage format for fixed-length data. Other storage features introduced in SQL Server 2008 to reduce storage space requirements are sparse columns and column sets. Sparse columns are ordinary columns that use an opti- mized storage format for NULL values. FILESTREAM storage was also introduced in SQL Server 2008 as a new storage mechanism for binary large object (BLOB) data. FILESTREAM storage is a property that can be applied to varbinary(max) columns and enables SQL Server applications to store unstructured data, such as documents and images, directly in the NTFS file system while still maintain- ing the behavior of a database column. The advantages of FILESTREAM storage are improved performance and increased size of BLOB data, expanding from the 2GB limit of image columns to the available space in the file system. Spatial indexes are new to SQL Server 2008 as well. These indexes are used against spatial data defined by coordinates of latitude and longitude. The spatial data is essential for effi- cient global navigation. The spatial indexes are grid-based and help optimize the perfor- mance of searches against the spatial data. NOTE This chapter assumes that you already have an understanding of the different types of indexes and how to define them. For more information on index types and how to cre- ate indexes, see Chapter 25, “Creating and Managing Indexes.” Download from www.wowebook.com ptg 1093 Database Files and Filegroups 34 Understanding Data Structures SQL Server DBAs and users do not see data and storage the same way SQL Server does. A DBA or end user sees a database more logically as the following: . Databases, physically stored in files . Tables and indexes, placed in filegroups within databases . Rows, stored in tables SQL Server internally sees these storage structures at a lower, physical level as . Databases, physically stored in data and log files . Pages within these files, allocated to tables and indexes . Data and index rows, stored in slots on pages Database Files and Filegroups Databases in SQL Server 2008 span at least two, and optionally several, database files. There must always be at least one file for data and one file for the transaction log. These database files are normal operating system files created in a directory within the operating system. These files are created when the database is created or when a database is expanded. Each database file has the following set of properties: . A logical filename—This name is used for internal reference to the file. . A physical filename—This name is the actual physical pathname of the file. . An initial size—If no size is specified for primary data file, its initial size, by default, is the minimum size required to hold the contents of the model database. . An optional maximum size—A maximum file size limit can be specified. . A file growth increment—This amount is specified in megabytes or as a percentage. The information and properties about each file for a database are stored in the database visible via the system catalog view called sys.database_files. This view exists in every database and contains information about each of the database files. The master database contains a similar view, sys.master_files, that contains file information for all databases within the SQL Server instance. Table 34.1 lists the most useful columns in the sys.database_files view. Download from www.wowebook.com . jobs within the SQL Server Agent job scheduler in SQL Server Management Studio. (For more information on setting up and scheduling jobs in SQL Server Agent, see Chapter 16, SQL Server Scheduling. installed on the SQL Server machine to be able to create and execute maintenance plans. In the initial release of SQL Server 2005, this was a requirement but was changed with SQL Server 2005 SP2 changed with SQL Server 2005 SP2. This change carried over to SQL Server 2008, and maintenance plans are now fully functional with the SQL Server Database Services installation. Maintenance Without