SQL Server

SQL Server 2008 : Performance Tuning - Tracing

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
11/16/2010 2:56:27 PM
Half of performance tuning is finding the problem. System Monitor is the performance monitoring tool provided by Windows and this can be useful when measuring hardware performance or bottlenecks and useful in identifying the process on a server that is causing a slowdown. If users are complaining of poor response times and SQL Server is running on a shared server, perhaps with a third-party application or webserver such as Internet Information Services (IIS), System Monitor can help find the process consuming resources. If a server is dedicated to SQL Server, or investigation with System Monitor identifies SQL Server as the cause of the problem, a limited set of System Monitor counters are available to continue troubleshooting. System Monitor provides a serverwide overview and it isn’t possible to see exactly what SQL Server is doing at any point in time, which becomes useful when tracing.

As the performance tuning exercise is refined, it becomes necessary to get visibility of activity within SQL Server, and this is when we need tracing. Tracing provides the ability to collect data about the Transact-SQL (T-SQL) commands and Multi-Dimensional Expressions (MDX) that are executed on a database server. Additionally it is possible to trace for information about events affecting system performance such as deadlocks, warnings, data and log file shrinks/grows, and blocked processes. Tracing can also gather information about the way SQL Server processes requests internally such as locks, lock escalation, and query execution plans.

SQL Server Profiler (known as SQL Profiler or simply as Profiler) is the graphic tool installed alongside SQL Server used to define, configure, and start/stop traces. SQL Server Profiler can be found at Start > All Programs > Microsoft SQL Server 2008 > Performance Tools > SQL Server Profiler.

Once Profiler is launched, a toolbar and grey background appears, and you’ll first need to create a new trace. To create a new trace, either click File > New Trace or click the left-most icon from the toolbar. The next screen is the server connection dialog; here, specify the name of the server and SQL Server instance to be traced, and connection credentials.

After successfully connecting to an instance of SQL Server, the next dialog allows control over how trace data is stored and what data is captured. As shown in Figure 1, it’s possible to provide a name that describes the trace.

Figure 1. Create a New Trace with SQL Server Profiler

Trace Templates

The next configuration option is the trace template option, where the Standard template is selected by default. Trace templates provide a preconfigured trace definition for common trace scenarios. It is possible to create new trace templates, or modify those provided with SQL Server. It is usually possible to start with a template and adjust the events and filters based on your needs. Table 1 contains a summary of the trace templates, when you might use them, and the events captured.

Table 1. Trace Template Summary
SP_CountsUsed to trace calls to start Stored Procedures.SP:Starting
StandardCaptures data to provide instance overview, including T-SQL Statement and Stored Procedure Start and Completion.Audit Login Audit Logout ExistingConnection RPC:Completed SQL:BatchCompleted SQL:BatchStarting
TSQLCaptures T-SQL batch start times, useful for troubleshooting client application performance and correlating data captured from applications with SQL Server events.Audit Login Audit Logout ExistingConnection RPC:Starting SQL:BatchStarting
TSQL_DurationRecords all T-SQL Statements and the duration to complete.RPC:Completed SQL:BatchCompleted
TSQL_GroupedUseful for capturing activity about a specific user or application, this template groups T-SQL commands by user or client.Audit Login Audit Logout ExistingConnection RPC:Starting SQL:BatchStarting
TSQL_LocksCaptures all the Transact-SQL statements that are submitted to SQL Server by clients along with exceptional lock events. Use to troubleshoot deadlocks, lock time-out, and lock escalation events.Blocked Process Report





Deadlock Graph (Use against SQL Server 2005 or SQL Server 2008 instance.)


Lock:Deadlock Chain


Lock:Timeout (Use against SQL Server 2000 instance.)
  Lock:Timeout (timeout>0) (Use against SQL Server 2005 or SQL Server 2008 instances.)
TSQL_ReplayUse this template if the trace is to be replayed. Captures all events necessary to recreate statements/workload on a different server.CursorClose





Audit Login

Audit Logout

Existing Connection

RPC Output Parameter



Exec Prepared SQL

Prepare SQL


TSQL_SPsUseful for troubleshooting poorly performing Stored Procedures, this template will capture each step within the stored procedure to display execution duration.Audit Login

Audit Logout






TuningCaptures T-SQL completion times, used to pass to SQL Server Database Tuning Advisor for analysis.RPC:Completed



After you choose a trace template, it’s possible to click Run, and server activity will begin to fill the screen. This can be useful to verify the required events are being captured, or to monitor SQL instances where activity is low (a development workstation or test server where workload is restricted). However, reading and analyzing results captured through Profiler directly to the screen can become unwieldy on a server with even moderate load. In this situation, consider tracing to a flat file or database table, which will speed up the trace and allow for post-capture analysis.

Trace Events

Selecting the Events tab from the top of the trace properties dialog allows control of the event classes that will be captured when the trace is running. The events that are already selected are those specified in the trace template. Click Show All Events and Show All Columns to display all events and options available for capture.

You can choose any events that are necessary to include these in the trace definition. Figure 2 shows some useful events to include in each trace, the Errors and Warning events. These will alert you to a number of conditions that you should be aware of when troubleshooting any SQL Server problem.

Figure 2. Select Show All Events and Show All Columns to Display All Possible Events and Columns

Configuring & Implementing...: Exercise Caution with LOCK Trace Events

SQL traces affect server performance. Trace as few events as necessary— you’ll save overhead and capture less data to analyze! Exercise particular caution when capturing any events in the LOCK event class, since a busy SQL Server may acquire and release many thousands of locks per minute.

Trace Filters

Trace filters allow restrictions to be applied on the data that is captured by the trace. This can be useful on particularly busy or shared servers when filters can be used to capture activity for a single user, database, or application. Filters can be applied to include (Like) or exclude (Not Like) trace data.

To apply a filter, click Column Filters from the Trace Properties dialogue and select the Column on which to filter. In the example shown in Figure 3 all requests from server LONDBS1 are excluded from the SQL Trace.

Figure 3. Use Trace Filters to Include or Exclude Specific Trace Data

Server-Side Tracing

Server-side tracing reduces the impact of tracing and is recommended when tracing busy production servers or machines where system resources (memory, CPU, etc) are low. Additionally, when traces are run from the server itself there is no network time involved in reporting start times for query execution. Since network time can vary (e.g., latency due to traffic of other network users), tracing across a network can produce inconsistent results.

There are two methods to create a server-side trace. As always a family of stored procedures are provided, which can be cumbersome and difficult to translate to actual events and columns. It is possible to create a trace within Profiler and then script the trace definition. To script the trace definition, select File > Export > Script Trace Definition > For SQL Server 2005–2008.

Open the trace definition in SQL Server Management Studio, and you’ll see the sp_trace_create statement to define the trace. Here you’ll need to replace InsertFileNameHere with the path to the folder where trace files should be saved (see Figure 4). Try to avoid tracing to system drives, or those where data or log files are stored, since this will affect performance of the database server.

Figure 4. Trace Definition Created by SQL Profiler

Configuring & Implementing...: Avoid Tracing to System Drives

Try to place the trace files on a dedicated disk with enough capacity for the duration of the trace. Avoid storing trace files on system drives. If the drive does fill, recovering a server from a full system partition is more difficult and time consuming that if a nonsystem partition fills.

Once the destination is configured, run the script and make a note of the TraceID that is returned by the query. The trace is now defined on the server; however, there’s an additional step required to start the trace. The system stored procedure sp_trace_setstatus is used to control the trace, and requires parameters TraceID and status. Table 2 shows the status parameters. In order to start TraceID 2, we’ll need to run sp_trace_setstatus(2,1).

Table 2. Status Parameters to Control Server-Side Traces
0Stop trace
1Start trace
2Close trace and remove trace definition

Finally, if you lose track of which traces are running on a server, run Select * from fn_trace_getinto(null) to return details of all traces. Remember that unless you’ve disabled it there’s a default trace running at all times to populate the DMVs; this will be TraceID 1.

Combining System Monitor and Profiler Traces

First introduced to SQL Server 2005, this excellent feature of Profiler allows Administrators to combine a System Monitor (Performance Monitor) trace with a SQL Trace. This presents a single view of system resources (disk, memory, CPU) with the statements executing at the time; for example, enabling Administrators to correlate high-CPU conditions with a specific stored procedure or T-SQL statement.

Figure 5 shows the timeline from System Monitor, which allows a view of hardware utilization. The red vertical bar allows administrators to jump to a particular point (e.g., a CPU spike), and the profiler trace will identify the T-SQL running at the moment of the spike.

Figure 5. Combining System Monitor and Profiler Traces for a Single View

Replaying Traces

SQL Server provides the ability to replay traces; typical scenarios involve capturing a trace from a production server and replaying the trace against a test or preproduction server. This can help when evaluating changes and also with some troubleshooting scenarios. Each statement captured in the trace will be replayed against the target server; this can be helpful in verifying that a fix implemented on a test server does resolve a problem.

There are a minimum set of events required for trace playback; alternately use the Replay trace template. Not all servers can be traced and replayed; for example, if the server is participating in Transactional Replication trace replay isn’t possible because of the way transactional replication marks transactions in the log.

Head of the Class...: Working with SQL Trace Data

Capturing trace data on a busy server many generate many gigabytes of data. Using a server-side trace to a file on a local disk will minimize the tracing overhead. However, unless you’re looking for a specific event in the trace, often the best way to manage the data is to load the trace data from a flat file into a table. The following function will load trace data from a file into a table:

SELECT * INTO srv1_trace FROM::fn_trace_gettable('c:\temp\trace1.trc',

Once the data is in a database, analysis with TSQL queries is much easier!

Using SQLDiag to Collect Performance Data

SQLDiag is a command-line, data-collection utility first supplied with SQL Server 2005 that can useful for collecting performance data. SQLDiag collects the following:

  • Windows Event Logs

  • SQL Server Configuration details

  • System Monitor Performance logs

  • SQL Server Profiler Trace data

  • SQL Server blocking information

Essentially, SQLDiag doesn’t do anything that couldn’t be achieved separately— each of these tools could be run independently, however SQLDiag it makes it easier to start and stop data collection and ensures all relevant information is collected each time data capture is run.

Other -----------------
- SQL Server 2008 : Implementing Error Handling - Managing and Raising User-Defined Errors
- SQL Server 2008 : Implementing Error Handling - Understanding Errors
- Implementing SQL Server Objects Using Managed Code (part 2)
- Implementing SQL Server Objects Using Managed Code (part 1)
- Encryption Catalog Views
- Built-In Cryptographic Functions
- SQL server 2008 : Managing Security - Permissions
- SQL server 2008 : Managing Security - Schemas
- SQL server 2008 : Managing Security - Users
- SQL server 2008 : Managing Security - Roles
- SQL Server 2008 : Managing Remote Servers
- Linked Servers
- Adding, Dropping, and Configuring Linked Servers
- Mapping Local Logins to Logins on Linked Servers
- Obtaining General Information About Linked Servers
- Executing a Stored Procedure via a Linked Server
- Setting Up Linked Servers Using SQL Server Management Studio
- Encryption basics for SQL Server : Cryptographic Keys
- Encryption basics for SQL Server : Key Maintenance
- Encryption basics for SQL Server : Key Algorithms
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us