Hướng dẫn học Microsoft SQL Server 2008 part 130 docx

Nielsen c56.tex V4 - 07/21/2009 3:52pm Page 1252
Part VIII Monitoring and Auditing
JOIN sys.trace_columns tcol
ON tinfo.columnid = tcol.trace_column_id
Result:
Event Column

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 the sp_trace_setstatus system stored procedure. The first param-
eter is the
traceid, and the second parameter specifies the action: 0 = stop the trace, 1 = start the
trace, and
2 = close a nd delete the trace. The sample code uses trace as 2:
EXEC sp_trace_setstatus 2, 0
Another useful trace system stored procedure is fn_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 with
option = 8 starts 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. Executing
sp_trace_create with option = 4 configures these traces.
1252
www.getcoolebook.com
Nielsen 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.
1253
www.getcoolebook.com
Nielsen c56.tex V4 - 07/21/2009 3:52pm Page 1254
www.getcoolebook.com
Nielsen 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
I
wonder how much of the gross national product is wasted annually wait-
ing at traffic lights. I’ve thought about using 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 f or 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.
1255
www.getcoolebook.com
Nielsen c57.tex V4 - 07/21/2009 3:55pm Page 1256
Part 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?
L

ooking 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 following
dbcc command:
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:
1256
www.getcoolebook.com
Nielsen 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

MISCELLANEOUS 0 0 0 0
LCK_M_SCH_S 1 29 29 0

LCK_M_SCH_M 12 160 40 5
LCK_M_S 21 12718 2029 35
LCK_M_U 7 4 1 4
LCK_M_X 35 611 76 126
LCK_M_IS 7 2 1 0

The versatile sys.dm_exec_requests DMV 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_stats DMV, 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.’’
1257

www.getcoolebook.com
Nielsen c57.tex V4 - 07/21/2009 3:55pm Page 1258
Part 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 o n 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.
1258
www.getcoolebook.com
Nielsen 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.
1259
www.getcoolebook.com
Nielsen c57.tex V4 - 07/21/2009 3:55pm Page 1260
www.getcoolebook.com
Nielsen 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
I
f 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.
1261
www.getcoolebook.com