A Developers Guide to SQL Profiler
By Mike Prince
SQL Profiler is powerful tool for any MS SQL database developer. Adding it to your toolset opens up a whole new world of debugging and performance tuning capabilities by providing a deep insight into what your code, and database, is actually doing. Whether you are developing with hand-coded T-SQL,
an OR Mapper (LLBL Gen, etc.), or a component that generates database
commands for you, the Profiler can help diagnose
many mysteries and help pinpoint performance problems.
How does it work? It's pretty simple in concept. The Profiler receives a copy of all statements issued to
the database after they have executed. This allows you to see the SQL statment and it's duration,
CPU, and I/O used during runtime.
Let's take a quick peek at the Profiler. If you are using SQL 2005, you will
find it under Start > Programs > Microsoft SQL Server 2005 > Performance
Tools. If you are using SQL 2000, go to Start > Programs > Microsoft
SQL Server and look for Profiler. I'll be using screen shots from SQL 2005
but they will still be relevant if you are using SQL 2000.
Possibly the most intimidating thing is simply opening the app. After you connect
to your database, it's basically a blank slate. You eventually find File > New Trace but then you are presented with a somewhat
cryptic interface. This
is about as far as many developers go, but let's push on through and see what it
has to offer. The easiest way to get going is to select 'Tuning'
from the 'Use the template:" drop down box. This template will show you all
stored procs and T-SQL statements as they run against the database in real-time. After selecting 'Tuning', click Run or File > Run Trace. Don't worry about the other fields on this
form right now as they won't be needed for doing the basics.
Now that you have the profiler running you will see a single line that says 'Trace
Start'. If you are running this against a busy development server or perhaps
a production server then you may see hundreds of records a second. This
tool can actually slow down a busy database server a bit so be careful
about running it against a production machine during peak times. If you need
to slow down the onslaught of records, stop the trace and click on the Properties button in the toolbar. Click on the Events Selection tab and look for Column Filters and you will see the screen shot below. Select DatabaseName
and expand the 'Like' item in the tree and type in AdventureWorks and then click OK. Now press the green run button or select File > Run Trace.
If you do not have AdventureWorks installed just follow along using your own database and change the sample queries as necessary. In SQL 2000, you will need to figure out your database id by running this query and then filtering by DatabaseID:
/* for SQL 2000 */
use AdventureWorks
select db_id()
We're in business now. The profiler is running, we've applied a filter
so that we can see just want we need to. Now what? In this case, we'll
fire a couple of test queries directly against the database, but in real life, here
is where you would fire up the app that is not doing what you want or expect. For this example, let's open
up SQL Server Management Studio (SQL 2005) or SQL Query Analyzer (SQL 2000) then
connect to the AdventureWorks database and run the following query:
select * from Person.Address where City like 'Orlando'
Return to the Profiler and you should see something similar to the screen below.
The
most important columns will be the TextData and the Duration. In this case,
TextData is exactly what we entered into the query window. In other cases,
this will be the stored proc or T-SQL statement as generated by some component in
your application. The Duration is in milliseconds and in this case it is
4ms.
Hopefully this helps in understanding the power of this application. I develop mostly web applications
and tend to fire up SQL Profiler nearly every day for one purpose or another.
The next time you are puzzled by how something works,
or doesn't work, in
your database application, fire it up and get a clear view of the traffic
between your app and your database. There are a ton of other events and columns
that can help you with various problems so go ahead and dive in. You won't
be sorry.