ptg 704 CHAPTER 22 Administering Policy-Based Management FIGURE 22.8 The Evaluation Results pane. Importing a policy from an XML file is just as simple. Follow these steps to import a policy with SQL Server Management Studio: 1. In Object Explorer, expand the Management folder, expand the Policy Management node, and then select Policies. 2. Right-click on the Policies folder and select Import. 3. The import screen has three options you need to be aware of: a. First, provide the path of the file to import. b. Second, enable the option Replace Duplicate Items When Imported. c. Finally, in the Policy State drop-down box, specify the state of the policy being imported. The options include Preserve Policy State on Import, Enable All Policies on Import, and Disable All Policies on Import. Sample Templates and Real-World Examples The following sections illustrate the sample policy templates included with SQL Server 2008 and real-world examples for using Policy-Based Management. Sample Policy Templates SQL Server 2008 includes a plethora of predefined sample policies, which can be leveraged by importing them into a SQL Server 2008 system. The policies available for import are located in the default installation drive at C:\Program Files\Microsoft SQL Download from www.wowebook.com ptg 705 Sample Templates and Real-World Examples 22 Server\100\Tools\Policies. As mentioned earlier, you can import the desired policies by right-clicking the Policies node and selecting Import. The sample templates are categorized by SQL Server feature such as Database Engine, Reporting Services, and Analysis Services. Evaluating Recovery Models Recovery models determine how SQL Server uses the transaction log. On OLTP systems, the most appropriate recovery model is generally the Full Recovery model. For OLAP systems, the most appropriate recovery model is generally the simple recovery model. For most development environments, the most appropriate recovery model is also the simple recovery model. For mission-critical databases, or databases where point-in-time recovery is important, having a transaction log backed up every five minutes may be required. Policy-Based Management can be used to determine whether the appropriate recovery model is in place for each user database for each server type. Central Management Servers could be created for each server type and a policy can be created to ensure that the appropriate recovery model is in place across all servers managed within a management server. Implementing Surface Area Configuration Checks SQL Server 2005 shipped with the SQL Server Surface Area Configuration (SAC) tool. This tool allowed you to enable or disable various components and services on individual SQL 2005 Servers. This feature was deprecated in SQL Server 2008 because the Microsoft team felt that the better way to handle these configuration tasks was through Policy-Based Management. If you want to implement the Surface Area Configuration feature in SQL Server 2008 to configure components and services, import the following policies: . Surface Area Configuration for Database Engine 2005 and 2000 Features.xml . Surface Area Configuration for Database Engine 2008 Features.xml . Surface Area Configuration for Service Broker Endpoints.xml . Surface Area Configuration for SOAP Endpoints.xml SQL Server Health Checks One of the SQL Server Support Engineers has posted blog entries on how to perform server health checks using Policy-Based Management. You can access his blog using this URL: http://blogs.msdn.com/bartd/archive/2008/09/11/defining-complex-server-health- policies-in-sql-2008.aspx. The main part of the SQL Server health check revolves around ensuring the disk response times are less than 100ms. The Policy uses ExecuteSQL to query the dynamic management view sys.dm_io_virtual_file_stats to ensure that the disk response time is within this limit. You can extend this policy to query other DMVs for other health checks—for example, the use of excessive parallelism or checking to ensure that cumulative wait stats have not exceeded desired boundaries. Download from www.wowebook.com ptg 706 CHAPTER 22 Administering Policy-Based Management Ensuring Object Naming Conventions Your company may have standards for naming objects. For example, stored procedures must start with the prefix usp, tables must start with the prefix tbl, and functions must start with the prefix ufn. Policy-Based Management can be used to ensure that all objects are compliant with this policy. This policy can be implemented to execute as On Change Prevent, which prevents the creation of such noncompliant objects. Checking Best Practices Compliance You can implement policies that check for SQL Server best practices. For example, data- bases can be configured with the autoclose and autoshrink options. Although these options have their place on some systems, they are not recommended to be enabled in production environments because the autoclose option causes a time delay while the data- base is opened by a connection trying to access it. This can lead to timeouts. The autoshrink option can lead to fragmentation and is in general not recommended. A policy can check for these settings and other settings to ensure that all your databases are follow- ing best practices. Policy-Based Management Best Practices Following are some best practices to consider when implementing Policy-Based Management in SQL Server 2008: . When deploying Policy-Based Management in your environment, you should be very careful about using On Change Prevent. For example, a policy that prevents stored procedure creation with the sp_ prefix prevents the enabling of replication on a SQL Server. . When you create a policy that you want enforced on all user databases, you should place this policy in the default category so that it is subscribed to all databases. Otherwise, you need to manually subscribe all databases to the categories that contain the policies you want enforced. . You should make use of multiple Configuration Servers or Server Groups to group your SQL Servers according to logical groupings on which you want to group your policies. . Importing policies into centralized SQL Server 2008 servers makes it easier to deploy groups of policies against groups of servers using Central Management Servers—for example, to store data warehouse policies on Server A. You should use this server as a source when selecting policies to evaluate against your data warehouse servers registered in the Data Warehousing Central Management Server. . You might find that your environment contains third-party user applications/data- bases that are not in compliance with the policies you have created for your enter- prise. Policy-Based Management uses the opt-in metaphor such that all policies are enforced by default. For databases on which you do not want the policy to be enforced, you need to tag the database, perhaps with an extended property or a Download from www.wowebook.com ptg 707 Summary 22 specially named table that the server exception category or target will detect and exempt that server or database from the policy. . You should use the ExecuteWSQL task to issue WMI queries to extend conditions and policies beyond the SQL Server environment—for example, to check what other ser- vices may be running on a server hosting SQL Server. Summary Policy-Based Management is a new component in SQL Server 2008 that allows you to manage your SQL 2000, 2005, and 2008 servers by creating policies that can be used to enforce compliance to best practices or to report on out-of-compliance servers. It provides a highly granular, flexible, and extensible toolset that allows you to manage all aspects of your SQL Server. Properly used, it is a great tool to enforce standardization in your envi- ronment and to ease the management burden. The next part of this book, Part IV, “Database Administration,” explores the tasks involved in creating and managing databases and database objects, just the sorts of things you want to apply many of your best practices and policies against. Download from www.wowebook.com ptg This page intentionally left blank Download from www.wowebook.com ptg CHAPTER 23 Creating and Managing Databases IN THIS CHAPTER . What’s New in Creating and Managing Databases . Data Storage in SQL Server . Database Files . Creating Databases . Setting Database Options . Managing Databases A database is a collection of tables and related objects that help protect and organize data. It must exist before you can create all database objects, including tables, indexes, and stored procedures. This chapter focuses on how to create a sound database that can house database objects and how to manage the database after the objects are created. The creation and management of the various database objects is discussed in the remaining chapters in Part IV, “Database Administration.” NOTE It is important to remember that SQL Server actually uses its own set of databases that are installed by default when SQL Server is installed. These databases are referred to as system databases. The databases that users create are aptly named user databases. The system databases include master, model, msdb, tempdb, and resource. Each of these databases per- forms a key function in the operation of SQL Server. For example, the master database contains an entry for every user database created and contains server- wide information critical to the operation of SQL Server. The model database is basically a template database for any newly created databases. Each sys- tem database is based on a structure similar to user databases and contain database objects like those contained in user databases. The system databases are discussed in detail in Chapter 7, “SQL Server System and Database Administration.” Download from www.wowebook.com ptg 710 CHAPTER 23 Creating and Managing Databases What’s New in Creating and Managing Databases SQL Server 2008 offers several new features that provide improved security and manage- ability. The primary security enhancement is the capability to encrypt an entire database using Transparent Data Encryption (TDE). This transparent data encryption applies to the data files and log files that make up a database. It allows for an entire database to be secure via encryption without the need to change existing applications or the individual database objects. Transparent Data Encription is covered in Chapter 12, “Data Encryption.” The manageability improvements in SQL Server 2008 are centered around data compres- sion and enhanced database mirroring. The data compression improvements help reduce the amount of space that your database files occupy. The enhancements in database mirroring include automatic page repair, improved performance, and enhanced supporta- bility via additional performance counters and new dynamic management views. Database mirroring is discussed in more detail in Chapter 20, “Database Mirroring.” Data Storage in SQL Server A database is a storage structure for database objects. It is made up of at least two files. One file, referred to as a data file, stores the database objects, such as tables and indexes. The second file, referred to as the transaction log file, records changes to the data. A data file or log file can belong to only one database. SQL Server stores data on the data file in 8KB blocks, known as pages. A page is the small- est unit of input/output (I/O) that SQL Server uses to transfer data to and from disk. An 8KB page is equal to 1024 bytes × 8, or 8192 bytes. There is some overhead associated with each data page, so the maximum number of bytes of data that can be stored on a page is 8060 bytes. The overhead on a data page includes a 96-byte page header that contains system information about the page. This system information includes the page number, page type, and amount of free space on the page. Generally, a row of data in a SQL Server database is limited to the 8060-byte maximum. With SQL Server 2008, there are some exceptions to this 8060-byte limit if the table contains columns that have the data types text/image, varchar, nvarchar, varbinary,or sql variant. With these data types, SQL Server can store the data in a separate data struc- ture when the size of the row exceeds the 8060-byte limit. When the 8060-byte limit is exceeded, SQL Server stores a pointer to the separate data structure so that the information in these columns can be accessed. In an effort to reduce internal operations and increase I/O efficiency, SQL Server, when allocating space to a table or an index, allocates space in extents. An extent is eight contigu- ous pages, or 64KB of storage. There are actually two types of extents. Every table or index is initially allocated space in a mixed extent. As the name implies, mixed extents store pages from more than one object. When an index or a table is first created, it is assigned an index allocation map (IAM), which is used to track space usage for the object, and at least one data page. The IAM and data page are assigned to a mixed extent in an effort to save Download from www.wowebook.com ptg 711 Database Files space because dedicating an extent to a table with a few small rows would be wasteful. Up to eight initial pages are assigned this way. When an object requires more than eight pages of storage, all further space is allocated from uniform extents. A uniform extent stores pages for only a single index or table. This allows SQL Server to optimize read and write opera- tions and reduce fragmentation because the data is stored in units of 64KB (that is, eight pages) as opposed to individual 8KB pages being scattered throughout the data file. For more detailed information on the internal storage structures and how to manage them in SQL Server databases, see Chapter 38, “Database Design and Performance.” Database Files SQL Server maps a database over a set of operating system files visible to the SQL Server machine. Microsoft recommends that the files be located on a storage area network (SAN), on an iSCSI-based network, or on a locally attached disk. These three storage options provide the best performance and reliability for a SQL Server database. You have an option of storing database files on a network, but this option is turned off by default. You can use the trace flag 1807 to enable network-based database files, but it is generally not recom- mended that you do so. Each database can contain a maximum of 32,767 files. Each database file serves a different purpose for the database engine. These files have a standard layout that allows SQL Server to organize and read the data within the files. SQL Server needs to keep track of the allo- cated space in each data file; it does so by allocating special pages in the first extent of each file. Because the data stored on these pages is dense and the files are accessed often, they are usually found in memory; therefore, they can be retrieved quickly. The first page (page 0) in every file is the file header page. This page contains information about the file, such as the database to which the file belongs, the filegroup it is in, the minimum size, and its growth increment. The second page (page 1) in each file is the page free space (PFS) page. The PFS page keeps track of the other pages in the database file. The PFS uses 1 byte for each page. This byte keeps track of whether the page is allocated, whether it is empty, and, if it is not empty, how full the page is. A single PFS page can keep track of 8,000 contiguous pages. Additional PFS pages are created as needed. The third page (page 2) in each file is the global allocation map (GAM) page. This page tracks allocated extents. Each GAM page tracks 64,000 extents, and additional GAM pages are allocated as needed. The GAM page contains 1 bit for each extent, which is set to 0 if the extent is allocated to an object and to 1 if it is free. The fourth page (page 3) is the secondary GAM (SGAM) page. The SGAM page tracks allo- cated mixed extents. Each SGAM page tracks 64,000 mixed extents, and additional SGAM pages are allocated as needed. A bit set to 1 for an extent indicates a mixed extent with pages available. 23 Download from www.wowebook.com ptg 712 CHAPTER 23 Creating and Managing Databases Primary Files The primary data file is the data file that keeps track of all the other data files used by the database. It is an operating system file that typically has the file extension .mdf. SQL Server does not require that it have this .mdf extension, but it is recommended for consis- tency. The primary data file is the first file created for a database. Each database must have only one primary file. This file stores data for any database objects mapped to it, and it contains references to any other database files created. In many cases, the primary data file is the only data file. There is no requirement to have more than one data file, and often, a database contains only one primary data file (for example, C:\mssql\mydb.mdf) and only one log file (for example, C:\mssql\mydb_log.ldf). Secondary Files You can create zero or more secondar y data files in a database. These files, by default, are identified with the .ndf extension, but the extension can be different. Secondary data files provide an opportunity to spread the data that SQL Server stores over more than one phys- ical file. This capability can be particularly useful for larger databases and can help with performance and management of database files. Consider, for example, a situation in which a database server has four physical drives available for the data file(s). Each drive is 1GB in size, but the database you are creating is 2GB. In this example, the database will not fit on one drive. A solution to this problem is to create a primary data file on one of the drives and a secondary data file on each of the three remaining drives. SQL Server automat- ically spreads the 2GB database across the four data files located on four separate drives. Secondary files also provide some added flexibility for backing up or copying databases. This is most apparent with large databases. For example, let’s say you have a 100GB data- base, and it contains only a primary data file. If you want to move this database to another environment, you must have a drive that is at least 100GB to store the primary data file. If you want to copy the database to a server that has 10 50GB drives, you cannot do it. You have the space across all 10 drives, but you do not have a single drive that can hold the primary data file. If, however, you create the database with several secondary files, you have the option of placing each of the secondary files on a separate drive. TIP You can use the sys.master_files catalog view to list the database files for all the databases. For example, SELECT db_name(database_id),* from sys.master_files order by 1 returns all the database files, ordered by the name of the database they belong to. You can change the sort order for the SELECT state- ment and order it by physical_name to quickly locate a database file and find which database is using that file. Download from www.wowebook.com ptg 713 Database Files Using Filegroups Filegroups allow you to align certain database objects with specific data files. Tables, indexes, and large object (LOB) data can be assigned to a filegroup. A filegroup can be associated with one or more data files. The alignment of data and indexes to filegroups can provide performance benefits and improve manageability. Each database has at least one filegroup, called the primary filegroup. This filegroup, by default, contains the primary data file and any other secondary data files that have not been specifically aligned with another filegroup. Any database object that you create without specifying a filegroup is created in the primary filegroup. Additional filegroups can be created and aligned with secondary data files. There is no requirement to have more than one filegroup, but additional filegroups give you added flex- ibility. Filegroups can be aligned with data files that can be stored on separate disk drives to improve data access. This improvement is facilitated by concurrent disk access across the disk drives assigned to the filegroups. TIP If too many outstanding I/Os are causing bottlenecks in the disk I/O subsystem, you might want to consider spreading the files across more disk drives. Performance Monitor can identify I/O bottlenecks by monitoring the PhysicalDisk object and Disk Queue Length counter. You should consider spreading the files across multiple disk drives if the Disk Queue Length counter is greater than two times the number of spin- dles on the disk. For more information on monitoring SQL Server performance, see Chapter 39, “Monitoring SQL Server Performance.” For example, you could create a filegroup called UserData_FG, consisting of three files spread over three physical drives. You could create another filegroup named Index_FG, with a single file, on a fourth drive. Then, when you create the tables, you can create them on the UserData_FG filegroup. You can create indexes on the Index_FG filegroup. This reduces contention between tables because the data is spread over three disks and can be accessed independently of the indexes. If more storage is required in the future, you can easily add additional files to the index or data filegroup, as appropriate. You can create filegroups at the time the database is created, or you can add them after the database is created. When you create filegroups along with the database, the definition for the filegroup is contained in the CREATE DATABASE statement. Following is an example of a CREATE DATABASE statement with filegroup definitions: CREATE DATABASE [mydb] ON PRIMARY ( NAME = N’mydb’, FILENAME = N’C:\mssql2008\data\mydb.mdf’ , SIZE = 2048KB , FILEGROWTH = 1024KB ), FILEGROUP [Index_FG] 23 Download from www.wowebook.com . Configuration Servers or Server Groups to group your SQL Servers according to logical groupings on which you want to group your policies. . Importing policies into centralized SQL Server 2008 servers. beyond the SQL Server environment—for example, to check what other ser- vices may be running on a server hosting SQL Server. Summary Policy-Based Management is a new component in SQL Server 2008 that. in SQL Server databases, see Chapter 38, “Database Design and Performance.” Database Files SQL Server maps a database over a set of operating system files visible to the SQL Server machine. Microsoft