Microsoft SQL Server 2008 R2 Unleashed- P152 pot

ptg 1454 CHAPTER 39 Monitoring SQL Server Performance . CPU utilized by the computer running the instance This performance data is broken down based on utilization thresholds and displayed in the dashboard window based on whether the specific metric is overutilized, underutilized, or well utilized. This breakdown is created for each managed instance as well as data-tier applications, a discussion of which is beyond the scope of this chapter. The key to making this performance information valuable for you is defining the thresholds for each one of these metrics. Overutilization or underutilization, to some degree, is a matter of personal preference. A CPU that is at 70% utilization may be considered overuti- lized for some but not for others. The thresholds for these metrics can be defined using the Utility Administration node in the Utility Explorer. Figure 39.16 shows the policy screen where the global policies for the managed instances can be defined. These policies are essen- tially the thresholds for each of the four performance categories displayed in the SQL Server Utility dashboard. The real power of the SQL Server Utility lies in its capability to collect the kind of perfor- mance data that we have been talking about for other SQL Server instances. This multi- server management capability is easy to implement and simply requires that you enroll the other SQL Server instances with a UCP. As mentioned earlier, you can do this by using the third link on the Utility Configuration Steps page. You can also right-click on the Managed Instances node in the Utility Explorer and select Enroll Instance. The Enroll Instance Wizard guides you through the enrollment steps. Upon completion of the wizard, the new instance appears in the Utility Explorer Content tab, as shown in Figure 39.17. FIGURE 39.16 Global policies for managed instances. ptg 1455 Performance Monitoring Tools 39 The performance data collected by the SQL Server Utility is stored in the utility manage- ment data warehouse. The UMDW is a database named sysutility_mdw that is automati- cally created on the UCP instance when the UCP is created. It can be viewed in the list of databases in Object Explorer. By default, each managed instance enrolled in the UCP sends configuration and performance data to the UCP database every 15 minutes. The frequency of data collections provides for a comprehensive set of historical information. This data can be viewed in the Utility Explorer across different intervals, including daily, weekly, monthly, and yearly views. These views provide a sound foundation for identifying prob- lems or identifying trends that can lead to problems in the enrolled SQL Server instances. CAUTION The frequency of collection of data in the UMDW database can also lead to a large database. Make sure that you monitor the size of the sysutility_mdw database over time. You can manage the data retention period through the SQL Server Utility Explorer. Click on Utility Administration and then select the Data Warehouse tab. You can drag the slider to change the retention period from the default value of one year to one, three, or six months if the UMDW database is becoming too large. SQL Server Extended Events SQL Server Extended Events (SSEE) are truly the future event-oriented framework that all SQL Server–based systems and applications will be using going forward. Extended Events are highly flexible to define, are able to capture almost any action or event within your FIGURE 39.17 Managed instances. ptg 1456 CHAPTER 39 Monitoring SQL Server Performance reach, are lightweight in their implementation, and are flexible enough to create simple or complex monitoring across multiple systems and environments. In other words, SSEE is a unified approach to handling events across SQL Server systems, while at the same time enabling users to isolate specific events for troubleshooting purposes. The Extended Events framework can be utilized to help SQL Server implementations in many ways. Some approaches might include the following: . Isolating excessive CPU utilization . Looking for deadlocks/locking . Locating long-running SQL queries One of the key features of Extended Events is that events are not bound to a general set of output columns like SQL Trace events. Instead, each Extended Event publishes its data using its own unique schema. This makes the system as flexible as possible for what can be returned from Extended Events. The Extended Event system was engineered from the ground up with performance in mind, so events should have minimal impact on system performance. SSEE currently is T-SQL based (there is no GUI tool available for SSEE yet). However, it has several predefined SQL Server catalog and dynamic management views and also is inte- grated with the Event Tracing for Windows (ETW) tools. Figure 39.18 shows the overall makeup of the new SSEE framework. SQL Server Applications Event Tracing for Windows (ETW) Operating System Extended Events Catalog Views Dynamic Management Views Viewing Metadata Viewing Session data XYZ EE Session TheMostLocks EE Session TheMostLocks SQL Events App Events OS events Network EE Registered Packages Events Targets Actions Types Predicates Maps FIGURE 39.18 SQL Server Extended Event framework. ptg 1457 Performance Monitoring Tools 39 There is basically an Extended Event engine that runs within SQL Server and drives the event gathering for active sessions. This capability essentially provides a standard and powerful way to dynamically monitor active processes, while at the same time having minimal effect on those processes. Looking a little closer at Figure 39.18, you can see the concept of Extended Events pack- ages (a package), which contain one or more Extended Events objects. The Extended Events engine allows any event to be bound to any target. In other words, events can push their results to any location for consumption (like the ETW) or can be exposed via Views in SMSS, and so on. Predicates are used to filter what events (that are firing) get pushed to the target (consumer). This capability greatly adds to the flexibility of the Extended Events infrastructure. The next sections examine the main elements of Extended Events. Packages A package is a container for SQL Server Extended Events objects. It is the basic unit within which all other Extended Event objects ship. Four kinds of Extended Events packages are included in SQL Server 2008: . package0—Extended Events system objects. This is the default package. . sqlserver—SQL Server–related objects. . sqlos—SQL Server Operating System (SQLOS)–related objects. . SecAudit—Security Audit events. You can see these four packages by running the following query: select * from sys.dm_xe_packages Packages can interact with one another to avoid having to provide the same code in multiple contexts. In other words, if one package exposes an action that can be bound to an event, any number of other events in other packages can also use it. For example, the package0 package that ships with SQL Server 2008 contains objects designed to be used by all the other packages. A package can contain any or all of the following objects: . Events . Targets . Actions . Types . Predicates . Maps ptg 1458 CHAPTER 39 Monitoring SQL Server Performance Events Events are monitoring points of interest in the execution path of a program, such as SQL Server. An event firing indicates that the point of interest was reached and provides state information from the time the event was fired. Events can be used solely for tracing purposes or for triggering actions. These actions can either be synchronous or asynchro- nous. There can be one or more events in an event session package. To see a list of the events provided with SQL Server, you can run the following query: select * from sys.dm_xe_objects where object_type = ‘event’ As stated previously, events have a schema that defines their contents. This schema is composed of event columns with well-defined types. You can view the event schema by querying sys.dm_xe_object_columns, as in the following example: select name, column_id, type_name, column_type from sys.dm_xe_object_columns where object_name = ‘page_split’ go name column_id type_name column_type ID 0 uint16 readonly UUID 1 guid_ptr readonly VERSION 2 uint8 readonly CHANNEL 3 etw_channel readonly KEYWORD 4 keyword_map readonly file_id 0 uint16 data page_id 1 uint32 data Columns marked with column_type data are the values that will be filled in at runtime. The read-only columns provide metadata about the event. Notice that one of the columns in the output is the channel for the event; this indicates the category of the event. The available event channels in SQL Server 2008 are as follows: . Admin—Admin events are primarily targeted to the end users, administrators, and support. They include events such as error reports and deprecation announcements. . Operational—Operational events are used for analyzing and diagnosing a problem or occurrence. They can be used to trigger tools or tasks based on the problem or occurrence. An example of an operational event is one in which a database is attached or detached. . Analytic—Analytic events are those that fire on a regular basis, often in high volume. They describe program operation such as lock acquisition and SQL Server statement execution. They are typically aggregated to support performance analysis. . Debug—Debug events are used solely by DBAs and support engineers to help diag- nose and solve engine-related problems. ptg 1459 Performance Monitoring Tools 39 Targets Targets are event session consumers and indicate where output is located, such as a file, ring buffer, or a bucket with aggregation. Targets can process events synchronously or asynchronously. Extended Events provides several predefined targets you can use as appro- priate for directing event output. An example of one of our favorites is provided later in this chapter. You can find a list of available targets in SQL Server 2008 by running the following query: select * from sys.dm_xe_objects where object_type =’target’ Predicates Predicates are a set of logical evaluation rules for events when they are processed that serve to filter events. They help reduce the volume of captured data and tailor down the output for analysis. In effect, they enable the Extended Events user to selectively capture event data based on specific criteria. There are two different types of predicates in SQL Server 2008: pred_compare and pred_source. The pred_compare predicates are comparison functions, such as >=. To view a list of the pred_compare predicates available in SQL Server 2008, you can run the following query: select * from sys.dm_xe_objects where object_type = ‘pred_compare’ If you run this query, you’ll notice that there are a number of similar pred_compare predi- cates with the same comparison function but for different data types (for example, greater_than_int64 and greater_than_float64). The pred_source predicates are extended attributes that can be used within predicates to filter on attributes not carried by the event’s own schema (such as transaction_id or database_id). The available pred_source predicates can be listed by using the following query: select * from sys.dm_xe_objects where object_type = ‘pred_source’ Actions Actions are programmatic responses or series of responses to an event. Actions are bound to an event, and each event may have a unique set of actions. Actions are performed synchronously in association with bound events. They can be used to accomplish certain tasks or simply provide more information relevant to the events. There are many types of actions, and they have a wide range of capabilities: . Receive a stack dump and inspect data. . Store state information in a variable. . Bring event data from multiple places together. ptg 1460 CHAPTER 39 Monitoring SQL Server Performance . Append new data to existing event data. To view a list of the actions available in SQL Server 2008, you can run the following query: select * from sys.dm_xe_objects where object_type = ‘action’ Types and Maps Two kinds of data types can be defined in an event: scalar types and maps. Scalar types are single values, like integers. Maps are tables that map internal object values to static, prede- fined, user-friendly descriptions. They help you see what the internal values stand for (making them human consumable) but allow the event to more efficiently store the integer map value rather than the actual text. Like all the other elements discussed thus far, types and maps can also be viewed by querying the sys.dm_xe_objects catalog view: select * from sys.dm_xe_objects where object_type in (‘type’, ‘map’) Although types are relatively self-explanatory, maps require a lookup to expose the associ- ated human-readable text when appropriate. The map values are stored in the DMV called sys.dm_xe_map_values. To list the map_keys and map_values for lock types, for example, you can run the following query: select * from sys.dm_xe_map_values where name = ‘lock_mode’ Extended Events Catalog Views and DMVs To get metadata information about what events, actions, fields, and targets have been defined, you can use the catalog views supplied with SQL Server. NOTE Examples of the queries presented in this section are provided in the file named Extended Events Views.sql on the CD for this book. For catalog views, the following short list shows the SELECT statements and their purposes (that use the predefined SSEE catalog views). To see event sessions, you use the following: SELECT * FROM sys.server_event_sessions; To see actions on each event (of an event session), run this: SELECT * FROM sys.server_event_session_actions; To see events in an event session, run the following: SELECT * FROM sys.server_event_session_events; ptg 1461 Performance Monitoring Tools 39 To see columns of events and targets, use this statement: SELECT * FROM sys.server_event_session_fields; And, to see event targets for an event session, you use the following: SELECT * FROM sys.server_event_session_targets; You use the dynamic management views to obtain session metadata and session data itself (as it is being gathered during execution). The metadata is obtained from the catalog views, and the session data is created when you start and run an event session. To see session dispatcher pools, you use the following statement: SELECT * FROM sys.dm_os_dispatcher_pools; To see event package objects, use this: SELECT * FROM sys.dm_xe_objects; To see the schema for all objects, run this statement: SELECT * FROM sys.dm_xe_object_columns; To see the registered packages in the Extended Events engine, use this: SELECT * FROM sys.dm_xe_packages; To see the active Extended Events sessions, run the following: SELECT * FROM sys.dm_xe_sessions; To see session targets, run this statement: SELECT * FROM sys.dm_xe_session_targets; To see session events, use this: SELECT * FROM sys.dm_xe_session_events; To see event session actions, use this: SELECT * FROM sys.dm_xe_session_event_actions; To see the mapping of internal keys to readable text, use the following: SELECT * FROM sys.dm_xe_map_values; Specific variations might be as follows: SELECT map_value Keyword from sys.dm_xe_map_values where name = ‘keyword_map’; ptg 1462 CHAPTER 39 Monitoring SQL Server Performance SELECT map_key, map_value from sys.dm_xe_map_values where name = ‘lock_mode’; And finally, to see the configuration values for objects bound to a session, you use the following: SELECT * FROM sys.dm_xe_session_object_columns; Creating an Extended Events Session Microsoft uses the same common paradigm ( CREATE, ALTER, DROP) for most of its newer capabilities, such as Create Audit (for SQL Auditing), Create Endpoint (for database mirroring), and many others. SSEE follows the same path in that you basically create an Extended Events session, alter it to start the monitoring session, alter it again to stop the monitoring, and then leverage the catalog and dynamic management views before, during, and after the session monitoring to view the event information. Creating events (event sessions) is fairly easy to do using the CREATE, ALTER and DROP EVENT statements. These Data Definition Language (DDL) statements completely control the creation and activation of Extended Events. All the SSEE objects are created in the msdb database. Only those users with CONTROL SERVER permissions can create, alter, or drop SSEE objects. To use the catalog and dynamic management views, you need at least VIEW SERVER STATE permission. In this section, you quickly set up and define a new Extended Events session object that includes operating system IO requests and SQL Server lock-acquired counts. The purpose is to isolate the database objects (tables) that are being hit hardest with locks to better understand the behavior of the database design. Included on the CD for this book is a SQL script file named TheMostLocks.sql. Locate this SQL script now; then start SSMS and open a new query connection with the CREATE EVENT SESSION script in it. Figure 39.19 shows a current connection to SQL Server with TheMostLocks.sql file open and the event session named TheMostLocks ready to be created. As you examine the CREATE EVENT SESSION T-SQL code, notice that two events are being created with the ADD EVENT statements. One will gather async IO requests, and the other will retrieve SQL Server–acquired locks on an object’s information. Also, notice the TARGET statement, which uses a predefined target location that allows you to retrieve the results within SQL Server during execution and that filters on showing only the lock’s acquired information. The CREATE EVENT SESSION T-SQL code is as follows: IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name=’TheMostLocks’) DROP EVENT session TheMostLocks ON SERVER; CREATE EVENT SESSION TheMostLocks ON SERVER ptg 1463 Performance Monitoring Tools 39 FIGURE 39.19 SSMS creating an event session named TheMostLocks. Alternatively, you can direct the TARGET output to a file by using the following TARGET statement, for example: ADD TARGET package0.etw_classic_sync_target (SET default_etw_session_logfile_path = N’C:\TEMP\EESessionFile.etl’ ) You could then use the resulting file with the ETW to assemble this and other events from other portions of your environment. After the event session is created, you are able to start it by using the ALTER EVENT SESSION command, generate some activity on your server that will be captured by the event session, view the dynamic results during the execution of the activity, and then stop the event session. Go ahead and create the event session as it is listed now. Simply highlight the CREATE EVENT SESSION T-SQL statements shown previously and execute this code from SSMS. When it is complete, you are ready to start the event session by using the following command: START EVENT SESSION ALTER EVENT SESSION TheMostLocks ON SERVER STATE=start; ADD EVENT sqlos.async_io_requested, ADD EVENT sqlserver.lock_acquired ADD TARGET package0.synchronous_bucketizer ( SET filtering_event_name=’sqlserver.lock_acquired’, source_type=0, source=’resource_0’) WITH (MAX_MEMORY=4MB, MAX_EVENT_SIZE=4MB); . 2008: . package0—Extended Events system objects. This is the default package. . sqlserver SQL Server related objects. . sqlos SQL Server Operating System (SQLOS)–related objects. . SecAudit—Security Audit events. You. UMDW database is becoming too large. SQL Server Extended Events SQL Server Extended Events (SSEE) are truly the future event-oriented framework that all SQL Server based systems and applications. the SQL Server Utility dashboard. The real power of the SQL Server Utility lies in its capability to collect the kind of perfor- mance data that we have been talking about for other SQL Server