Lesson 3: Performing Monitoring Tasks

3 4

Monitoring SQL Server 2000 consists of performing various tasks to monitor levels of resource usage and specific SQL Server events. In this lesson, you will learn to use Windows 2000 System Monitor and Task Manager to monitor memory, I/O, and processor use. You will also monitor the execution of stored procedures and SQL batches using SQL Profiler. Finally, you will monitor locks using the SQL Server Enterprise Manager Current Activity window and system stored procedures.

---

After this lesson, you will be able to

• Use System Monitor and Task Manager to monitor resource usage
• Use SQL Profiler to monitor stored procedures and Transact-SQL batches
• Use SQL Profiler to monitor user activity
• Use the SQL Server Enterprise Manager Current Activity window and system stored procedures to view blocking locks and deadlocks

Estimated lesson time: 45 minutes

---

Monitoring Resource Usage

You monitor resource use (memory, I/O, and processor) to determine whether adequate resources exist, and also to determine the relative use of resources by different server processes. It is useful to test resource usage on a computer with minimal load to establish the performance baseline before you place a load on the system.

Task Manager

To monitor resource use with Task Manager, right-click the Windows taskbar and then click Task Manager. You can also press the Ctrl+Alt+Del key combination and then click the Task Manager button in the Windows Security menu. To view resource use on a per-process basis, click the Processes tab in Task Manager. See Figure 14.1.

Figure 14.1

Task Manager (Processes tab).

In the Processes tab, notice the five default columns of information that are displayed. You can sort the information displayed by clicking a column heading. Notice that in Figure 14.1, the columns are ordered based on the amount of memory used for each process. Click Select Columns on the View menu to select additional columns to appear on the Processes page. Figure 14.2 shows the Select Columns dialog box.

Figure 14.2

Selecting additional columns within Task Manager.

You can control the frequency with which the information is refreshed (or pause the display) by clicking Update Speed on the View menu in Task Manager. In the Options menu, you can control whether Task Manager always appears on top of other applications on the desktop (this is the default behavior) and also whether Task Manager appears on the Windows taskbar when minimized (default).

Click the Performance tab to view overall resource use on the computer. See Figure 14.3.

Figure 14.3

Task Manager (Performance tab).

Notice, in the Totals group box, that you can view processor use, based on handles, threads, and processes. You can also view memory use, based on committed memory (including virtual memory) in the Commit Charge (K) group box, physical memory in the Physical Memory (K) group box, and kernel memory in the Kernel Memory (K) group box. In Figure 14.3, notice that the peak committed memory is higher than the total physical memory on the computer. This indicates that this computer could benefit from additional memory.

Note

---

When Task Manager is running, the System Tray always displays the overall CPU usage value from Task Manager.

System Monitor

To monitor resource use with System Monitor, click Performance in the Administrative Tools program group. System Monitor is a snap-in within the Performance console. See Figure 14.4.

Figure 14.4

Performance MMC with the System Monitor snap-in.

System Monitor displays the counter values for selected performance objects, counters, and instances. These can be current values, a snapshot of values at a given point in time, or values from a saved Counter Log. To add counters to System Monitor, click the Add button on the toolbar to display the Add Counters dialog box. See Figure 14.5. Notice that you can use counters from the local computer, or you can select a remote computer to monitor.

Figure 14.5

Adding counters to System Monitor.

You can view counter values as a chart, histogram, or report by clicking the corresponding button on the toolbar. See Figures 14.6, 14.7, and 14.8.

Figure 14.6

Chart view of System Monitor.

Figure 14.7

Histogram view of System Monitor.

Figure 14.8

Report view of System Monitor.

Select a counter and then click the Highlight button on the toolbar (or press Ctrl+H on your keyboard) to highlight the counter in white in the chart or histogram view. You can only highlight one counter at any given time. Click the Freeze Display button on the toolbar to freeze the counter values at a particular point for further analysis. Click the Properties button on the System Monitor toolbar (not the Performance MMC toolbar) to alter the properties of System Monitor. Properties include update frequency (default is 1 second) and display characteristics.

To create a log for later review, expand Performance Logs And Alerts, right-click Counter Logs, and then click New Log Settings. You will be prompted to enter the name of the new log file in the New Log Settings dialog box, and then the NewLogFile dialog box appears, as shown in Figure 14.9.

You can create a log file definition containing the counters to be logged, the sampling interval, the file size (including enabling file rollover), and a logging schedule.

Memory Objects and Counters

You should monitor your computer to determine whether there is adequate memory on the computer for the processes that are running. Indications of insufficient memory are a lack of available memory and hard disk paging. Multiple counters must be interpreted together. You might also need to determine which processes are using memory and to isolate the memory used by SQL Server. This information is useful for setting minimum and maximum memory values for SQL Server when sharing the computer with other server applications.

Figure 14.9

Creating a memory counter log in System Monitor.

Table 14.7 describes the most important memory counters to monitor and provides help in interpreting values received.

Note

---

You might need to use LogicalDisk counters rather than PhysicalDisk counters if you have multiple logical partitions on a single physical disk. Whereas physical disk counters are enabled by default, logical disk counters are not. Use the Diskperf -yv command to enable logical disk counters (and to reboot the system).

I/O Objects and Counters

Overloaded disk subsystems are one of the most common performance problems with SQL Server installations. I/O-bound disks cause disk queuing and a general degradation of overall system performance. This problem is solved, in most cases, by adding additional disks to RAID or by implementing RAID. However, insufficient memory and inefficient queries can also cause excessive disk I/O. Table 14.8 describes the most important I/O object counters to monitor and provides help on interpreting values received.

Processor Objects and Counters

Inadequate processor resources are also a common performance problem. Additional processors or a faster processor can solve the problem. However, inadequate memory (causing excessive paging and processor use) or inefficient statements (generating excessive processor use) can also be the cause of the performance bottleneck. Table 14.9 describes the most important processor object counters to monitor and provides help on interpreting values received.

Table 14.7 Memory Object Counters

Object Counter	This Object Counter Reports . . .	How to Interpret. . .
Memory \ Available Mbytes	Megabytes of memory currently available for use.	A low value can indicate a shortage of memory or an application failing to release memory.
Memory \ Pages/sec	Number of pages retrieved from disk or written to free space in the working set on the disk because of hard page faults.	A high value (above 20) can indicate excessive hard disk paging because of a memory shortage.
PhysicalDisk \ Avg. Disk Queue Length	Average number of both read and write requests that were queued.	If an increase in disk queue length is not accompanied by a decrease in memory paging, a memory shortage exists.
Memory \ Page Faults/sec	The overall rate that faulted pages are handled by the processor.	A high value for overall page faults/sec coinciding with a low value for the SQL Server instance indicates that SQL Server is not causing the memory shortage.
Process \ Page Faults/sec for the SQL Server instance	The rate faulted pages occur because of the SQL Server process for a given SQL Server instance.	A high value for overall page faults/sec coinciding with a low value for the SQL Server instance indicates that SQL Server is not causing the memory shortage.
SQL Server: Memory Manager \ Total Server Memory (KB)	Total amount of dynamic memory SQL Server is currently using for its memory buffer.	If this value is consistently close to the total amount of physical memory of the computer (or the configured maximum memory value), more memory might be needed.
Process \ Working Set for the SQL Server instance	Total number of current bytes in the Working Set for the SQL Server instance.	Use this value to determine the maximum memory needed for SQL Server with the current load.
SQL Server: Buffer Manager \ Buffer Cache Hit Ratio	Percentage of pages found in the memory buffer pool without having to incur a read from disk.	This value should generally be above 90%. If not, more memory is generally needed.
SQL Server: Buffer Manager \ Total Pages	Total number of pages in the buffer pool (including data, free, and stolen pages).	A low value can indicate a shortage of memory available for the buffer pool.

Table 14.8 I/O Object Counters

Object Counter	This Object Counter Reports . . .	How to Interpret. . .
PhysicalDisk \ % Disk Time	Percentage of elapsed time during which the hard disk is busy servicing read or write requests.	A low rate of disk paging coinciding with a high rate of disk usage and disk queuing indicates a disk bottleneck. Can be over 100% if using a RAID device or an intelligent disk controller.
PhysicalDisk \ Avg. Disk Queue Length	Average number of both read and write requests that were queued.	A low rate of disk paging coinciding with a high rate of disk usage and disk queuing indicates a disk bottleneck. A disk queue above 1.5 to 2 times the number of disk spindles indicates a disk bottleneck.
PhysicalDisk\ Current Disk Queue Length	Instantaneous number of both read and write requests that are queued.	Use in conjunction with the PhysicalDisk\ Avg. Disk Queue Length to determine whether a disk bottleneck exists.
PhysicalDisk \ Avg. Disk/sec Write	Average time to write data to disk (disk latency).	A disk latency value above 15 to 20 milliseconds indicates a disk bottleneck.
PhysicalDisk \ Avg. Disk/sec Read	Average time to read data from disk.	A disk latency value above 15 to 20 milliseconds indicates a disk bottleneck.
PhysicalDisk \ Disk Writes/sec	Rate of write operations.	If the rate of disk writes plus disk reads is not close to the capacity of the hard disk and disk latency is high, a faulty disk is likely. If the combined rate is close to the capacity, a disk bottleneck is likely.
PhysicalDisk \ Disk Reads/sec	Rate of read operations.	If the rate of disk writes plus disk reads is not close to the capacity of the hard disk and disk latency is high, a faulty disk is likely. If the combined rate is close to the capacity, a disk bottleneck is likely.

Table 14.9 Processor Object Counters

Object Counter	This Object Counter Reports . . .	How to Interpret. . .
Processor \ % Processor Time	Percentage of time the processor spent executing non-idle threads.	Rates above 75% generally indicate a processor bottleneck. Systems with values above 60% can generally benefit from more processor power.
System \ Processor Queue Length	Number of threads in the processor queue.	A sustained processor queue above two threads generally indicates a processor bottleneck.

Practice: Monitoring System Resources Using System Monitor and Task Manager

In this practice you use System Monitor and Task Manager to monitor system resource use.

To monitor system resources using System Monitor and Task Manager

1. Ensure that you are logged on to the SelfPacedSQL.MSFT domain controller as Administrator.
2. Minimize all running applications.
3. Right-click the Windows taskbar and then click Task Manager.

   Windows Task Manager appears.

4. Click the Performance tab.

   Notice the overall values for process and memory use. In particular, note the delta between Total Physical Memory and both the Total Commit Charge and the Peak Commit Charge. These indicators will tell you if you have an overall memory shortage on your computer.

5. On the Options menu, click Hide When Minimized and then minimize Windows Task Manager.
6. Click Start and then click Run.
7. In the Open drop-down combo box, type C:\SelfPacedSQL\CH_14\Monitor.msc, and then click OK.

   A preconfigured Performance console appears displaying a number of performance object counters in the Report view. Review the displayed counters.

8. On the toolbar, click the Freeze Display button.

   You will use this frozen display to compare values with a SQL Server load and without a SQL Server load.

9. Click Start and then click Run.
10. In the Open drop-down combo box, type C:\SelfPacedSQL\CH_14 \Monitor.msc and then click OK.

    A second version of the same preconfigured Performance console appears.

11. Right-click the taskbar and then click Tile Windows Vertically.

    The two Performance consoles are displayed side by side.

12. Click Start and then click Run.
13. In the Open drop-down combo box, type C:\SelfPacedSQL\CH_14\Load.bat, and then click OK.

    The OSQL command-prompt utility runs the LoadInLoop.sql command in the Command Prompt window.

14. Minimize the Command Prompt window.

    Notice the effect of the load on the performance object counters. Compare the counters between the frozen instance of System Monitor and the unfrozen instance. Notice the load on the disk. Determine whether you have a memory shortage on your computer or the processor needs additional power.

15. Double-click Task Manager in the system tray.

    Windows Task Manager appears.

    Notice the overall values for process and memory use. In particular, notice how the delta between Total Physical Memory and both the Total Commit Charge and the Peak Commit Charge changed. Does your system have a memory shortage?

16. After the OSQL command in the Command Prompt window finishes, notice the reduced load on the computer.
17. Close the Windows Task Manager and both copies of the Performance console.

Monitoring Stored Procedures, Transact SQL Batches, and User Activity

To monitor stored procedures and Transact-SQL batches, click Profiler in the Microsoft SQL Server program group. See Figure 14.10.

Figure 14.10

SQL Profiler.

You can create a new trace, create a new template, or open an existing trace file for analysis and replay. To create a new trace, click the New Trace button on the toolbar (or point to New and then click Trace in the File menu) and then, in the Connect To SQL Server dialog box, connect to the SQL Server instance on which you want to trace SQL Server events. The Trace Properties dialog box then appears, as shown in Figure 14.11.

Figure 14.11

SQL Profiler Trace properties (General tab).

In the General tab, you can create a new trace definition or use one of the preconfigured trace templates. In the Trace Name text box, use a descriptive naming convention for each new trace definition you create. You can choose to save the captured trace information to a file or table, and set a maximum size for the captured data. If you save the captured trace information to a file, notice that the default is to enable file rollover (this creates a new file when the maximum size is reached). You can also enable a stop time for the trace.

In the Events tab, you can choose SQL Server events (event classes) from various categories of events. Certain event classes will already be selected based on the initial template selected. See Figure 14.12.

In the Data Columns tab, you can choose to add (or subtract) to the default data columns to capture the information you want. You will want different types of information for different types of traces. By moving one or more data columns up to the Groups category, you can group the output by that data column. You move data columns up by clicking the Up button. You can also order the data columns in the output, by clicking the Up button or the Down button. See Figure 14.13.

In the Filters tab, you can choose to include or exclude various types of events. Notice that, by default, SQL Profiler events are not captured. See Figure 14.14. You might also want to exclude all events related to the domain user account of the SQL Server service.

Figure 14.12

SQL Profiler Trace Properties (Events tab).

Figure 14.13

SQL Profiler Trace Properties (Data Columns tab).

Figure 14.14

SQL Profiler Trace Properties (Filters tab).

You can also select the Exclude System IDs check box to exclude SQL events referencing system objects. This will generally capture the information you want to analyze and will significantly reduce the size of your trace because system objects that are being accessed can result in 50 to 75 percent of the trace events. Click the Run button to start the trace.

After a trace has been captured, you can search within the trace for specified strings (by clicking the Find String button on the toolbar). You can also choose to save the template for later use or save the data captured for later analysis and comparison by clicking Save As on the File menu.

You should create separate trace templates for different types of traces.

• Long-running queries—Capture all data columns related to the TSQL and Stored Procedure event classes and then group by Duration and filter by length of time.
• Stored procedure performance—Capture all data columns related to the selected Stored Procedure event classes for a specified stored procedure (using the ObjectID event criteria) or for all stored procedures, and then group by ClientProcessID.
• Cause of a deadlock—Capture all data columns related to selected TSQL and Stored Procedure event classes, and group by EventClass. Use the Database ID event criteria to limit to a specified database.
• Login and logouts—Capture the EventClass, EventSubClass, LoginSID, and Login data columns for the Security Audit\Audit Login event class.
• Individual user activity—Capture all data columns related to the Sessions\ExistingConnection, and TSQL event classes and group by DBUserName.

Practice: Monitoring SQL Batches and Stored Procedures

In this practice you use SQL Profiler to monitor Transact-SQL batches and stored procedures.

To monitor SQL batches and stored procedures

1. Ensure that you are logged on to the SelfPacedSQL.MSFT domain controller as Administrator.
2. Click Start, point to Programs, point to Microsoft SQL Server, and then click Profiler.

   SQL Profiler appears.

3. On the toolbar, click the New Trace button.

   The Connect To SQL Server dialog box appears.

4. Make sure that the Windows Authentication option button is selected, and then click OK to connect to the default instance on SelfPacedCPU.

   The Trace Properties dialog box appears.

5. In the Trace Name text box, type Duration.
6. In the Template Name drop-down list, click SQLProfilerTSQL_Duration and then click the Events tab.

   Notice that the only event classes being traced are RPC:Completed and SQL:BatchCompleted.

7. Click the Data Columns tab.

   Notice that the data columns selected are being grouped by EventClass and then by Duration.

8. Click the Filters tab.

   Notice that events generated by SQL Profiler are being excluded.

9. Expand DatabaseName and then expand Like.
10. Type Northwind in the Like text box.
11. Expand Duration and then expand Greater Than Or Equal.
12. Type 100 in the Great Than Or Equal text box.
13. Click the Run button.

    Notice that the Duration trace starts.

14. On the toolbar, click the SQL Query Analyzer button.

    The Connect To SQL Server dialog box appears.

15. Make sure that the Windows Authentication option button is selected, and then click OK to connect to the default instance on SelfPacedCPU.

    SQL Query Analyzer appears.

16. On the toolbar, click the Load SQL Script button.

    The Open Query File dialog box appears.

17. Open Duration.sql in the C:\SelfPacedSQL\CH_14 folder.

    A Transact-SQL script appears that performs a variety of SELECT statements, which will take differing amounts of time to complete.

18. On the toolbar, click the Execute Query button.
19. Switch to SQL Profiler.

    Notice the SELECT statements that appear in the trace.

20. Click the longest-running SELECT statement.

    Notice that the Transact-SQL statement executed appears in the lower pane.

21. On the toolbar, click the Properties button.

    The Trace Properties dialog box appears, displaying the trace properties for the Duration trace.

22. Click the Filters tab.

    Notice that the existing filters are displayed. Also notice that you cannot modify a running trace.

23. Click Cancel.
24. On the toolbar, click the Stop Selected Trace button.
25. Close SQL Profiler, but leave the SQL Query Analyzer running.

Monitoring Current Locking and User Activity

To view current locking and user activity in SQL Server Enterprise Manager, expand the Management container for the instance and then expand the Current Activity container. See Figure 14.15.

Notice that there are three containers: Process Info, Locks/Process ID, and Locks/Object. In the console tree, click the Process Info container to view detailed information in the details pane regarding all current connections and processes. See Figures 14.16 and 14.17.

Note

---

To update the information displayed, right-click the Current Activity container and then click Refresh.

Figure 14.15

The Current Activity window.

Figure 14.16

Current Activity window (Process Info—left half).

Figure 14.17

Current Activity window (Process Info—right half).

The information available in the Process Info container is described in Table 14.10.

Table 14.10 Information in the Process Info Container

Column	Description
Process ID	SQL Server Process ID (SPID) of the process.
Context ID	Execution context ID (ECID) of a subthread operating on behalf of the process.
User	User ID of the user who executed the command that initiated the process.
Database	Current database context of the process (certain system processes will have no database context).
Status	Process status (running, sleeping, runnable, or background) of the process.
Open Transactions	Number of open transactions for the process.
Command	SQL Server command currently executing for the process.
Application	Name of the application program being used by the process.
Wait Time	Wait time (in milliseconds), if any, for the process.
Wait Type	A string indicating the current or last wait type for the process.
Wait Resource	Textual representation of a lock resource, such as a row identifier (RID) of the process.
CPU	Cumulative processor time for the process.
Physical IO	Cumulative disk reads and writes for the process.
Memory Usage	Number of pages in the procedure cache that are currently allocated to this process. A negative number indicates pages being freed for another process.
Login Time	Time a client process logged into the server. For server processes, the time the server started.
Last Batch	Last time a client process executed an EXECUTE statement or a remote stored procedure call. For server processes, the time the server started.
Host	Name of the computer that initiated the process.
Network Library	Net-library used by the client to initiate the process.
Network Address	Network address (the Message Authentication Code [MAC] address) for the network interface card (NIC) on the client computer that initiated the process.
Blocked By	SPID of a blocking process for the process.
Blocking	SPID of process being blocked by the process.

The Locks/Process ID container displays each active process. Expand the Locks/Process ID container and then click an active process in the console tree to view the locks held by the process. See Figures 14.18 and 14.19.

Notice that SPID 53 is blocking SPID 56. SPID 53 has been granted an exclusive row lock on the same resource on which SPID 56 is waiting for a lock. For a complete list of the types and modes of locks, refer to the topic "Monitoring with SQL Server Enterprise Manager" in SQL Server Books Online. To view the most recent command issued by the blocking process, right-click the process ID and then click Properties to display the Process Details dialog box. See Figure 14.20.

Figure 14.18

Locks/Process ID information for a blocking process.

Figure 14.19

Locks/Process ID information for a blocked process.

Figure 14.20

Last TSQL command by the blocking process.

In Figure 14.20, notice that the most recent TSQL command batch began a transaction but did not complete the transaction because this open transaction is blocking other processes. To resolve a blocking lock or a deadlock (in the short term), the database administrator can either click the Send Message button to send a message to the user who initiated the blocking process or click the Kill Process button to kill the process directly.

Note

---

In general, applications should be coded to acquire shared locks rather than exclusive locks when waiting for user input.

The Locks/Object container displays each database object that is locked, from the row and table level up to the database level. See Figure 14.21.

Notice that three processes have locks on the Customer table in the SSEMDB database. Process ID 53 has an exclusive row lock, and process IDs 55 and 56 are waiting to place exclusive row locks on the same row.

Figure 14.21

Locks/object information for a locked object.

Practice: Monitoring Blocking Problems Using the Current Activity Window and System Stored Procedures

In this practice you use the SQL Server Enterprise Manager and system stored procedures to monitor blocking problems.

To monitor blocking problems using the Current Activity window and system stored procedures

1. Ensure that you are logged on to the SelfPacedSQL.MSFT domain controller as Administrator.
2. Click Start, point to Programs, point to Microsoft SQL Server, and then click Enterprise Manager.
3. Expand the Microsoft SQL Servers container, expand the SQL Server Group container, expand the SelfPacedCPU container, expand the Management container, expand the Current Activity container, and then click Process Info.

   The Process Info details are displayed in the details pane. If you do not see the details, right-click Process Info, point to View, and then click Detail.

4. In the details pane, click the User column to sort the user processes by user name.

   Notice two user processes for SelfPacedSQL\Administrator: one for the existing connection by SQL Server Enterprise Manager to the master database and one for the existing connection by SQL Query Analyzer to the Northwind database. Note the Process ID number for the connection by SQL Query Analyzer.

5. Switch to SQL Query Analyzer.
6. On the toolbar, click the Load SQL Script button.

   The Open Query File dialog box appears.

7. Open BlockLock.sql in the C:\SelfPacedSQL\CH_14 folder.

   A Transact-SQL script appears that will begin a transaction to update the ContactName for a particular CustomerID. It also executes the sp_lock system stored procedure.

8. On the toolbar, click the Execute Query button.

   Notice the information returned from the sp_lock system stored procedure. In particular, note the locks granted to the SQL Query Analyzer SPID and note in particular the exclusive row lock granted to this process.

9. On the File menu, click Connect.

   The Connect To SQL Server dialog box appears.

10. Make sure that the Windows Authentication option button is selected, and then click OK to connect to the default instance on SelfPacedCPU.
11. On the toolbar, click the Load SQL Script button.

    The Open Query File dialog box appears.

12. Open BlockLock2.sql in the C:\SelfPacedSQL\CH_14 folder.
13. The BlockLock2.sql query appears. This query updates the same customer record, but does not leave the transaction open.
14. On the toolbar, click the Execute Query button.

    Notice that the query does not complete its execution.

15. Switch to SQL Server Enterprise Manager.
16. In the console tree, right-click the Current Activity container and then click Refresh.
17. In the details pane, double-click Locks/Process ID.

    Notice that the first process is blocking the second process.

18. Right-click the blocking process and then click Properties.

    The Process Details dialog box appears displaying the last TSQL command batch executed by the blocking process.

19. Click the Send Message button.

    The Send Message - SelfPacedCPU dialog box appears.

20. In the Message text box, type Your application is blocking. Please close your open transaction. Then click the the Send button.

    A Send Message message box appears stating that the message was successfully sent and a Messenger Service message box appears containing the message (one message box will appear behind the other message box).

21. Click OK in each of these message boxes to close the message boxes.
22. In the Process Details dialog box, click the Close button.
23. In the console tree, click the process that is blocked.

    In the details pane, notice in the Status column that the lock request for a row lock is waiting.

24. In the console tree, expand the Locks/Object container and then click SSEMDB.dbo.Customer.

    In the details pane, notice the two row locks. The first process was granted an exclusive row lock and the second process is waiting.

25. Switch to SQL Query Analyzer.

    Notice that the second query still has not completed.

26. Switch to the first connection.
27. Highlight ROLLBACK TRAN and then click the Execute Query button on the toolbar.

    Switch to the second query. Notice that it has now executed successfully. Also notice that the second query does not hold any exclusive locks at the end of the transaction.

28. Switch to SQL Server Enterprise Manager.
29. In the console tree, right-click the Current Activity container and then click Refresh.
30. In the details pane, double-click Locks/Process ID.

    Notice that no blocking locks or blocked processes appear.

31. Close SQL Server Enterprise Manager and SQL Query Analyzer.

Lesson Summary

When monitoring SQL Server performance and activity, determine the monitoring task and then select the appropriate tool. Rather than monitoring for everything all at once, perform specific and limited monitoring tasks. Repeat these same tasks over time to establish your evolving baseline. Use the SQL Server Enterprise Manager Current Activity window to manage deadlocks and to view current blocking locks.