Using SQL Profiler to Find Errors
This chapter is from the book
This chapter is from the book
This chapter is from the book
One of the best tools for helping to solve problems in SQL Server 2000 is SQL Profiler. SQL Profiler as a problem-solving tool can show you exactly what has been sent to the SQL Server by a client application.
I have had to upgrade a SQL Server from version 6.5 to version 7.0 (yeah, I know it should have been 2000, but the client couldn't wait). The client had an old Visual Basic interface (written by someone else) and no source code available for the client application. I used SQL Profiler to trace the Transact-SQL statements that were sent to the database from the client application to ensure that the upgrade to SQL Server version 7.0 would go smoothly. The tool was invaluable, and allowed the upgrade to go as easily as possible.
Let's take a look at SQL Profiler and see what it has on offer. In this section we will set up a trace to capture the commands that the client application (Spy Net) sends to our SQL Server 2000 application.
Creating the Trace
We will start the trace and capture all (no specific) of the commands that the browser sends to our SQLSpyNet database, including login information and a basic search.
NOTE
The ability to capture information from the browser as it goes to SQL Server is one of the best forms of debugging that you can do! It is simple yet very effective, so if you are going to do any sort of front-end development, pay close attention.
SQL Profiler can be launched from within Enterprise Manager (under Tools, SQL Server Profiler) or from within the SQL Server menu group in your Start menu, by selecting Programs, Microsoft SQL Server, Profiler.
-
When you have SQL Profiler launched, the first thing you need to do is set up a trace definition. You can do this by selecting File, New, Trace, as shown in Figure 1 (or use Ctrl+N).
Figure 1 Launching the new trace definition screen.
This will prompt you for your login information so that your connection information can be validated against the database on which you want to perform a trace.
-
Fill in the login information and you will see a screen similar to that shown in Figure 2.
Figure 2 Setting the properties for the new trace definition.
Next, define the trace. As you can see on this screen, you have several options (and even more on each of the tabs). Fill in the blanks on the General tab as described in the following:
Trace Name—Allows you to enter the unique name for your trace to identify the individual traces later on. Enter Trace for Spy Net.
Trace SQL Server—Specifies the instance of SQL Server on which you want to perform a trace. Make sure the instance (if you have more than one) that contains SQLSpyNet is selected.
Template Name—Allows you to choose from a list of predefined templates that ship with SQL Server 2000. These templates are designed to assist you with the different aspects of a DBA role. For example, a SQLProfilerTuning template will assist you in tuning your SQL queries and database performance. Select the SQLProfilerStandard template.
Template File Name—This allows you to choose another template (custom written, for example) that you can use instead of the predefined ones that come with SQL Server 2000. These template files have a .tdf file extension. You do not need to change this option for our needs.
Save to File—This, as you can imagine, allows you to save the trace to a file. So if you wanted to implement auditing in your application, you could capture all events against your server/database and save the trace file to disk. You don't need to do this.
Save to Table—Alternatively, you can save your trace to a table within your database. This allows you to save the events in either an existing table or in a new table within any databases that you have access to. Like the Save to File option, you do not need to do this.
Enable Trace Stop Time—This allows you to specify how long you would like to run a trace. Leave this unchecked for now.
TIP
This is invaluable if we are auditing our application! We can specify the times that we want to trace for, meaning we can capture the peak time traffic or the after-hours potential hacker traffic!
-
Click the Events tab. As shown in Figure 3, this window allows us to specify the event classes that we want to trace against.
Figure 3 Setting the events we want to capture for the new trace definition.
The event classes allow us to capture when an event is prepared, executed, or completed for all the major Transact-SQL categories. We can capture when a stored procedure was started, recompiled, or completed, for example. For our needs though, the defaults of the SQLProfilerStandard template are fine.
NOTE
If you save your trace and review the trace properties at a later date, the only events that you will see are the captured events; the Available Event Classes box will be disabled.
-
Click The Data Columns tab, as shown in Figure 4. This dialog allows us to specify the columns of information that we want to see displayed in our trace.
Figure 4 Setting the columns we want to see for the new trace definition.
Because we are not on an NT-based system, remove the NTUserName column from the Selected Data select box. Click the NTUserName column, and then click the Remove button.
TIP
If you do not see the NTUserName column, look under the Columns group (written in bold).
To see the last and one of the most-used tabs in the Profile Trace Properties screen, click the Filters tab.
The Filters tab allows us to apply filters to our traces so that we can narrow our traces to specific databases, users, or even applications.
-
Because we are only interested in what happens to our SQLSpyNet database (in this instance), find your way to the DatabaseName column, click the plus (+) symbol, and enter SQLSpyNet in the Like box, as shown in Figure 5.
Figure 5 Setting the filters for the new trace definition.
This will restrict the filter to show only those events that occur in the SQLSpyNet database.
And that's it! Our trace definition is now ready to go. Click the Run button and the Trace will start.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
Sometimes this can take a little while, depending on the speed of your machine and how busy it is processing requests, so be patient.
When the trace starts, it will capture some basic information about the existing connections (if any), so you might notice several entries appear in the window that seem as though they are not relevant to our application.
Am I Already Connected?
What the trace is doing is logging that a connection is already established against the SQL Server. This can show you that users are already connected, so performing a large query could impact them.
If you are seeing that the trace is reporting an existing connection (considering we are in a single-user environment) you probably have Enterprise Manager, Query Analyzer, or Spy Net open, or even a combination of all three.
If you close these applications, stop the trace (by clicking the red square in the toolbar) and clear the trace window by selecting Edit, Clear Trace Window from the menu bar, you will have a fresh trace screen. Now restart the trace (by clicking the green triangle in the toolbar) and voila—no more existing connection information!
Spying on Users
So there we go; our trace is started. How do we check what our users are doing?
NOTE
Make sure you still have the SQL Profiler window open with the trace running to complete the steps in the following section.
Open the Spy Net application, and enter your login information, then go to the Search screen.
-
Perform a search. Figure 6 shows that I've performed a search for Greg and an entry is logged in the trace window.
Figure 6 Spying on our users to see what they are doing.
This shows that a user (ourselves) has executed the stored procedure PersonSearch with the parameters 'Greg' and NULL.
We can then copy this command and paste it into a Query Analyzer window to see the results that SQL Server 2000 will return for the query.
){kind=link}
TIP
You can copy the command that was sent to the SQL Server by the client application by clicking the command and then highlighting the text in the Results window. Right-click and select Copy or use the shortcut keys Ctrl+C.
See what I mean about help when you are debugging? If you can see the commands sent to the SQL Server from the client application, you can easily see what parameters are missing or check to see whether they are malformed and so forth. As you can imagine, this becomes very powerful when you continually have an error returned from a client application and you just can't figure it out! Capture the command, submit it to the SQL Server through Query Analyzer, and nine times out of ten, your problem will be resolved.