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 . DatabaseID TSQL :SQL: StmtCompleted ApplicationName TSQL :SQL: StmtCompleted SPID TSQL :SQL: StmtCompleted Duration TSQL :SQL: StmtCompleted StartTime TSQL :SQL: StmtCompleted RowCounts 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. Files Microsoft SQL Server MSSQL10.MSSQLSERVERMSSQLLoglog_195.trc’, 1) Preconfigured traces SQL Server automatically runs a trace called the Default Trace that gathers basic events like server