ptg 684 CHAPTER 21 SQL Server Clustering What has happened is that the application can no longer connect to the failed SQL Server (because you turned off CLUSTER1), and it is still in the middle of failing over to CLUSTER2 in the two-node cluster. A failover occurs in a short amount of time; the actual amount of time varies, depending on the power and speed of the servers implemented and the number of in-flight transac- tions that need to be rolled back or forward at the time of the failure. (A complete SQL failover often occurs in about 15 to 45 seconds. This is very minor and well within most service-level agreements and high-availability goals.) You then simply click the Retrieve button again in the Connection Test Program, and you are talking to SQL Server again, but now to CLUSTER2. As you can see in Figure 21.27, the data connection has returned the customer data, SHOWDATETIME has been updated, and SERVERNAME still shows the same virtual SQL Server name that the application needs to connect to, but the SPID has changed from 55 to 52. This is due to the new connection of the Connection Test Program to the newly owned (failed-over) SQL Server machine. The Connection Test Program has simply connected to the newly started SQL Server instance on CLUSTER2. The unhandled exception (error) goes away, and the end user never knows a complete failover occurred; the user simply keeps processing as usual. NOTE You could program better error handling that would not show the “unhandled excep- tion” error. You might want to display a simple error message, such as “database momentarily unavailable—please try again,” which would be much more user friendly. Potential Problems to Watch Out for with SQL Server Clustering Many potential problems can arise during setup and configuration of SQL Server Clustering. Following are some items you should watch out for: . SQL Server service accounts and passwords should be kept the same on all nodes, or a node will not be able to restart a SQL Server service. You can use administrator or FIGURE 21.27 Executing the Connection Test Program again against the failed-over cluster node. Download from www.wowebook.com ptg 685 Summary 21 a designated account (for example, Cluster or ClusterAdmin) that has administrator rights within the domain and on each server. . Drive letters for the cluster disks must be the same on all nodes (servers). Otherwise, you might not be able to access a clustered disk. . You might have to create an alternative method to connect to SQL Server if the network name is offline and you cannot connect using TCP/IP. You can use named pipes, specified as \\.\pipe\$$\SQLA\sql\query. . It is likely that you will run into trouble getting MSCS to install due to hardware incompatibility. Be sure to check Microsoft’s Hardware Compatibility List before you venture into this installation. Summary Building out your company’s infrastructure with clustering technology at the heart is a huge step toward achieving five-nines reliability. If you do this, every application, system component, or database you deploy on this architecture has that added element of resilience. And, in many cases, the application or system component changes needed to take advantage of these clustering technologies are completely transparent. Utilizing a combination of NLB and MSCS allows you not only to fail over applications but to scale for increasing network capacity. The two-node, active/passive node is one of the most common SQL Server Clustering config- urations used. As you become more familiar with SQL Server Clustering and your high-avail- ability requirements get closer to five-nines), you might need to put in place other, more advanced configurations, such as four-node SQL Server clusters and/or datacenter-class clus- ters (of up to eight-node SQL Server clusters and active/active variations). If you follow the basic guidelines of disk configurations and database allocations across these disk configura- tions, as described in this chapter, you can guarantee a certain level of stability, performance, and scalability. SQL Server Clustering is one of the best, most cost-effective solutions, and it is literally “out of the box” with SQL Server and the Windows family of servers. Remember that SQL Server 2008 supports other concepts related to high availability, such as data replication, log shipping (soon to be deprecated), and database mirroring. You might use these solutions rather than SQL Server Clustering, depending on your requirements. Clustering is a very complex subject. The information contained in this chapter is suffi- cient to start you in this area, but for a much more complete and thorough understanding of how to assess your high-availability needs, to evaluate what you should build for high availability, and to implement a high-availability platform that uses MSCS and SQL Server Clustering, you should find a copy of Microsoft SQL Server High Availability by Paul Bertucci (Sams Publishing). This book is loaded with full explanations, a formal approach to achieving five-nines reliability, and numerous live examples. Chapter 22, “Administering Policy-Based Management,” explains how to affectively administer servers using the Declarative Management Framework. Download from www.wowebook.com ptg This page intentionally left blank Download from www.wowebook.com ptg CHAPTER 22 Administering Policy- Based Management IN THIS CHAPTER . Introduction to Policy-Based Management . Policy-Based Management Concepts . Implementing Policy-Based Management . Sample Templates and Real- World Examples . Policy-Based Management Best Practices Policy-Based Management is one of the new management features introduced in SQL Server 2008. Policy-Based Management enables an organization to define policies to manage one or more SQL Server instances, databases, or objects within the enterprise. In addition, policies can be evaluated against target systems to ensure that the standard configuration settings are not out of compliance. Policy- Based Management was developed in response to the following industry trends: . Increasing amounts of data being stored . Data center consolidation and virtualization . Growing product capabilities . Proliferation of SQL Server systems within the enterprise . Need for a way to manage SQL Server settings from a holistic perspective . Regulatory compliance demanding secure and stan- dardized settings Introduction to Policy-Based Management A data explosion has been occurring over the past several years. In a 2006 study, International Data Corporation (IDC; http://www.idc.com) reported that 5 exabytes of digital media (5 billion gigabytes) were stored in 2003, and in 2006 this had ballooned to 161 exabytes. Not only is more data Download from www.wowebook.com ptg 688 CHAPTER 22 Administering Policy-Based Management being stored, but users are accessing more data than before. Part of this data growth is a result of the need for business intelligence (BI) systems to deliver actionable insights becoming more critical in the enterprise. Obtaining these insights requires large data volumes for trending and forecasting. As a result, data warehouses are becoming more crit- ical in every enterprise. This data explosion frequently results in a proliferation of SQL Servers. Essentially, DBAs are being required to do more, frequently with less. In addition, the increasing complexities of the SQL Server product set are forcing DBAs to focus on effi- cient, scalable management and standardization. Due to the large numbers of SQL Servers involved, management by automation becomes critical as well to lessen the administrative burden. Monitoring also becomes more important to provide proactive support. A well-managed SQL Server enterprise that follows best practices offers the following advantages: . Standardization—Every SQL Server will have a common disk layout and settings, as well as consistent naming standards. As a result, DBAs moving from one SQL Server to another will not be surprised by different disk layouts or unusual settings that could account for a performance problem. . Best practices—Microsoft internal studies have shown that 80% of the support calls to their Customer Service and Support (CSS) could have been avoided if the customer had been following best practices. Best practices not only offer perfor- mance advantages but also lead to fewer failure events caused by poorly configured SQL Servers, and security breaches due to SQL Servers that have not been hardened (security holes not locked down). . Ease of deployment—A well-managed data center will have automated procedures for building SQL Servers (that is, unattended installations using configuration files) that require less time to build and minimal administrative interaction, resulting in fewer mistakes in a build and a reduction in administrative tasks. . Regulatory compliance—By maintaining controlled and standardized settings, organizations can easily adhere to the demanding requirements of regulations such as Sarbanes-Oxley, the Health Insurance Portability and Accountability Act (HIPAA), and Payment Card Industry (PCI) standards. The intent of Policy-Based Management is to provide a management framework that allows DBAs to automate management in their enterprise according to their own set of predefined standards. By implementing Policy-Based Management within a SQL Server infrastructure, organizations can reap the following benefits: total cost of ownership asso- ciated with managing SQL Server systems will be reduced, configuration changes to the SQL Server system can be monitored, unwanted system configuration changes can be prevented, and policies will ensure compliance. The stated goals of Policy-Based Management fall into three categories: . Management by intent—Allows DBAs to enforce standards and best practices from the start rather than in response to a performance problem or failure event Download from www.wowebook.com ptg 689 Policy-Based Management Concepts . Intelligent monitoring—Allows DBAs to detect changes that have been made to their SQL Server environments that deviate from the desired configuration . Virtualized management—Provides a scalable framework that allows for manage- ment across the enterprise Microsoft SQL Server 2008 and SQL Server 2008 R2 also ship with several predefined poli- cies. These policies are not automatically imported into a default installation of SQL Server 2008. However, you can manually import them into SQL Server and use them as is or as a foundation for defining your own similar policies. These sample policies can be found in C:\Program Files\Microsoft SQL Server\100\Tools\Policies\DatabaseEngine\1033. Note that there are also policies for Reporting Services and Analysis Services, which can be found in the ReportingServices and AnalysisServices subdirectories of the Policies directory. Also note that Policy-Based Management can be used to manage SQL 2005 and 2000 servers. NOTE Microsoft has a blog focusing on Policy-Based Management (http://blogs.msdn.com/ sqlpbm/) where it publishes scripts that can be used to enforce Microsoft best prac- tices for SQL Server, as well as tips, tricks, and tutorials for using Policy-Based Management. Policy-Based Management Concepts Before we start learning about enforcing Policy-Based Management, there are a few key concepts DBAs must understand. These concepts include . Facets . Conditions . Policies . Categories . Targets . Execution mode . Central Management Servers Facets A facet is a logical grouping of predefined SQL Server 2008 configuration settings. When a facet is coupled with a condition, a policy is formed and can be applied to one or more SQL Server instances and systems. Common facets include Surface Area Configuration, Server Audit, Database File, and Databases. Table 22.1 illustrates the complete list of prede- fined facets that can be selected, along with an indication of how each facet can be auto- mated. Check On Schedule uses a SQL Server Agent job to evaluate a policy. Check On 22 Download from www.wowebook.com ptg 690 CHAPTER 22 Administering Policy-Based Management TABLE 22.1 Facets for Policy-Based Management Facet Name Check on Change: Prevent Check on Change: Log Check on Schedule Application Role X X X Asymmetric Key X X X Audit X Backup Device X Broker Priority X Broker Service X Certificate X Credential X Cryptographic Provider X Data File X Database X Database Audit Specification X Database DDL Trigger X Database Maintenance X Database Option X X Database Performance X Database Role X X X Database Security X Default X Endpoint X X X File Group X Full Text Catalog X Full Text Index X Full Text Stop List X Index X Change uses event notification to evaluate based on when changes occur. Facets are included with SQL Server 2008 and cannot be modified. Download from www.wowebook.com ptg 691 Policy-Based Management Concepts TABLE 22.1 Facets for Policy-Based Management Facet Name Check on Change: Prevent Check on Change: Log Check on Schedule Linked Server X Log File X Login X Login Options X X X Message Type X Multipart Name X X X Name X Partition Function X Partition Scheme X Plan Guide X Remote Service Binding X Resource Governor X Resource Pool X X X Rule X Schema X X X Server X Server Audit X Server Audit Specification X Server Configuration X X Server DDL Trigger X Server Information X Server Performance X Server Security X Server Settings X Server Setup X Service Contract X Service Queue X 22 Download from www.wowebook.com ptg 692 CHAPTER 22 Administering Policy-Based Management TABLE 22.1 Facets for Policy-Based Management Facet Name Check on Change: Prevent Check on Change: Log Check on Schedule Service Route X Statistic X Stored Procedure X X X Surface Area X X Surface Area for AS Surface Area for RS Symmetric Key X Synonym X Table X Table Options X X X Trigger X User X User Defined Aggregate X User Defined Data Type X User Defined Function X X X User Defined Table Type X User Defined Type X User Options X X X View X View Options X X X Workload Group X X X Xml Schema Collection X The complete list of facets can be viewed in SQL Server 2008 Management Studio by expanding the Management folder, the Policy-Based Management node, and then the Facets folder. Alternatively, to view facets applied to a specific database, you can right- click the database and select Facets. Download from www.wowebook.com ptg 693 Policy-Based Management Concepts 22 NOTE Currently, there are 74 facets available for use. Going forward, Microsoft will undoubt- edly create more facets, which will be included with upcoming service packs. Conditions A condition is a Boolean expression that dictates an outcome or desired state of a specific management condition, also known as a facet. Condition settings are based on properties, comparative operators, and values such as String, equal, not equal, LIKE, NOT LIKE, IN,or NOT IN. For example, a check condition could verify that data and log files reside on sepa- rate drives, that the state of the database recovery model is set to Full Recovery, that data- base file sizes are not larger than a predefined value, and that database mail is disabled. Policies A policy is a standard for a single setting of an object. It ultimately acts as a verification mechanism of one or more conditions of the required state of SQL Server targets. Typical scenarios for creating policies include imposing Surface Area Configuration settings, enforcing naming conventions on database objects, enforcing database and transaction log placement, and controlling recovery models. As mentioned earlier, a tremendous number of policies can be created against SQL Server 2008 systems. Surface Area Configurations are a very common policy, especially because the SQL Server 2005 Surface Area Configuration tool has been deprecated in SQL Server 2008. NOTE A policy can contain only one condition and can be either enabled or disabled. Categories Microsoft recognized that although you may want to implement a set of rigid standards for your internal SQL Server development or deployments, your enterprise may have to host third-party software that does not follow your standards. Although your internally developed user databases will subscribe to your own policies, the third-party user applica- tions will subscribe to their own categories. To provide flexibility, you can select which policies you want a table, database, or server to subscribe to and group them into groups called categories, and then have a database subscribe to a category and unsubscribe from a group of other policies if necessary. A policy can belong to only one policy category. Targets A target is one or more SQL Server instances, databases, or database objects that you want to apply your categories or policies to. Targets can be only SQL Server 2008 R2, 2008, 2005, or 2000 systems. All targets in a server instance form a target hierarchy. A target set is the set of targets that results from applying a set of target filters to the target hierar- chy—for example, all the tables in a database contained in a specific schema. Download from www.wowebook.com . X Schema X X X Server X Server Audit X Server Audit Specification X Server Configuration X X Server DDL Trigger X Server Information X Server Performance X Server Security X Server Settings X Server. enterprise Microsoft SQL Server 2008 and SQL Server 2008 R2 also ship with several predefined poli- cies. These policies are not automatically imported into a default installation of SQL Server 2008. However,. scalability. SQL Server Clustering is one of the best, most cost-effective solutions, and it is literally “out of the box” with SQL Server and the Windows family of servers. Remember that SQL Server 2008