Nielsen c39.tex V4 - 07/21/2009 2:17pm Page 932 Part VI Enterprise Data Management To revert this change and make the AdventureWorks2008 database online and available, do the fol- lowing: ALTER DATABASE AdventureWorks2008 SET ONLINE; You may encounter a situation in which the database is inaccessible and you do not have a backup. To access the database regardless of online/offline state, members of the sysadmin role can put the database in EMERGENCY mode. Once in EMERGENCY mode, the database is in read-only mode and is accessible only by members of the sysadmin role. To put the AdventureWorks2008 sample database in EMERGENCY mode in code, do the following: ALTER DATABASE AdventureWorks2008 SET EMERGENCY; The READ_ONLY database-state settings are used to allow only selects from the database. READ_ONLY cannot take effect if any users are i n the database. To reset the database to a normal read-and-write state, the READ_WRITE database setting is used. To set the AdventureWorks2008 sample database to a READ_ONLY state in code, do the following: ALTER DATABASE AdventureWorks2008 SET READ_ONLY; The restricted access database-state settings are also available. The three restricted access levels are single_user, restricted_user,andmulti_user states. These settings control which users are allowed to access the database. T he SINGLE_USER setting is appropriate when you are doing database maintenance. The RESTRICTED_USER setting allows database access only to users in the db_owner, dbcreator,andsysadmin roles. The MULTI_USER setting is used to set the database in the normal operating state. The following sets the AdventureWorks2008 sample database to SINGLE_USER access: ALTER DATABASE AdventureWorks2008 SET SINGLE_USER; To revert the preceding setting and set the AdventureWorks2008 database access to MULTI_USER access, do the following: ALTER DATABASE AdventureWorks2008 SET MULTI_USER; Compatibility level In SQL Server, the database-compatibility level can be set to 80 (SQL Server 2000), 90 (SQL Server 2005), or 100 (SQL Server 2008). When a database is upgraded to SQL Server 2008 from any earlier version of SQL Server, the database retains its existing compatibility level. Setting the database- compatibility level to a level lower than 100 may be necessary if you are upgrading the Database Engine and still need to maintain the behavior of an earlier version of SQL Server. The compatibility level option does not provide full backward compatibility. It is mainly intended to enable new reserved words to be used in tables, and to retain some (very lim- ited) changed behavior. Refer to SQL Server Books Online for a full overview. To set the compatibility level of the AdventureWorks2008 sample database to 100 (SQL Server 2008) in code, do the following: ALTER DATABASE AdventureWorks2008 SET COMPATIBILITY_LEVEL = 100; 932 www.getcoolebook.com Nielsen c39.tex V4 - 07/21/2009 2:17pm Page 933 Configuring SQL Server 39 TABLE 39-13 Recovery-Configuration Properties Property Level* Graphic Control Code Option Recovery Model D Management Studio ALTER DATABASE <DB Name> SET RECOVERY Page Verify D Management Studio ALTER DATABASE <DB Name> SET PAGE_VERIFY Media Retention S Management Studio EXEC sp_configure ‘media retention’ Backup Compression S Management Studio EXEC s p_configure ‘backup compression default’ Recovery Interval S Management Studio EXEC sp_configure ‘recovery interval’ * The configuration level refers to Server, Database, or Connection. New in 2008 I n SQL Server 2008, the ALTER DATABASE syntax shown in the sample code replaces the sp_dbcmptlevel stored procedure for setting the database compatibility level To view the compatibility level of SQL Server, query the compatibility_level column in the sys.databases catalog view. Recovery-configuration properties The recovery-configuration properties, shown in Table 39-13, are used to set recovery options in SQL Server. The recovery options determine how SQL Server handles transactions and the transaction log, and how the transaction log is backed up. Recovery model SQL Server 2008 uses a recovery model to c onfigure several settings that work together to control how the transaction l og behaves regarding file growth and recovery possibilities. The three recovery model options are as follows: ■ Simple: The transaction log contains only transactions that are not yet written to the data file. This option does not provide up-to-the-minute recovery. 933 www.getcoolebook.com Nielsen c39.tex V4 - 07/21/2009 2:17pm Page 934 Part VI Enterprise Data Management ■ Bulk-Logged: The transaction log contains all DML operations, but bulk insert operations are only marked, not logged. ■ Full: The transaction log contains all changes to the data file. This option provides the greatest recovery potential. Chapter 41, ‘‘Recovery Planning,’’ focuses on recovery planning and operations in detail. In code, set the recovery option with the ALTER DATABASE SET RECOVERY command. In Management Studio, the recovery model can be changed by selecting Simple, Bulk-logged, or Full in the Recovery Model drop-down list in the Database Properties Options tab (refer to Figure 39-2). To set the recovery mode in the AdventureWorks2008 sample database to Bulk-Logged in code, do the following: ALTER DATABASE AdventureWorks2008 SET RECOVERY BULK_LOGGED; Page Verify Even though SQL Server works with 8KB data pages, the operating system I/O writes in 512-byte sec- tors. Therefore, it’s possible that a failure might o ccur in the middle of a data-page write, resulting in only some of the 512-byte sectors to be written to disk. This is known as a torn page. You can have SQL Server tell you if a torn page occurs by using the PAGE_VERIFY database option. The PAGE_VERIFY database option can be set to one of the following values: ■ CHECKSUM: This is the default level for PAGE_VERIFY. With this option, SQL Server calcu- lates a checksum over the contents of each page and stores the value in the page header when a page is written to disk. When the page is read from disk, the checksum is recalculated and compared to the original checksum value. ■ TORN_PAGE_DETECTION: This option instructs SQL Server to toggle a bit on each 512-byte sector with each write operation. If all the sectors were written to disk, then all the detection bits should be identical. If, on recovery, any of the bits are different, then SQL Server can detect the torn-page condition and mark the database as suspect. ■ NONE: With this option, database page writes will not generate a CHECKSUM or TORN_PAGE_DETECTION value. To change the PAGE_VERIFY option, you can either use Management Studio or T-SQL code. In Man- agement Studio, PAGE_VERIFY can be changed b y selecting CHECKSUM, TORN_PAGE_DETECTION,or NULL in the Page Verify box in the Database Properties Options tab (refer to Figure 39-2). Using T-SQL code, the following command can be used to set the PAGE_VERIFY option for AdventureWorks2008 sample database to TORN_PAGE_DETECTION: ALTER DATABASE AdventureWorks2008 SET PAGE_VERIFY TORN_PAGE_DETECTION; To view the PAGE_VERIFY option for the database, query the page_verify_option_desc column in the sys.databases catalog view. 934 www.getcoolebook.com Nielsen c39.tex V4 - 07/21/2009 2:17pm Page 935 Configuring SQL Server 39 Media retention The media retention option is used to set the number of days to retain each backup set. The default value for media retention is 0 days. This option helps protect backups from being overwritten until the specified number of days has elapsed. In Management Studio, the media retention server configuration option can be set by entering the number of days to retain each backup media in the ‘‘Default backup media retention (in days)’’ box in the Server Properties Database Settings tab (see Figure 39-11). FIGURE 39-11 The Database Settings tab of Management Studio’s Server Properties To set media retention to 10 days in code, do the following: EXEC sp_configure ‘show advanced options’, 1; RECONFIGURE; EXEC sp_configure ‘media retention’, 10; RECONFIGURE; 935 www.getcoolebook.com Nielsen c39.tex V4 - 07/21/2009 2:17pm Page 936 Part VI Enterprise Data Management Backup compression Backup compression is a new feature introduced in SQL Server 2008 Enterprise Edition. Although this feature is supported only in Enterprise Edition, every SQL Server 2008 edition can restore a compressed backup. In Management Studio, to compress new backups by default, set backup compression default by checking the Compress Backup check box in the Server Properties Database Settings tab (refer to Figure 39-11). To set backup compression default in code, do the following: EXEC sp_configure ‘backup compression default’, 1 RECONFIGURE After installation, new backups are uncompressed by default. Backup compression can greatly reduce backup size and backup restore time. This improvement is not free, however. Backup compression significantly increases CPU usage, which may impact other operations on the server. Hence, I recommend testing this feature thoroughly to understand the pros and cons before implementing it in your production SQL Server. For more information about backup compression, refer to Chapter 41, ‘‘Recovery Planning.’’ Recovery interval The recovery interval server configuration option controls when SQL Server issues checkpoints for each database. A checkpoint flushes dirty pages from the buffer cache of the database to disk. Check- points are performed when SQL Server estimates that the recovery time will be longer than the speci- fied recovery interval. The estimated duration applies only to the REDO (roll forward) phase of the recovery, not the UNDO (roll backward) phase. The default value for this option is 0, which implies that this option is automatically configured by SQL Server. Best Practice L eave the recovery interval option at the default value of 0. If you do change the recovery interval, then be sure to test it thoroughly and evaluate all other performance-tuning opportunities first. If you insist on changing the recovery interval option, you can use either Management Studio or T-SQL code. In Management Studio, the recovery interval server configuration option can be set by entering the maximum number of minutes per database to recover databases in the ‘‘Recovery interval (minutes)’’ box in the Server Properties Database Settings tab (refer to Figure 39-11). 936 www.getcoolebook.com Nielsen c39.tex V4 - 07/21/2009 2:17pm Page 937 Configuring SQL Server 39 Using T-SQL code, the following command sets the recovery interval server configuration option to five minutes: EXEC sp_configure ‘show advanced options’, ‘1’; RECONFIGURE; EXEC sp_configure ‘recovery interval’, 5; RECONFIGURE; Summary Configuration options are important for compatibility, performance tuning, and controlling the connec- tion. The configuration options are set at the server, database, and connection level. Most of the options can be set from Management Studio, and all of them can be configured with code. Continuing with SQL Server administration tasks, the next chapter focuses on managing policies. 937 www.getcoolebook.com Nielsen c39.tex V4 - 07/21/2009 2:17pm Page 938 www.getcoolebook.com Nielsen c40.tex V4 - 07/21/2009 2:20pm Page 939 Policy-Based Management IN THIS CHAPTER Declarative management Exploring facet properties Defining policies Enforcing policies R ecently I was on a virtual panel with SQL Server MVPs Steve Wynkop and Chris Shaw (of SSWUG.org fame) discussing what’s new with SQL Server 2008. I said the top new developer feature is table-valued param- eters, and the top DBA feature is Policy-Based Management (affectionately called PBM). This surprised Chris because he expected me to focus on only developer features, and he wanted to say that PBM was the top new feature. Sorry to steal your thunder, Chris. But it’s true. For SQL Server operations, PBM has the potential to radically alter how DBAs do their job, advance the consistency and quality of the operations up a few levels, and significantly ease managing hundreds of servers. I’ll put it in print here: If you’re an operational DBA and you don’t get excited about PBM, then you should consider flipping burgers instead. (And as a DB dev type, I don’t usually get very excited about an admin feature.) So, with that introduction, what is PBM? Traditionally, applying and enforcing server and database settings and configura- tions across multiple SQL Servers has been a mash-up of log books, checklists, jobs, DDL triggers, scripts, and good ideas on the whiteboard that were never actually implemented. PBM changes all that by making policies declarative — in fact, during its early life, PBM was called Declarative Management Framework. SQL is a declarative language, meaning that SQL commands don’t state how the query should be solved. SQL describes the question, and the Query Optimizer figures out how to solve the query. 939 www.getcoolebook.com Nielsen c40.tex V4 - 07/21/2009 2:20pm Page 940 Part VI Enterprise Data Management Similarly, PBM abstracts the management intent, meaning the policies, from the procedural implemen- tation. As the DBA, you define what the system should be and then let SQL Server figure out how to achieve it. Policy checking can be automated, and the results logged. SQL Server 2008 focuses on automating policy checking for a single SQL Server instance. But users can build multi-server solutions quite easily using PowerShell scripts and agent jobs. What’s New with Policy-Based Management? O f course, everything is new with PBM — it’s a new feature — but there’s more to the story. In SQL Server 2008, PBM replaces the Surface Area Configuration (SAC) tool that SQL Server 2005 introduced. With SQL Server 2005, Microsoft installed SQL Server in a locked-down state — with a minimum exposed surface area configuration. Any setting that could be turned off was turned off. The SAC tool was a pretty slick and easy way to check the server settings and enable features. PBM is considerably more complicated than the old SAC tool. One of SQL Server’s strengths has always been the scalability of the experience — it’s usable by the occasional, accidental DBA as well as by the professional, experienced DBA. I contend that SAC was very useful for the web developers who also serve as the DBA 30 minutes a month. They’re never going to learn PBM, and probably never going to read this chapter, but the SAC tool was easy to find and easy to use. PBM is far superior to SAC in every way; SAC was just really easy to use. The demise of SAC aside, Policy-Based Management is brilliant. Without a doubt, PBM is the right direction for SQL Server management and it’s the right tool for the professional DBA today. It’s worth mentioning that there is more to PBM than meets the eye. PBM is actually a down-payment technology that Microsoft can build on. I expect to see great things being done in SQL 11 to leverage PBM. Defining Policies Policies may be defined interactively in Management Studio, loaded in from XML, or defined with either T-SQL code or APIs. There are three types of PBM objects. In a sense they function as three levels, with one policy built from conditions, which are built out of facets: ■ 74 Management facets, defined only by Microsoft, are collections of properties that represent a management dimension. For example, the table facet has 34 specific properties that can be checked about a table. Examples of common facets include logins, a server, a linked server, or an index. Inside each facet are anywhere from a handful to dozens of properties, which can be referred to by a condition. ■ Health conditions, defined by the DBA, based on one facet, are the desired states, or values, in terms of facet properties. 940 www.getcoolebook.com Nielsen c40.tex V4 - 07/21/2009 2:20pm Page 941 Policy-Based Management 40 ■ Policies, defined by the DBA, based on one health condition, declare how and upon what object (server, database, etc.) the health condition should be enforced. The UI for Policy-Based Management is in Management Studio’s Object Explorer under the Management node, as shown in Figure 40-1. Most of the PBM tasks are found in the PBM node context menus. Management facets A brilliant-cut diamond has 58 facets. Policy-Based Management has 74 management facets; fortunately, a condition can be built with only one facet. The easiest way to see all the facets is to open the Facets node under Management ➪ Policy Management, as shown in Figure 40-1. FIGURE 40-1 Policy-Based Management’s policies, conditions, and facets are found in Object Explorer under the Management node. In database design terminology, there’s a many-to-many relationship between SQL Server object types and properties. For example, database facet properties apply only to databases, but the name facet property (there’s only one property) can apply to 19 different types of SQL Server objects, ranging from ApplicationRoles to XmlSchemaCollections, including databases. 941 www.getcoolebook.com . AdventureWorks2008 SET MULTI_USER; Compatibility level In SQL Server, the database-compatibility level can be set to 80 (SQL Server 2000), 90 (SQL Server 2005), or 100 (SQL Server 2008) . When a. more to the story. In SQL Server 2008, PBM replaces the Surface Area Configuration (SAC) tool that SQL Server 2005 introduced. With SQL Server 2005, Microsoft installed SQL Server in a locked-down. and then let SQL Server figure out how to achieve it. Policy checking can be automated, and the results logged. SQL Server 2008 focuses on automating policy checking for a single SQL Server instance.