Module 9

Extended Events
Introduction

Monitoring the query performance is one of the important diagnosis methods

to uncover poorly performing queries. However, sometimes this can be a bit of
struggling activity. Therefore, we have to use proper tools and methods to
monitor and analyze the query performance metrics. In order to monitor the
query performance, we can use the following tools:
• Query Store
• Dynamic Management Views and Functions (DMV)
• Extended Events
• Performance Monitor
• Activity Monitor
• 3rd party SQL Server Monitoring tools
• SQL Server Management Studio (SSMS) reports
What is SQL Server extended events?

SQL Server Extended Events is a performance monitoring tool that helps to collect and
monitor the database engine actions to diagnose problems in SQL Server. Microsoft has
introduced the extended events with the SQL Server 2008 and then decided to retire
the SQL profiler. Behind taking such a decision, there were some disadvantages of SQL
profiler. The main problem of the profiler was related to performance because it
consumes many system resources, and this situation was affecting the database
performance negatively. SQL Server extended events do not impact the performance of
the SQL Server as the profiler does and it also offers numerous events that help to
troubleshoot the query performance and other problems. Such as to resolve the
deadlock problems, it can be the first option.
What is SQL Server extended events?

One of the common complaining issues of SQL Server is long-running queries. For this
reason, as a first step, we need to detect long-running queries to troubleshoot these
queries. To define a query as problematic in terms of the runtime of a query, a certain
threshold value must be determined for the relevant database because the database
environment waiting tolerance can change. Some systems cannot tolerate microsecond
wait, while some systems have higher thresholds for long wait times. As we stated, we
can use different tools to find out the poorly performing queries. However, using
extended events can be one of the effective methods to diagnose these queries in our
database engine. At this point, the disorienting problem will be which event to use
because SQL Server offers numerous events.
What is SQL Server extended events?

The sql_statement_completed event captures all queries which are executed against in
the database and it involves the following metrics:
• CPU time
• Duration of the query execution
• Number of the logical reads
• Number of the physical reads
• SQL text and statement
• Number of the writes
• Client hostname
• Client application name
Create an extended event session to identify the long-running queries
Create an extended event session to identify the long-running queries

On the menu, we click the New Session… option to create a new extended event
session, and then the New Session window will appear. In this window, we give a name
to our extended event session and check the following options:
• Start the event session at server startup
• Start the event session immediately after session creation.
These two options allow starting the extended event session automatically when the
database service is started and also after the creation of the session it automatically
begins to collect data.
Create an extended event session to identify the long-running queries
Create an extended event session to identify the long-running queries

After giving a name to the session then we jump into the Events tab. Events are the
objects that are triggered when a specific action occurs. On this screen, we can find all
events and can filter the sql_statement_completed event. After finding the
sql_statement_completed event, we send out it to the Selected events list through the
right arrow button.
Create an extended event session to identify the long-running queries
Create an extended event session to identify the long-running queries

We click the Configure button to select the global event fields. Event fields are the
elements of the events that give information about the specific part of the events. Such
as, to find the application name that fired the event we need to choose the client app
name field. We select the client app name and client hostname on the Global Fields
(Action) list.
Create an extended event session to identify the long-running queries
Create an extended event session to identify the long-running queries
Create an extended event session to identify the long-running queries
Create an extended event session to identify the long-running queries

On the Data Storage tab, we will choose where the SQL Server extended events will
store the collected data. We select the event file to write the collected data into
an XEL file. After selecting the event_file type, we need to define the file location and the
maximum size of the file. When the Enable file rollover option is checked, after the
extended event XEL file reaches this maximum file size limit a new XEL file is created with
the same filename but appends a sequence number to the end of the file name.
Create an extended event session to identify the long-running queries
Create an extended event session to identify the long-running queries

On the Advanced tab, we can find some detailed settings. We can set how much
tolerance we have for data loss for the session we created in the event storage mode
options. We will choose the No event loss but this option can affect the system
performance negatively the databases which have heavy workloads. Another option
is Maximum dispatch latency and this option specifies the maximum duration that an
event can be kept in the buffer before being written to the target. Finally, we click
the OK button and create the extended event.
Create an extended event session to identify the long-running queries
 Create an extended event session to identify the long-running queries

• Event Retention mode: This is how we want our events to be handled. Suppose in the case of
a heavily loaded system, this option ensures we want to capture all events or is it fine to lose
some events while keeping system performance and reliability intact.
• The event retention mode is set to “Single event loss”. This means if the event buffers fill up
before SQL Server can write the events to the targets, it will drop a single event instead of causing
significant performance degradation on the server.
• ALLOW_SINGLE_EVENT_LOSS. An event can be dropped from the session if the
buffers are full. A compromise between performance and data loss, this is the default
value.
• ALLOW_MULTIPLE_EVENT_LOSS. Full event buffers containing multiple events can be
discarded. Minimal performance impact, but high data loss.
• NO_EVENT_LOSS. Events are never discarded; tasks that trigger events must wait until
event buffer space is available. Potential for severe performance impact, but no data
loss.
• If we set this option to "No event loss" this option may impact system performance so care
should be taken.
 Create an extended event session to identify the long-running queries

• Maximum Dispatch latency: This option forces events to be flushed from memory to the targets
at a defined interval.
• In seconds. Select this option to prolong or shorten the maximum dispatch latency.
• Unlimited. Select this option if you want the events dispatched only when the buffer is full.
• The final option includes:
• Maximum memory size
• Maximum event size
• Memory partition mode which is how the memory partition should be handled i.e. none, per
node or per CPU.
• NONE. Memory is not partitioned. A single group of event buffers are created.
• PER_NODE. A group of event buffers is created per NUMA node.
• PER_CPU. A group of event buffers is created per CPU.
Configuring Targets

Event File
The event file target can be used to write session data to a file.

Event Pairing
The event pairing target is used to match events that occur in pairs (for example,
statement starting and statement completing, or lock acquired and lock released), and
report on beginning events that have no matching end event.

Ring Buffer
The ring buffer target is used to write session data into a block of memory. When the
allocated memory is full, the oldest data in the buffer is discarded and new data is
written in its place.
Configuring Targets

Histogram
The histogram target is used to partition a count of events into groups based on a
specified value.

Event Tracing for Windows

The event tracing for Windows target is used to write session data to an ETW log.

Event Counter
The event counter target is used to count events in a session. It takes no configuration
parameters.
Create an extended event session to identify the long-running queries
Analyze the collected data

After we create the extended event session, it will automatically start and begin to collect
the data.
We can use the Watch Live Data option to analyze the collected data.
For example, after executing the following query in the Adventureworks database, this
query will be captured by the extended event.

1 SELECT SO.AccountNumber FROM

2 Sales.SalesOrderHeader SO
3 INNER JOIN Sales.SalesOrderDetail SD
4 ON SO.ModifiedDate = SD.ModifiedDate
Analyze the collected data
Analyze the collected data

When we configured the Extended Events, if we selected the option to show live data after
configuration we can navigate to the newly created event, right click on the event and select
the "Watch Live Data" as shown below.
Analyze the collected data

Here is sample output from the "Watch Live Data" option:

The system_health Extended Events Session

• Created by default on all instances of SQL Server

2008 or later versions
• Starts at instance startup
• Captures events useful for troubleshooting
• Ring buffer and file targets
Usage Scenarios for Extended Events

Execution Time-outs
When a Transact-SQL statement runs for longer than the client application’s command
time-out setting, a time-out error will be raised by the client
application. Without detailed client application logging, it may be difficult to identify the
statement causing a time-out.
This scenario is an ideal use case for the Extended Events event pairing target, using
either of the following pairs:
• sqlserver.sp_statement_starting and sqlserver.sp_statement_completed (for
systems using stored procedures for database access).
• sqlserver.sql_statement_starting and sqlserver.sql_statement_completed (for
systems using ad hoc SQL for database access).

When a time-out occurs, the starting event will have no corresponding completed event,
and will be returned in the output of the event pairing target.
Usage Scenarios for Extended Events

Troubleshooting ASYNC_NETWORK_IO
The ASYNC_NETWORK_IO wait type occurs when the database engine is waiting for a
client application to consume a result set. This can occur because the client application
processes a result set row-by-row as it is returned from the database server.
To troubleshoot this issue with Extended Events, capture the sqlos.wait_info event,
filtering on wait_type value NETWORK_IO. The histogram target might be suitable for
this investigation, using either the client application name or the client host name to
define histogram groups.
Usage Scenarios for Extended Events

Tracking Errors and Error Handling in Transact-SQL

Errors may be handled in Transact-SQL code by using TRY…CATCH blocks. Every error
raises an event in Extended Events; this includes the errors handled by the TRY…CATCH
blocks. You might want to capture all unhandled errors, or track the most commonly
occurring errors whether or not they are handled.
The sqlserver.error_reported event can be used to track errors as they are raised. The
is_intercepted column can be used to identify an error is handled in a TRY…CATCH
block.
Usage Scenarios for Extended Events

Tracking Recompilations
Query execution plan recompilations occur when a plan in the plan cache is discarded
and recompiled.
High numbers of plan recompilations might be an indicator of a performance problem,
and may cause CPU pressure. Windows performance counters can be used to track
overall recompilation counts for a SQL Server instance, but more detail may be needed
to investigate further.
In Extended Events, the sqlserver.sql_statement_recompile event can provide detailed
information, including the cause of recompilation.
The histogram target can be used for tracking recompilations. Group on
source_database_id to identify the database with the highest number of recompilations
in an instance. Group on statement/object_id to find the most commonly recompiled
statements.
Usage Scenarios for Extended Events

tempdb Latch Contention

Latch contention in tempdb can occur due to contention for the allocation bitmap
pages when large numbers of temporary objects are being created or deleted. This
causes tempdb performance problems because all allocations in tempdb are slowed
down.
The latch_suspend_end event tracks the end of latch waits by database_id, file_id, and
page_id. With the predicate divide_evenly_by_int64, you can capture the contention
specifically on allocation pages, because the different allocation bitmap pages occur at
regular intervals in a database data file. Grouping the events using the histogram target
should make it easier to identify whether latch waits are caused by contention for
allocation bitmap pages.
Usage Scenarios for Extended Events

Tracking Lock Escalation

Lock escalation occurs when more than 5,000 locks are required in a single session or
under certain memory conditions.
The sqlserver.lock_escalation event provides the lock escalation information.

Troubleshooting Orphaned Transactions

Orphaned transactions are open transactions where the transaction is neither committed
nor rolled back.
An orphaned transaction may hold locks and lead to more critical problems like log
growth and blocking, potentially leading to a block on the whole SQL Server instance.
The database_transaction_begin and database_transaction_end events can be used
with an event pairing target to identify the orphaned transactions. The tsql_frame
action can be used to identify the line of code where the orphaned transaction started.
Usage Scenarios for Extended Events

Tracking Session-Level Wait Stats

The wait stats available from the sys.dm_os_wait_stats DMV are aggregated at instance
level, so it’s not a fine-grained troubleshooting tool. Although you can track wait stats
by session with the additional sys.dm_exec_session_wait_stats DMV on SQL Server, this
may not be suitable for use in a busy system with many concurrent database sessions.
The sqlos.wait_info event can be used to track waits across multiple concurrent
sessions.
Tracking Database and Object Usage
Tracking database and objects usage helps to identify the most frequently used
database and most frequently used objects within a database. You might use this
information to guide your optimization efforts, or to prioritize objects for migration to
faster storage or memory-optimized tables.
The sqlserver.lock_acquired event can help with tracking the usage in most cases. For
database usage, a histogram can target grouping on database_id. Object usage can be
tracked by tracking SCH_M or SCH_S locks at the object resource level by grouping on
object_id in a histogram target.
Usage Scenarios for Extended Events
Extended Events Best Practices

Run Extended Events sessions only when you need them

Although Extended Events is a lightweight logging framework, each active session has an
overhead of CPU and memory resources. You should get into the practice of
only running Extended Events sessions you have created when you have to troubleshoot
specific issues.

Use the SSMS GUI to browse available events

Understand the limitations of the ring buffer target

When using a ring buffer target, be aware that you might not always be able to view all the
events contained in the ring buffer. This is due to a limitation of the sys.dm_xe_session_targets
DMV; the DMV is restricted to displaying 4 MB of formatted XML data. Because Extended
Events data is stored internally as unformatted binary, it is possible that the data in a ring buffer
will, when converted to formatted XML, exceed the 4 MB limit of sys.dm_xe_session_targets.
Extended Events Best Practices

Consider the performance impact of collecting query execution plans

Three events can be used to collect query execution plans as part of an Extended Events
session:
• query_post_compilation_showplan. Returns the estimated query execution plan when a
query is compiled.
• query_pre_execution_showplan. Returns the estimated query execution plan when a query
is executed.
• query_post_execution_showplan. Returns the actual query execution plan when a query is
executed.
When using any of these events you should consider that adding them to a session, even when
predicates are used to limit the events captured, can have a significant impact on the
performance of the database engine instance. This effect is most marked with the
query_post_execution_showplan event. You should limit your use of these events to
troubleshooting specific issues; they should not be included in an
Extended Events session that is always running.
Extended Events Best Practices

Understand the Deadlock Graph Format

Deadlock graphs collected by the xml_deadlock_report and database_xml_deadlock_report
events are in a different format from the deadlock graphs produced by SQL Server Profiler; with
these, you can use deadlock graphs captured by Extended Events to represent complex
deadlock scenarios involving more than two processes. If saved as an .xdl file, both formats of
deadlock graph can be opened by SSMS.
Demonstration: Tracking Session-Level Waits

• In this demonstration, you will see how to report

on wait types by session using Extended Events
Lab: Extended Events

• Exercise 1: Using the system_health Extended

Events Session
• Exercise 2: Tracking Page Splits Using Extended
Events

Logon Information
Virtual machine: 10987C-MIA-SQL
User name: ADVENTUREWORKS\Student
Password: Pa55w.rd

Estimated Time: 90 minutes

Lab Scenario

While investigating why the new SQL Server

instance was so slow, you came across deadlock
occurrences and excessive fragmentation in
indexes caused by page split operations. In this
lab, you will review deadlock occurrences using
the default session and implement a new
Extended Event session to identify workloads that
cause huge page splits.
Lab Review

In this lab, you have learned how to:

• Use the system_health Extended Events session.
• Create your own Extended Events session.
Module Review and Takeaways

In this module, you have learned about the

Extended Events system and its components. You
have learned about the objects that comprise an
Extended Events session, and how to query the
metadata about each object type to understand the
information it provides.
You have learned how to create, amend and drop
Extended Events sessions using either SSMS or
Transact-SQL, in addition to learning about various
methods for extracting data from session targets.
Module 10
Monitoring, Tracing, and Baselines
Module Overview

This module describes tools and techniques you can use to monitor and trace Microsoft®
SQL Server® performance data, and to create baselines to assess future changes in
performance. It focuses on data collection strategy and techniques to analyze the collected
data.

• Monitoring and Tracing

• Baselining and Benchmarking
Lesson 1: Monitoring and Tracing

This lesson describes the tools that you can use to monitor and trace SQL Server diagnostic
data. Monitoring SQL Server enables you to detect performance problems as and when they
happen or before they happen, so you can resolve issues proactively. You can also use the
trace and monitoring data to establish a baseline and create a benchmark for SQL Server
performance.
• Dynamic Management Objects
• Windows Performance Monitor
• Activity Monitor
• Extended Events
• SQL Server Profiler
• Analyzing Trace Data
• Trace Replay
• Demonstration: Analyzing Performance Monitor Data
Dynamic Management Objects
DMOs are a collection of dynamic management views (DMVs) and dynamic management
functions (DMFs) that you can use to monitor the health of a
SQL Server instance or database.
You can query a DMV by using Transact-SQL in the same way that you can query other
views. A DMF is a table-valued function that accepts one or more parameters.
• Server-scoped DMOs are stored in the sys schema of the master database and provide
information at the instance level. Querying a server-scoped DMO requires the VIEW
SERVER STATE permission and the SELECT permission on the appropriate object.
• Database-scoped DMOs are stored in the sys schema of each database and provide
information at the database level. Querying a database-scoped DMO requires the VIEW
DATABASE STATE permission and the SELECT permission on the appropriate object.
Dynamic Management Objects
There are more than 150 DMOs covering many categories; they are an important and
useful tool that you can use to monitor and tune SQL Server. You can identify the category
of a DMV by its prefix, as shown in the following table:
Dynamic Management Objects
The following DMVs are particularly valuable for gathering performance information:
• sys.dm_db_index_physical_stats. This provides size and fragmentation information for
all indexes.
• sys.dm_exec_rquests. This provides information about currently running queries
including start time, resource utilization, and estimated completion time. You can use it
to identify blocking issues.
• sys.dm_io_virtual_file_stats. This returns information about database file reads and
writes. You can use it to identify contention issues.
• sys_dm_os_wait_stats. This returns the total wait time for each wait type since instance
startup or when the wait statistics were last cleared. You can clear wait statistics by using
the DBCC SQLPERF(WAITSTATS, CLEAR) command.
Windows Performance Monitor

Windows Performance Monitor is a graphical tool for monitoring system performance.

It is preinstalled with Windows and provides insight into current application and
hardware performance by using built-in Windows
performance counters.
Windows Performance Monitor

You can use Performance Monitor to:

• Display real-time system performance data in three formats: line graph, histogram,
and report.
• Monitor overall system health, SQL Server health, or the health of other applications
by selecting counters from the available performance objects.
• Record current performance counter values in text files and databases to analyze
later. You can analyze the performance data by using file manipulation techniques or
Transact-SQL queries against the appropriate database.
• Create custom sets of performance counters known as a data collector set that you
can then schedule to run as appropriate.
• Configure and respond to alerts. For example, when a specified threshold is reached,
start a particular data collector set or a particular program.
Windows Performance Monitor
Monitoring Tools

From the Monitoring Tools icon you can right click and launch the Resource
Monitor. Resource Monitor is another powerful tool that can help you see how your
system resources are being used. You also have the ability to launch the System
Reliability Monitor. This utility allows you to see information about software updates
and installations. You can also see critical events that occurred and on what day those
events occurred. Finally, you can see all of the problem reports that have been sent
from your computer by clicking on the "View all problem reports" link at the bottom of
the window.
Windows Performance Monitor
Performance Monitor

The Performance Monitor is primarily for viewing real time statistics. By default only
one counter is selected; the %Processor Time counter. However you can add additional
counters by clicking on the green plus sign. This will allow you to monitor any counters
you wish in real time.
While you can see all of the performance counters you like here, the real power of
Performance Monitor is found in its ability to capture performance metrics over
an elapsed period of time. Capturing data over a period of time allows you to see
trends and these trends are what are most useful for determining the overall
performance of your system. To capture this data, you can create what are called "Data
Collector Sets".
Windows Performance Monitor
Data Collector Sets

Data Collector Sets are aptly named. They collect data from your system so that you
can view changes in configuration information and performance information over a
specified period of time.

Performance Counter Capture data based on the polling of an event

at a specified time interval
Capture data based on events that occur
Event Traces
rather than based on a specified time interval
System Configuration Information
Capture configuration information
Activity Monitor

Activity Monitor is a lightweight monitoring tool that is built into SQL Server Management
Studio.
Activity Monitor displays the current SQL Server processes and their effect on the instance.
Activity Monitor provides information about the following areas:
• Active expensive queries. This shows running queries with high resource usage in terms
of CPU, I/O, and memory.
• Data file I/O. This displays usage information for the database files.
• Processes. This shows diagnostic information about running processes in SQL Server in a
tabular format that is easy to analyze.
• Recent expensive queries. This shows recent queries with high resource usage in terms
of CPU, I/O, and memory.
• Resource waits. This displays real-time wait statistics.
• Overview. This provides an overview of the current health of the system.
Activity Monitor

SQL Server Activity Monitor presents information in a document window that consists of a
number of collapsible panes. You can customize these by rearranging or sorting columns, or
by adding filters.
When you expand a tab in Activity Monitor, queries are sent to the database engine to
retrieve the required data. To ensure that unnecessary load is not placed on the server,
querying stops when you collapse a tab.
Extended Events

See module 9
SQL Server Profiler

SQL Server Profiler is an application for capturing, managing, and analyzing traces. The
trace can be saved to a trace file or a database table. SQL Server Profiler has been
deprecated and may be removed in future versions of SQL Server.
You can use SQL Server Profiler to capture relevant data points for selected events that
you can use to identify the causes of performance problems.
SQL Server Profiler

You can use SQL Server Profiler to:

• Find resource-intensive queries.
• Find long-running queries.
• Resolve problems by replaying a recorded trace in a test environment.
• Correlate Performance Monitor output to diagnose problems.
• Capture blocking and deadlock graphs.
• Find missing statistics, and hash and sort warnings.
SQL Server Profiler is a good tool to diagnose and fix performance problems. However,
before you use it, you should be aware that SQL Server Profiler has a negative impact
on the performance of a SQL Server instance, particularly if you run more than one
trace at a time. Events in SQL Server Profiler generate all data columns, even if you
have not selected all columns for recording.
Trace Replay

Trace Replay helps you to assess the impact of hardware and software changes by
putting a reallife load on a test system. You can perform a Trace Replay by using
SQL Server Profiler or the Microsoft SQL Server Distributed Replay feature.

You can use Trace Replay to replay a production workload on a test server to help
to identify performance issues or to test the impact of software patches, bug
fixes, or configuration changes. For example, you can replay the trace to check
the effect of the newly created indexes on the test server.
Database Engine Tuning Advisor

The Database Engine Tuning Advisor is a graphical and command-line tool that
analyzes how the SQL Server Database Engine processes queries and makes
recommendations for improving the performance of queries through the creation
of indexes, partitions, indexed views, and statistics. It is provided with SQL Server
and can consume a trace file, analyze the queries that are captured, and then
provide details of:
• New indexes and statistics that can increase query performance.
• Suggest partition strategy.
• The usage of existing indexes.
Demonstration: Analyzing Performance Monitor Data

In this demonstration, you will see how to:

• Analyze Performance Monitor data
Lesson 2: Baselining and Benchmarking

This lesson focuses on how to establish baselines and create benchmarks for SQL Server.
You must establish a SQL Server baseline because baselines give insights into trends that
occur in a SQL Server environment. This simplifies troubleshooting.

• Methodology for Creating Baselines

• Stress-Testing Tools

• Data Collection Using DMVs

• Data Collection Using Perfmon Counters

• Analyzing Collected Data

• Database Engine Tuning Advisor

• Demonstration: Collecting Performance Data using DMVs

Methodology for Creating Baselines

A baseline is the normal or usual state of a SQL Server environment. A SQL

Server baseline informs you how a system typically performs on any given day.
Some of the main benefits of a baseline include the following:
• It provides insights into trends that occur in an environment, in addition to
data.
• You can compare baselines with current system state to find out what has
changed and proactively tune or resolve problems.
• It provides better capacity planning.
• It makes troubleshooting swift and easy.
Methodology for Creating Baselines

What to Capture?
Many diagnostic data points are available to be collected from one or more
sources. Too much data can be overwhelming and difficult to analyze. It will only
add to the storage cost instead of being useful.
Capture relevant data points—the data that can help you diagnose and foresee
performance problems.
Methodology for Creating Baselines
To start with, consider collecting the following data points:
• System usage. System usage is largely described in terms of CPU, I/O, and memory
consumption. You can quickly check these basic Performance Monitor counters against
the current values in case of sudden performance degradation. These values can also be
used to define a system usage trend, which will further help in capacity planning.
• SQL Server configuration. These are instance-level or database-level configuration
settings, such as max server memory, degree of parallelism, or auto shrink. You can
change these configuration settings, but changing them without having advanced
knowledge of SQL Server can create problems.
• Database size information. The system will come to a halt when storage runs out of
space. This makes it necessary to capture database and file size information. It will help
you to ensure that the system is up and running and proactively reacts to space issues,
thereby preventing system downtime.
• Wait statistics. Wait statistics is the first place to look when you troubleshoot SQL
Server performance issues. It gives deeper insights into the root cause of a system and is
very helpful when optimizing a slow system. You can also compare the wait statistics
 Methodology for Creating Baselines
Data Capture Frequency
After you decide what to capture, the next step is to decide the frequency of the data capture.
The frequency governs the amount of data that is captured. Too much data will result in high
storage costs; too little data will not give better understanding of the system. The frequency
depends on the type of data that you capture. Performance Monitor data can be captured every
15 seconds or so. However, it is not ideal to capture SQL instance configuration data every 15
seconds.
It is also necessary to have a data retention strategy. It is not advisable to keep a year or six
months’ worth of baseline data as this data is not likely to be of use. In addition, capturing data
during off-peak hours will only add additional data to the storage without being useful. The best
practice is to capture data during business peak hours and keep it for three or four months.
Data Storage
The data collected might be small, but the frequency and duration of collection might mean that
it requires a large amount of storage. The recommendation is to store the baseline data in a
separate database on a separate SQL Server instance. The separate database can be used to
store baseline database from more than one server. You should also optimize the baseline
database to get the relevant
Data Collection Using Perfmon Counters

Performance Monitor is a Windows graphical utility to monitor real-time

performance data or capture data over a period. You can create a
baseline or compare the current system performance against an established baseline
by using the captured data.
You cannot use the real-time performance data for historical analysis. It can only be
used to monitor current system state and compare against
the established baseline. To monitor real-time performance using Performance
Monitor, follow these steps:
1. To start Performance Monitor, in the Run command window, type perfmon.
2. In the leftmost pane, expand Monitoring Tools, and then click Performance
Monitor. This will open
3. the Performance Monitor window in the rightmost pane.
4. To add the counters to monitor, click the Plus Sign.
5. When you have added the required counters, click OK to view performance
information.
Data Collection Using Perfmon Counters

To set up and schedule a data collector set to collect performance counters,

follow these steps:
1. To start Performance Monitor, in the Run command window, type perfmon.
2. In the Performance Monitor window, in the leftmost pane, expand Data
Collector Sets, right-click User Defined, click New, and then click Data
Collector Set. The Create new Data Collector Set dialog box will appear.
3. In the Create new Data Collector Set dialog box, type a name, click Create
manually, and then click Next.
4. In the Create data logs section, select Performance counter, and then click
Next.
5. Choose the appropriate performance counters.
6. Specify a sampling interval, and then click Finish. You can now schedule the data
collector or execute manually as required.
7. Right-click the data collector set you created, and then click Properties.
8. On the Schedule tab, click Add, and in the Folder Action dialog box, schedule
the collection.
Analyzing Collected Data

The data you collect will not be useful until you can analyze it to get meaningful
information. You can analyze Performance Monitor data by using Microsoft
Excel® or by importing the performance logs into a database:
• Microsoft Excel. The performance data, in csv format, can be manually
analyzed in Excel. If the data is collected in binary format, the binary log file
can be converted to csv format with the relog command-line utility. The relog
utility ships with Windows and does not require a separate installation. The
following example shows a typical command to convert a binary log file to csv
format by using the relog utility:
relog <binary file path> -f csv –o <csv file path>
Analyzing data in Excel can be a tedious task. The column headers need to be
formatted, the performance data requires formatting, and then aggregate
columns need to be added to get the maximum and minimum standard deviation
for the counter values. This becomes even more tedious when more than one file
is to be analyzed
Analyzing Collected Data

• Database. The performance data can be imported into SQL Server and analyzed by
using Transact- SQL statements. The performance data can be imported into a
database manually, loaded by using SQL Server Integration Services, or loaded by
using the relog utility. The simplest method is probably the use of the relog
command-line utility. The following example shows the syntax to import a
performance log into a database by using the relog utility:

relog <binary file path> -f SQL -o SQL:<ODBC Connection>!<display string>

The relog utility accepts a binary log file and inserts it into the database that the
Open Database Connectivity (ODBC) connection specifies. The display string
identifies the binary log file or the data collector set within the database
Analyzing Collected Data

The relog utility imports data into three different tables, as follows:
• DisplayToID. This lists each data collector set that is imported into the database. A
unique identifier uniquely identifies each data collector set. The data collector is
identified by the display string value that is specified when importing the data, as
shown in the preceding relog command syntax. The table also contains the number of
records that are imported and the log start and log stop time.
• CounterDetails. This contains one row for each counter that is present in the
performance log file. Every counter is uniquely identified by a unique counter id. Each
counter has an associated machine name. This is helpful in identifying counter values
from different computers.
• CounterData. The CounterData table stores the actual counter values. The important
columns are GUID, counterID, counter value, and counterdatetime. The GUID
columns link to the DisplayToID GUID column. The counterID columns link to the
CounterDetails counterID column. The counter value column contains the actual
counter value, and the counterdatetime column contains the timethat the value was
recorded.
Database Engine Tuning Advisor

• Enables tuning with no knowledge of underlying databases

• Accepts a variety of workloads:

• Plan cache

• SQL Server Profiler trace

• Transact-SQL

• XML
Demonstration: Collecting Performance Data using
DMVs
• In this demonstration, you will see how to collect
performance data by using DMVs
Lab: Monitoring, Tracing, and Baselining

• Exercise 1: Collecting and Analyzing Data Using

Extended Events
• Exercise 2: Implementing Baseline Methodology

Logon Information
Virtual machine: 10987C-MIA-SQL
User name: ADVENTUREWORKS\Student
Password: Pa55w.rd

Estimated Time: 60 minutes

Lab Scenario

You are investigating why a new SQL Server

instance is so slow; users frequently complain that
their workloads run very slowly during peak hours
of business. In addition, to troubleshoot
performance issues in future and take more
informed corrective measures, you decide to
establish a baseline for SQL Server performance.
In this lab, you will set up data collection for
analyzing workload during peak business hours
and implement a baseline methodology to collect
performance data at frequent intervals, so that
comparisons can be made with the baseline.
Lab Review

You will now be able to:

• Collect and analyze performance data by using
Extended Events.
• Implement a methodology to establish a baseline.
Module Review and Takeaways

Constant monitoring and tracing is the key to

identifying performance issues that are happening
in their environment. Benchmarks and baselines are
the key to implanting a robust performance
troubleshooting methodology.