ptg 1514 CHAPTER 40 Managing Workloads with the Resource Governor ALTER RESOURCE GOVERNOR RECONFIGURE GO You can also move a workload group to another resource pool in SSMS using the Resource Governor Properties page. Click the Resource Pool name in the Resource Pools grid; then right-click on Workload Group in the Workload Groups grid and select Move To (see Figure 40.6). This brings up the Move Workload Group dialog, which lists the available resource pools the workload group can be moved to. Select the desired resource pool and click OK. Why move a workload group to a different resource pool? You might decide that a work- load group should be in a resource pool that has different configuration settings, or you might want to move workload groups out of a resource pool so that you can drop the resource pool. Deleting Workload Groups You can delete a workload group or resource pool by using SQL Server Management Studio or T-SQL. To drop a workload group in SSMS, follow these steps: 1. Expand the Management node in Object Explorer and expand the Resource Governor node to display the Resource Pools folder. 2. Expand the node of the resource pool where the workload group is defined to display the Workload Groups folder. FIGURE 40.6 Moving a workload group in SSMS. ptg 1515 Modifying Your Resource Governor Configuration 40 3. Expand the Workload Groups folder to list the workload groups. 4. Right-click the workload group you want to drop and select Delete. 5. In the Delete Object window, the Workload Group is listed in the Object to Be Deleted list. Click OK to confirm the deletion. To drop a workload group using T-SQL, use the DROP WORKLOAD GROUP command: DROP WORKLOAD GROUP OLTPWG1 ALTER RESOURCE GOVERNOR RECONFIGURE go You cannot drop a workload group if there are any active sessions assigned to it. If a work- load group contains active sessions, deleting the workload group or moving it to a differ- ent resource pool will fail when the ALTER RESOURCE GOVERNOR RECONFIGURE statement is called to apply the change. The following options provide a way to work around this problem: . Wait until all the sessions from the affected group have disconnected and then rerun the ALTER RESOURCE GOVERNOR RECONFIGURE statement. . Explicitly stop sessions in the affected group by using the KILL command and then rerun the ALTER RESOURCE GOVERNOR RECONFIGURE statement. . Restart SQL Server. When the restart process is complete, the deleted group will not be created, and a moved group will automatically use the new resource pool assignment. NOTE If an attempt to reconfigure Resource Governor fails after dropping a workload group because of active sessions and you change your mind about dropping the workload group, you can restore it by rerunning the CREATE WORKLOAD GROUP command for that workgroup. After re-creating the workload group, run the ALTER RESOURCE GROUP RECONFIGURE command again, and the workload group is restored. Deleting Resource Pools To drop a resource pool in SSMS, follow these steps: 1. Expand the Management node in Object Explorer and expand the Resource Governor node to display the Resource Pools folder. 2. Expand the Resource Pools folder to list the resource pools defined. 3. Right-click the resource pool you want to drop and select Delete. 4. In the Delete Object window, the resource pool is listed in the Object to Be Deleted list. Click OK to confirm the deletion. ptg 1516 CHAPTER 40 Managing Workloads with the Resource Governor To drop a workload group using T-SQL, use the DROP RESOURCE POOL command: DROP RESOURCE POOL OLTPPOOL ALTER RESOURCE GOVERNOR RECONFIGURE go You cannot drop a resource pool if any workload groups are still assigned to the resource pool. You need to drop the workload group or move it to another resource pool first. Modifying a Classification Function If you need to make a change to the classification function, it’s important to note that the function cannot be dropped or altered while it is marked as the classification function for the Resource Governor. Before you can modify or drop the classification function, you first need to disable Resource Governor. Alternatively, you can replace the classification func- tion with another by running the ALTER RESOURCE GOVERNOR command and passing it a different CLASSIFIER_FUNCTION name. You can also simply disable the current classifier function by executing the following command: ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = NULL); ALTER RESOURCE GOVERNOR RECONFIGURE; The sample classification function shown in Listing 40.1 uses a simple case expression to determine the workload group based on only two login IDs. If you have a more complex set of rules to apply or want to be able to make changes more dynamically than having to replace the classification function each time you need to make a change, you can define your classifier function to look up the workload group names from a database table, rather than hard-coding the workload group names and matching criteria into the function. Performance should not be greatly affected when accessing the table to look up the work- load group. The reason is that the table likely won’t be very large and should remain cached in the buffer pool because it’s being accessed repeatedly every time a connection is made to SQL Server. ptg 1517 Summary 40 Summary Resource Governor offers many potential benefits, primarily the capability to prioritize SQL Server resources for critical applications and users and preventing “runaway” or unexpected queries from adversely impacting SQL Server performance significantly. It fits in with Microsoft’s goal of providing predictable performance for your SQL Server applications. Resource Governor also offers some potential pitfalls, however. For example, a misconfig- ured Resource Governor can not only hurt a server’s overall performance, but can poten- tially lock up your server, requiring you to use the dedicated administrator connection to attach to the locked-up SQL Server to troubleshoot and fix the problem. Therefore, it is recommended that you implement Resource Governor only if you are an experienced DBA and have a good understanding of, and familiarity with, the workloads executed against your SQL Server databases. Even then, it’s imperative that you test your configuration on a test server before rolling it out into production. Also, after implementing a Resource Governor configuration, you should monitor your SQL Server performance to make sure the configuration has the desired effect. The next chapter, “A Performance and Tuning Methodology,” provides guidelines for monitoring and tuning the performance of your SQL Server environment. ptg This page intentionally left blank ptg CHAPTER 41 A Performance and Tuning Methodology IN THIS CHAPTER . The Full Architectural Landscape . Primary Performance and Tuning Handles . A Performance and Tuning Methodology . Performance and Tuning Design Guidelines . Tools of the Performance and Tuning Trade Yes, you can tune your SQL Server implementation to perform optimally for you. However, random jabs at bleed- ing arteries may stop immediate bleeding, but the patient will die before too long. Forgive the graphic analogy, but all too often, performance and tuning is crudely attempted with extremely serious oversights and very often extremely poor results. Usually, you can avoid this outcome if you follow basic, orderly steps when tuning your SQL Server platform and understand the complete SQL Server ecosys- tem. This chapter describes a repeatable performance and tuning methodology that has been refined over the past decade during hundreds of performance and tuning consulting engagements on SQL Server implementations running at some of the largest companies on the planet. Good performance really starts when you design it into your implementation from the beginning. Even the best- designed applications require fine-tuning over time. Unfortunately, dealing with performance is very often put off or not considered at all until it becomes a problem in production! As a part of introducing a formal performance and tuning approach, we describe the overall architectural landscape of most applications and how SQL Server sits within this envi- ronment. You should keep in mind that addressing perfor- mance and tuning of your SQL Server implementation is a layered exercise and all layers must be considered; all layers factor into your results. We also discuss an assortment of design considerations (guidelines) that you should incorpo- rate into your designs from the beginning. And lastly, we outline several tools of the trade when focusing on perfor- mance and tuning. Some are out-of-the-box from Microsoft; ptg 1520 CHAPTER 41 A Performance and Tuning Methodology Data Structures (DB, TBL, IDX) Files Application Layer Client/Browser Layer File Systems Volumes Operating Systems Encryption Message/Data Buses External Communication Layer (Internet, EDI, FTP, WS) Security Services Layer (WS, DS) Architecture Layers Web Tier Network Memory/RAM SQL Server Physical Disk/Sectors Partitions/Devices Physical Machine ( or Virtual Machine) FIGURE 41.1 The overall architectural landscape of a SQL Server implementation. others are from third-party providers that allow you to visualize and rapidly isolate your performance issues as they are happening. A number of other chapters in this book are dedicated to the actual performance tuning of a SQL Server instance, SQL tables, and SQL statements. This chapter provides you with a framework and ordered process to attack a SQL Server–based environment from top to bottom that will yield thorough and complete results. No more just stopping the bleeding artery. We want to cure the patient! The Full Architectural Landscape As mentioned previously, understanding all layers of your implementation is critical to performance and tuning of your SQL Server application. Even the smallest aspect, such as locking, could be at the heart of your poor performing system. You just don’t truly know until you have evaluated all layers and all interactions that come into play in your SQL Server application. Figure 41.1 provides an overall perspective of all the layers of the archi- tecture that you need to better understand and potentially tune. As you can see in Figure 41.1, your SQL Server environment sits at the heart of many different layers. They include the hardware (either physical or virtual footprint), memory, physical disks/devices, operating system, file systems, and database, to name a few. Quite often, a combined effort is needed between the infrastructure, application, database, and network teams to deliver the final, well-tuned SQL Server environment. If you can under- ptg 1521 Primary Performance and Tuning Handles 41 stand that you have not just a database problem or just an application design problem, you will likely be more successful at delivering “optimal” results when tuning your envi- ronment. You can treat Figure41.1 as a checklist that you make sure you cover when doing performance and tuning. Then, when you make a change in one layer, you can make sure you test the full impact throughout all the other layers. Often, when you solve one issue in one layer, other issues bubble up to the surface of another layer. Primary Performance and Tuning Handles Now, let’s peel the onion a little more into the core architecture of SQL Server itself. Figure 41.2 shows the primary components within a SQL Server instance. The major issues to worry about at the instance level are the caches that comprise the memory pool and the number of CPUs available for processing to SQL Server itself (shown as white boxes, not dark ones). Of course, the disk I/O subsystem and files have to be carefully evaluated and used effectively as well. All other darker boxed items such as the SQL Server kernel are not within your control. The rule of thumb here is to treat these instance-level resources as “scarce” resources and monitor the CPU and disk I/O for their saturation levels (never exceeding 80%) and memory for its hit ratio and capability to service the desired amount of concurrent work SQL Server Architecture Server Net-libs DLLs SQL Server Kernel (code) Open Data Services Stack Space Variable code BufferPool User Connection Structures System Data Structures Plan Cache Buffer Cache Other Servers Web-Based Clients Windows Clients Windows Clients Windows Clients CPU CPU . . . Disk/Files Log Cache FIGURE 41.2 SQL Server instance architecture (memory, CPU, I/O). ptg 1522 CHAPTER 41 A Performance and Tuning Methodology Cache Optimizer SQLOS Devices/Files Partitions Tables Materialized Views Indexes SQL Statements CPU (s) FIGURE 41.3 SQL Server handles available for performance tuning. at or better than the service-level requirements of your end users (even during peak usage times). Figure 41.3 shows a more readily recognizable combination of “handles” that are the major areas a human can adjust to achieve optimal performance. We’ve already mentioned CPU, cache/memory, and disk I/O; these and all the other handles listed in Figure 41.3 work together and must be considered together when doing performance and tuning. A change in a SQL statement affects what the optimizer (which makes decisions regarding how data is accessed in SQL Server) will do to satisfy the query. The correct index allows the query to get data the most effective way. The correct table design drastically affects updates, deletes, inserts, and reads. The number of CPUs available to SQL Server can invoke parallelism. What work is done in tempdb (and where tempdb is located) can improve performance by 1000%. The index and table level fill factor (free space), number of page splits, and page allocations being done within your databases can hurt you by 1000%. Hints to the optimizer can change the way execution is handled. And other issues such as materialized views, partitions, and file placement (at the disk subsys- tem level) directly contribute to the overall performance of every SQL execution. Even something as simple as locking (or deadlocks) and the consistent order of update opera- tions within transactions can make or break an entire SQL Server implementation. We explain a bit more of what to look for with the primary handles in the guideline section later. For most development or production support teams, tackling performance and tuning for SQL Server can truly be overwhelming. The next section describes an orderly performance and tuning methodology that most should be able to follow and use to yield great results. A Performance and Tuning Methodology A methodology is a process or procedure, for example, designed for repeatability that has been proven to work for a certain paradigm. In our case, it is a repeatable and thorough SQL Server–focused performance and tuning process. We generalized this focused process into a repeatable methodology and identified two possible paths that can be taken through it: one for a new SQL Server implementation that will have performance and tuning designed into it from the start and another for performance and tuning of an ptg 1523 A Performance and Tuning Methodology 41 Performance & Tuning Methodology Code & Test Implementation Deploy Development Life Cycle Phases Close Construct Design Initiate Isolate & Monitor New New Existing Existing System Test & Acceptance Identify & Design Prototype Assessment FIGURE 41.4 Generalized performance and tuning methodology for SQL Server. existing SQL Server implementation (one that needs to be scaled out or rescued—or in other words, “optimized”). Figure 41.4 illustrates this overall performance and tuning methodology within a tradi- tional waterfall development methodology context. But, as you will see, it is very iterative in nature and can be followed within any organization’s formal development methodology. Notice the two distinct paths labeled “New” and “Existing” indicated by the dashed arrowed lines. As mentioned earlier, one path is for new implementations, and the other is for existing implementations. The following sections describe each of these distinct paths through the methodology. Designing In Performance and Tuning from the Start If you are just starting to design and develop a new SQL Server–based implementation, it would be great to factor in all possible performance and tuning considerations from the beginning. In real life, this is rarely done primarily because much is unknown from a data access, number of users, and table design point of view. However, you are not precluded from designing in certain common performance and tuning considerations, nor are you precluded from incorporating a performance and tuning “prototyping” step in your methodology so that you have known and predictable results of what you are building “as you go” and not “at the end.” As you have no doubt experienced (or heard many times), changing something after it is built is more expensive than if you had considered it much . actual performance tuning of a SQL Server instance, SQL tables, and SQL statements. This chapter provides you with a framework and ordered process to attack a SQL Server based environment from. unexpected queries from adversely impacting SQL Server performance significantly. It fits in with Microsoft s goal of providing predictable performance for your SQL Server applications. Resource Governor. hit ratio and capability to service the desired amount of concurrent work SQL Server Architecture Server Net-libs DLLs SQL Server Kernel (code) Open Data Services Stack Space Variable code BufferPool User