Microsoft SQL Server 2008 R2 Unleashed- P152 pot

SQL Server Applications Operating System Extended Events Catalog Views Dynamic Management Views Viewing Metadata Viewing Session data XYZ TheMostLocks TheMostLocks SQL Events App Events

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 Administrationnode 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 Instancesnode 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

The performance data collected by the SQL Server Utility is stored in the utility

manage-ment data warehouse The UMDW is a database namedsysutility_mdwthat 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 probprob-lems 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_mdwdatabase 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

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

Operating System Extended Events

Catalog Views Dynamic Management Views

Viewing Metadata

Viewing Session data

XYZ

TheMostLocks

TheMostLocks SQL Events

App Events

OS events

EE Registered Packages

Events

Targets

Actions

Types

Predicates

Maps

FIGURE 39.18 SQL Server Extended Event framework

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:

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

package0package 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

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_typedata 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

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_compareand

pred_source The pred_comparepredicates are comparison functions, such as >=

To view a list of the pred_comparepredicates 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_int64andgreater_than_float64)

Thepred_sourcepredicates are extended attributes that can be used within predicates to

filter on attributes not carried by the event’s own schema (such as transaction_idor

database_id) The available pred_sourcepredicates 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

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_objectscatalog 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_keysandmap_valuesfor 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.sqlon the CD for this book

For catalog views, the following short list shows the SELECTstatements 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;

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’;

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,ALTERandDROP

EVENTstatements These Data Definition Language (DDL) statements completely control

the creation and activation of Extended Events All the SSEE objects are created in the

msdbdatabase Only those users with CONTROL SERVERpermissions can create, alter, or

drop SSEE objects To use the catalog and dynamic management views, you need at least

VIEW SERVER STATEpermission

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 namedTheMostLocks.sql Locate this

SQL script now; then start SSMS and open a new query connection with theCREATE EVENT

SESSIONscript in it Figure 39.19 shows a current connection to SQL Server with

TheMostLocks.sqlfile open and the event session namedTheMostLocksready to be created

As you examine theCREATE EVENT SESSIONT-SQL code, notice that two events are being

created with theADD EVENTstatements One will gather async IO requests, and the other

will retrieve SQL Server–acquired locks on an object’s information Also, notice theTARGET

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

TheCREATE EVENT SESSIONT-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

FIGURE 39.19 SSMS creating an event session named TheMostLocks.

Alternatively, you can direct the TARGEToutput 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

SESSIONcommand, 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 theCREATE EVENT

SESSIONT-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);