The sample code uses trace as 2: EXEC sp_trace_setstatus 2, 0 Another useful trace system stored procedure isfn_trace_gettable, which reads a trace file and returns the data in table for
Trang 1Part VIII Monitoring and Auditing
JOIN sys.trace_columns tcol
ON tinfo.columnid = tcol.trace_column_id Result:
- -TSQL:SQL:StmtCompleted TextData
TSQL:SQL:StmtCompleted DatabaseID TSQL:SQL:StmtCompleted ApplicationName TSQL:SQL:StmtCompleted SPID
TSQL:SQL:StmtCompleted Duration TSQL:SQL:StmtCompleted StartTime TSQL:SQL:StmtCompleted RowCounts TSQL:SQL:StmtCompleted IsSystem TSQL:SQL:StmtCompleted EndTime TSQL:SQL:StmtCompleted Reads TSQL:SQL:StmtCompleted Writes TSQL:SQL:StmtCompleted CPU TSQL:SQL:StmtCompleted DatabaseName
To stop a server-side trace use thesp_trace_setstatussystem stored procedure The first
param-eter is thetraceid, and the second parameter specifies the action:0= stop the trace,1= start the
trace, and2= close and delete the trace The sample code uses trace as 2:
EXEC sp_trace_setstatus 2, 0 Another useful trace system stored procedure isfn_trace_gettable, which reads a trace file and
returns the data in table form:
SELECT * FROM fn_trace_gettable (’C:\Program Files\Microsoft SQL Server
\MSSQL10.MSSQLSERVER\MSSQL\Log\log_195.trc’, 1)
Preconfigured traces
SQL Server automatically runs a trace called the Default Trace that gathers basic events like server start
and stop, file growth, and creating or dropping objects As the default trace, its trace ID is 1
Theoreti-cally, it could be stopped without any ill effects, but there’s no reason to do so
Another preconfigured trace is the blackbox trace, which is used to diagnose server crashes Starting a
trace withoption = 8starts this trace Typically this trace is not run unless there’s a specific problem
and Microsoft PSS has asked for data from the trace
Common Criteria and the older C2 Audit security levels also involve running a specific trace that gathers
login and other security data Executingsp_trace_createwithoption = 4configures these traces
Trang 2Nielsen c56.tex V4 - 07/21/2009 3:52pm Page 1253
Tracing and Profiling 56
Summary
SQL Server Profiler and SQL Trace are two technologies you need if you’re interested in what’s really
happening with your server Profiler and SQL Trace may be venerable technologies compared to Change
Tracking or Extended Events, but they’re still two of the more useful tools in the DBA toolbox Whereas
some SQL Server technologies are optional — you can survive as a DBA without learning much about
XML or SMO — Profiler and SQL Trace are mandatory
Key points about SQL Trace and Profiler:
■ Trace is a server-side technology that collects data that may be consumed by Profiler or written
to a file
■ Profiler is a slick UI for Trace, but it may impact performance, so for heavy traces on a
pro-duction server, it’s best to use Profiler to configure the trace, generate a script, and then run
the trace on the server
■ Because there are 179 SQL Trace events, it’s worth it to become familiar with them
■ Events can be filtered; typically, Reporting Services and SQL Agent are filtered out
■ SQL Trace can be completely configured and controlled by T-SQL code alone, but this is an
advanced skill
■ SQL Trace events and Performance Monitor data can be integrated after the fact to produce a
complete picture of what was happening on the server
The next chapter stays in the mode of monitoring and auditing SQL Server Similar to SQL Trace, but at
a finer granularity, wait states track every process and every time it pauses for any reason
Trang 4Nielsen c57.tex V4 - 07/21/2009 3:55pm Page 1255
Wait States
IN THIS CHAPTER
Querying for wait states Detecting CPU pressure Analyzing hardware performance
Iwonder how much of the gross national product is wasted annually
wait-ing at traffic lights I’ve thought about uswait-ing the chronometer feature on my
Timex Ironman watch to time my monthly aggregate red light wait time (It
would be a good reason to actually use my watch for more than telling time, as
there’s little chance I’m going to do a triathlon anytime soon.) There’s no doubt
that our fast-food culture obsesses about avoiding waiting at any cost
SQL Server has to wait too Sometimes it’s waiting for I/O, sometimes for the
CLR, sometimes for CPU These waits are system bottlenecks Fortunately, you
don’t need a stopwatch to measure how SQL Server waits The data is all there in
a dynamic management view (DMV), just waiting for you
Most of my optimization strategies involve reducing the aggregate workload of the
database by improving the schema, queries, and indexes
Wait states are about tuning the environment — the hardware and server
oper-ating system By analyzing what SQL Server is waiting for, you can identify the
bottlenecks in the system
The SQL Server Operating System (SQLOS) uses one scheduler per logical CPU
core Each scheduler manages a set of sessions that rotate through three states
A session that’s running eventually has to wait for something, so it becomes
suspended while waiting When the wait is over, the session is runnable and
waiting for the CPU to pick it up again:
■ Running: Only one session per scheduler can be running at any
given time The session runs until it reaches a point when it’s waiting
for something, and then it yields control cooperatively back to the
scheduler The scheduler does not preempt sessions
■ Suspended: A session that’s waiting is said to be suspended, and it
stays suspended until the wait is satisfied
Trang 5Part VIII Monitoring and Auditing
■ Runnable: A session that’s no longer waiting and is ready to run again is put into the Runnable list, from which the scheduler can pick to run sessions
To examine this round-robin from a practical point of view:
■ If the session is spending time as runnable, then it’s waiting on the CPU This CPU pressure is
referred to as signal wait time It means the server needs more CPU cycles.
■ The amount of time that the session is suspended is the time it spends waiting for some resource — disk I/O, for example There no clearer way to see the hardware deficiencies than analyzing wait states
Of course, these three states assume that the session has work to do Sessions that are just waiting will
show up as background or sleeping
What’s New with Wait States?
Looking at wait states was a bit of an undocumented mystery when they were first exposed in SQL
Server 7, but Microsoft has steadily increased the number of wait states and their reliability
With SQL Server 2005, new dynamic management views were introduced, making it easier to view wait
states SQL Server 2008 brings wait states into the limelight by including wait states in Activity Monitor
Observing Wait State Statistics
Wait states are easier to observe with SQL Server 2008 than ever before SQL Server automatically
collects statistics on wait states as the server runs There’s nothing to enable or start as with SQL
Trace/Profiler For each type of wait state, SQL Server simply keeps a count of the instances and
durations
The normal behavior is to see the wait state statistics since the start of the server It’s probably more
beneficial to see the wait states for a period of time (e.g., during a specific test) To reset all the wait
states back to zero, run the followingdbcccommand:
dbcc sqlperf (’sys.dm_os_waiting_tasks’, clear) There are several ways to view wait states in SQL Server 2008
Querying wait states
The most common method of viewing wait states is to query the DMVs
The first wait state DMV lists every wait state type and its related statistics This is also where the
aggre-gate signal wait time (waiting on the CPU) is found:
Trang 6Nielsen c57.tex V4 - 07/21/2009 3:55pm Page 1257
Wait States 57
SELECT *
FROM sys.dm_os_wait_stats;
Result (abbreviated):
wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
- - -
.
The versatilesys.dm_exec_requestsDMV has a wealth of information about the current sessions,
including their current wait status:
SELECT session_id, status, command, wait_type, wait_time, last_wait_type
FROM sys.dm_exec_requests
WHERE Status NOT IN (’background’, ‘sleeping’);
Result:
session_id status command wait_type wait_time last_wait_type
- - - - -
-65 running SELECT NULL 0 MISCELLANEOUS
66 suspended CREATE DATABASE PAGEIOLATCH_SH 6 PAGEIOLATCH_SH
The third DMV with wait state information is a subset of the previous DMV:
SELECT *
FROM sys.dm_os_waiting_tasks
Activity Monitor
Activity Monitor has been around for nearly a decade, but it’s completely redesigned for SQL Server
2008 (Personally, I prefer the old Activity Monitor — it showed more detail about locks and wasn’t
as buggy a UI The new Activity Monitor refuses to size the columns correctly for widths less than
1,180 pixels.)
The new Activity Monitor has a section for waits that basically presents the key information from the
sys.dm_os_wait_statsDMV, as shown in Figure 57-1
If you’re running Enterprise Edition and exploring the new Management Data Warehouse
(MDW), you’ll find that the MDW also collects wait state information You can read more
about it in Chapter 62, ‘‘Management Data Warehouse.’’
Trang 7Part VIII Monitoring and Auditing
FIGURE 57-1
The new Activity Monitor displays basic wait state activity
Analyzing Wait States
Since wait state is available, the key question is, what does it mean? There are over 400 wait types, but
many are normal, similar, or rarely seen Some common wait types to look for include the following:
■ Locks: Sessions are waiting on other sessions to release locks Consider improving the indexing to reduce query duration
■ Latches and page latches: Sessions are waiting on memory or I/O
■ I/O Completion, Write Completion, Asynch I/O Completion: Sessions are waiting on writes to the data file
■ Asynch Network I/O: Sessions are waiting on a network resource
■ CXPacket: Parallel query synchronization
■ LogMgr, Write Log I/O: Sessions are waiting on the transaction log
Summary
Understanding wait states is vital to diagnosing server performance After all, what’s more important to
analyzing hardware performance than analyzing why it’s waiting? Key points from this chapter include
the following:
■ Every session (with work to do) rotates through three states: running, suspended, and runnable
Trang 8Nielsen c57.tex V4 - 07/21/2009 3:55pm Page 1259
Wait States 57
■ A high volume of runnable sessions, tracked as signal wait time, means there’s not enough
CPU cycles to meet the demand
■ While a resource is waiting for another resource (typically I/O or a lock), it’s considered
suspended
■ Wait states can be seen in Activity Monitor or DMVs
The next chapter propels the topic of monitoring and auditing into the newest capabilities of SQL
Server 2008 with Change Tracking, a new way to track which rows have been altered in a certain
time frame
Trang 10Nielsen c58.tex V4 - 07/21/2009 3:57pm Page 1261
Extended Events
IN THIS CHAPTER
Extended Events packages and objects
Starting XE sessions Querying XE data with XPath
If it ain’t broke don’t fix it
In my humble opinion, there’s nothing broken with SQL Trace and SQL Profiler,
wait states, and DMVs I’ve found these tools satisfactory for monitoring and
diagnostics
Nulltheless, the shiny new Extended Events (XE) feature, new in SQL Server
2008, is faster and more extensible than SQL Trace SQL Trace has an easy UI:
SQL Profiler Extended Events has no (Microsoft provided) UI, and it has a steep
learning curve XE is also compatible with Event Tracing for Windows (ETW)
You don’t need to learn Extended Events to be successful with SQL Server 2008
today
So why learn Extended Events? Two reasons First, Extended Events is
power-ful and more granular than SQL Trace Second, Extended Events is strategic to
Microsoft It’s the foundation for event analysis going forward
XE Components
The core of Extended Events is the Extended Events engine, which can handle
any event, and because the payload (the data about the event) is XML based, the
engine can include different data for different events as appropriate
The engine can see events synchronously, but can process events and send
event data to the target (the consumer of the event data) synchronously or
asynchronously, which is an improvement over SQL Trace and enables Extended
Events to handle a greater load than SQL Trace