Tracing Sql Server 2005
Upcoming SlideShare
Loading in...5
×
 

Tracing Sql Server 2005

on

  • 5,959 views

 

Statistics

Views

Total Views
5,959
Slideshare-icon Views on SlideShare
5,913
Embed Views
46

Actions

Likes
0
Downloads
42
Comments
0

4 Embeds 46

http://www.sqlserver.co.il 27
http://www.slideshare.net 14
http://www.valinor.co.il 4
https://duckduckgo.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Tracing Sql Server 2005 Tracing Sql Server 2005 Presentation Transcript

  • ISQL Users Group May 2009 Tracing and Profiling SQL Server [email_address] http://blogs.microsoft.co.il/blogs/yaniv_etrogi
    • Over the next 1 hour:
    • SQL Trace Architecture and Terminology
    • Security and Permissions
    • Profiler
    • Server side Tracing
    • Saving and Replaying Traces
    • Querying Server-Side Trace Metadata
    • Introduction
    • Query tuning, optimization and troubleshooting are all possible by the ability to view what's going on inside SQL Server
    • SQL Trace provides a real-time view into what’s going on inside the database engine and at a very granular level
  • SQL Trace Architecture and Terminology
    • SQL Trace is an SQL Server database engine technology
    • SQL Server Profiler is a .NET application that uses system stored procedures exposing the functionality of SQL Trace
    • Microsoft.SqlServer.Management.Trace
    • http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.trace.aspx
    • When tracing we monitor for specific events which are generated when various actions occur in the database engine
      • For example, a user login or the execution of a query are each actions that cause events to fire
    • Each event has an associated collection of columns that contain the collected data when the event fires
    • SQL Server uses a model that selectively enables data collection as required
      • Data is never collected until someone asks for it
    • There are around 171 events and 65 columns to select from
    • The main component of the SQL Trace architecture is the trace controller which is a shared resource that manages all traces created by any consumer
      • There are various event producers in the database engine for example in the query processor, lock manager, and cache manager
      • Each of these producers is responsible for generating events that relates to certain categories of server activity
      • All producers are disabled by default and therefore generate no data
      • When a trace is started for a certain event a global bitmap in the trace controller is updated letting the event producer know that at least one trace is listening, and causing the event to begin firing
      • Managed along with this bitmap is a secondary list of which traces are monitoring which events
      • Once an event fires, its data is routed into a global event sink, which queues the event data for distribution to each trace that is actively listening
      • The trace controller routes the data to each listening trace based on its internal list of traces and watched events
      • In addition to the trace controller's own lists each individual trace also keeps track of which events it is monitoring along with which columns are actually being used as well as what filters are in place
      • The event data returned by the trace controller to each trace is filtered and the data columns are trimmed down as necessary before the data is routed to an I/O provider
    • Trace I/O providers send the data to the final destination
    • The available output formats for trace data are either a file on the database server (or a network share) or a rowset to a client
    • Both providers use internal buffers to ensure that if the data is not consumed quickly enough (written to disk or read from the rowset) it will be queued
    • The file provider is designed with a guarantee that no event data will be lost
    • If an I/O slowdown occurs so disk writes are not occurring quickly enough the internal buffers begin to fill
    • To monitor for these waits watch the SQLTRACE_LOCK and IO_COMPLETION wait types
    • The rowset provider is not designed for data loss guarantee
    • If data is not being consumed quickly enough and its internal buffers fill it waits up to 20 seconds before it begins dropping events in order to free buffers for the sake of getting things moving
    • SQL Server Profiler will then send an information message informing that some events had been lost and had not been captured
    • You can find out if you're headed in that direction by monitoring SQL Server's TRACEWRITE wait type which is incremented as threads are waiting for buffers to free up
    • A background trace management thread is started whenever at least one trace is active on the server
      • SELECT * FROM sysprocesses
      • WHERE cmd = N'TRACE QUEUE TASK' ;
    • The background thread is responsible for:
      • Flushing file provider buffers (done every 4 seconds)
      • Can be seen as a wait_type of SQLTRACE_BUFFER_FLUSH
      • Closing rowset-based traces that are considered to be expired (dropping events for more than 10 minutes)
    • There is no provider that writes trace data directly to a table
      • Security and Permissions
    • SQL Server 2005 introduces a new permission called ALTER TRACE. This is a server-level permission granted to a login principal and allows access to start, stop, or modify a trace (in addition to being able to generate user-defined events)
    • GRANT ALTER TRACE TO <LoginName> ;
    • SQL Trace has a couple of built-in security features to keep passwords secured
      • SQL Trace will automatically omit data if an event contains a call to a password-related stored procedure or statement. For example, a call to CREATE LOGIN including the WITH PASSWORD option will be blanked out by SQL Trace.
      • SQL Trace will not return statement text or query plans generated within an encrypted stored procedure, user-defined function, or view
  • Profiler
    • The General tab allows you to control how the trace will be processed by the consumer
    • The default setting is to use the rowset provider displaying the events in real time in the SQL Server Profiler tool window
    • Other available options are
      • Save the events to a table
      • Save the events to a file (on either the server or the client)
    • When saving to a table Profiler uses the rowset provider and routes the data back into a table
    • When saving to a server side file Profiler actually starts two equivalent traces—one using the rowset provider and the other using the file provider
    • Saving to a client-side file does not use the file provider at all. Rather, the data is routed to the Profiler tool via the rowset provider and then saved from there to a file.
      • This is more efficient than using Profiler to write to a server-side file
      • Remember that doing so you do not take benefit of the lossless data guarantee offered by the file provider
    • The Events Selection tab allows you to select events that you'd like to trace along with their associated data columns
    • In order to narrow your scope and help ensure that tracing does not cause performance issues SQL Trace offers the ability to filter the events based on various criteria
    • In SQL Server Profiler filtration is exposed via the “Column Filters” tab
    • Remember to check the “Show All Columns” checkbox in order to see the complete list of columns
    • Once you click the Run button data will begin streaming immediately and be displayed at the Profiler window (this is because Profiler uses the rowset provider)
      • If you find that data is coming in too quickly for you to be able to read it you may disable scrolling using the Auto Scroll icon on the SQL Server Profiler toolbar
      • If you are on a slow remote connection and your trace is not well filtered you may be in a situation that the icons in the Profiler tool bar are seen as if they were inactive thus disallowing you to stop the trace. The only way out here is to stop the trace using sp_trace_setstatus
    • Events that do not produce data for a specific column cannot be used to filter on that column
      • For example, the SQL:BatchStarting event does not produce duration data and therefore a filter defined on that column for this event will not filter anything
      • Note that the SQL:BatchStarting event will still return even though it lacks the Duration output column. To modify this behavior, check the “Exclude Rows That Do Not Contain Values” checkbox in the “Edit Filter” dialog box for the column you'd like to change the setting for
  • Saving and Replaying Traces
    • Profiler ships with eight predefined templates
      • A template is a collection of event and column selections, filters, and other settings that you can save to create a reusable trace definitions
    • TSQL_Replay template selects a variety of columns for 15 events that are all required for Profiler to be able to play back (Replay) a collected trace at a later time.
      • Collecting data using this template allows you to reproduce a problem experienced on a production system by replaying events collected on the production system at a test environment
      • Very useful for support departments
    • Collected trace data has to be saved and then reopened before a replay can begin
    • SQL Server Profiler offers the following options for saving trace data available from the File menu:
      • The Trace File option is used to save the data to a file formatted using a proprietary binary format. This is generally the fastest way to save the data, and also the smallest in terms of bytes on disk
      • The Trace Table option is used to save the data to a new or previously created table in a database. This option is useful if you need to manipulate or report on the data using T-SQL
      • The Trace XML File option saves the data to a text file formatted as XML
      • The Trace XML File For Replay option also saves the data to an XML text file, but only those events and columns needed for replay functionality are saved
    • Once the data has been saved to a file or table the original trace window can be closed and the file or table reopened via SQL Server Profiler's File menu
    • A trace reopened in this way will have a Replay menu on the Profiler tool bar allowing you to start replaying the trace, stop the replay, or set a breakpoint
    • During the course of the replay, the same events used to produce the trace being replayed will be traced from the server on which you replay
      • The ”Save To File” and “Save To Table” options are used for a client-side save. No server-side option exists for saving playback results
    • The trace will be replayed on multiple threads (2005 only), corresponding to at most the “Number Of Replay Threads” specified
      • The “Replay Events In The Order They Were Traced” option ensures that all events will be played back in exactly the order in which they occurred as based upon the EventSequence column. Multiple threads will still be used to simulate multiple spids.
      • The “Replay Events Using Multiple Threads” option allows SQL Server Profiler to reorder the order in which each spid starts to execute events, in order to enhance playback performance. However, the order of events will remain consistent with the EventSequence within a given spid
  • Server-Side Tracing
    • sp_trace_create is used to define a trace and specify an output file location. This stored procedure returns a handle to the created trace in the form of an integer TraceId
    • sp_trace_setevent is used to add/remove event/column combinations to traces based on the TraceId
    • sp_trace_setfilter is used to define event filters based on trace columns
    • sp_trace_setstatus is called to start, stop and and delete a trace.
      • Traces can be started and stopped multiple times over their lifespan
      • sp_trace_setfilter
        • @TraceID
        • ,@columnid
        • ,@logical_operator
        • ,@comparison_operator
        • ,@value
      • /*
      • @logical_operator: AND (0) or OR (1)
      • @comparison_operator:
      • 0 = Equal, 1 = Not equal, 2 = Greater than, 3 = Less than, 4 = Greater than or equal,
      • 5 = Less than or equal, , 6 = Like, 7 = Not like
      • */
    • SQL Trace offers both &quot;and&quot; and &quot;or&quot; logical operators that can be combined if multiple filters are used. However, there is no way to indicate parentheses or other grouping constructs, meaning that the order of operations is limited to left-to-right evaluation. This means that an expression such as A and B or C and D is logically evaluated by SQL Trace as (((A and B) or C) and D). However, SQL Trace will internally break the filters into groups based on columns being filtered. So the expression Column1=10 or Column1=20 and Column3=15 or Column3=25 will actually be evaluated as (Column1=10 or Column1=20) and (Column3=15 or Column3=25). Not only is this somewhat confusing, but it can make certain conditions difficult or impossible to express.
  • Querying Server-Side Trace Metadata
    • Get Traces
    • SELECT *
    • FROM sys.traces WHERE [status] = 1 ;
      • --This query returns the trace status, which will be 1 (started) or 0 (stopped); the server-side path to the trace file (or NULL if the trace is using the rowset provider); the maximum file size (or again, NULL in the case of the rowset provider); information about how many buffers of what size are in use for processing the I/O; the number of events captured; and the number of dropped events (NULL if your trace is using the file provider(loseless guarantee) ).
    • Get Events
    • SELECT
    • e.name AS [e vent ] ,
    • c.name AS [c olumn ]
    • FROM fn_trace_geteventinfo( @TraceId ) ei
    • INNER JOIN sys.trace_events e
    • ON ei.eventid = e.trace_event_id
    • INNER JOIN sys.trace_columns c
    • ON ei.columnid = c.trace_column_id;
    • Get Filters
    • SELECT
    • columnid
    • ,c.name AS [c olumn ]
    • ,logical_operator
    • ,comparison_operator
    • ,value
    • FROM fn_trace_getfilterinfo( TraceId ) ei
    • INNER JOIN sys.trace_columns c
    • ON ei.columnid = c.trace_column_id;
    • Get Events/Columns combination
    • SELECT
    • e.name AS [event]
    • ,c.name AS [column]
    • FROM sys.trace_event_bindings b
    • INNER JOIN sys.trace_events e
    • ON e.trace_event_id = b.trace_event_id
    • INNER JOIN sys.trace_columns c
    • ON c.trace_column_id = b.trace_column_id
    • ORDER BY e.name ;
    • Get SubClass values
    • SELECT
    • c.name AS [column]
    • ,e.name AS [event]
    • ,s.subclass_value
    • ,s.subclass_name
    • FROM sys.trace_columns c
    • INNER JOIN sys.trace_subclass_values s
    • ON c.trace_column_id = s.trace_column_id
    • INNER JOIN sys.trace_events e
    • ON e.trace_event_id = s.trace_event_id
    • WHERE e.name LIKE 'Audit Login'; `
    • Reading trace files
    • SELECT * FROM fn_trace_gettable(‘B:TracesTraceErrors.trc', 1);
      • This function takes two parameters: The path + name to the trace file and the number of trace files to read. If the second parameter is DEFAULT then all available trace files will be read
    • SELECT * INTO ProfilerErrors
    • FROM fn_trace_gettable(‘B:TracesTraceErrors.trc', DEFAULT);
      • Loading the file to a table allows querying the data.
      • It also consumes less resources as it is a one time operation and benefits from the fact that the SELCT..INTO command is a BULK operation where as just performing queries against the trace loads sql server’s memory and if it is a large set of data spilling begins thus incurring additional I/O
    • SELECT IDENTITY(int, 1, 1) AS RowNumber, *
    • INTO dbo.ProfilerErrors
    • FROM fn_trace_gettable(‘B:TracesTraceErrors.trc', DEFAULT);
    • Controlling trace state
    • EXEC sp_trace_setstatus @TraceId, 1; --start
    • EXEC sp_trace_setstatus @TraceId, 0; --stop
    • EXEC sp_trace_setstatus @TraceId, 2; –remove
    • A trace in a stopped state can be started without the need to recreate the trace. This allows to modify the Events/Columns selection and the selected Filters
    • A restart of the SQL Server service removes all trace definitions
      • Zeros the EventSequence column
      • If you need your trace always up and running you can launch it from a start up stored procedure
    • Import Performance Monitor Data
    • Default Trace
    • Balackbox Trace
  • ?
  • SQL Server BOL (Books Online) sys.dm_os_wait_stats http://msdn.microsoft.com/en-us/library/ms179984.aspx Troubleshooting and Analysis with Traces http://technet.microsoft.com/en-us/library/cc293616.aspx Introducing SQL Trace http://msdn.microsoft.com/en-us/library/ms191006.aspx SQL Profiler Events http://msdn.microsoft.com/en-us/library/ms186265.aspx SQL Profiler Data Columns http://msdn.microsoft.com/en-us/library/aa173882(sql.80).aspx Inside Microsoft SQL Server 2005 http://www.insidesqlserver.com/thebooks.html
  • Trace Errors http://blogs.microsoft.co.il/blogs/yaniv_etrogi/TraceErrors.zip