ptg 1354 end as object, convert(varchar(12), resource_type) as resrc_type, convert(varchar(12), request_type) as req_type, convert(char(1), request_mode) as mode, convert(varchar(8), request_status) as status from sys.dm_tran_locks order by request_session_id, 3 desc go spid db_name object resrc_type req_type mode status 52 msdb 0 DATABASE LOCK S GRANT 55 bigpubs2008 titles OBJECT LOCK I GRANT 55 bigpubs2008 sales_qty_rollup OBJECT LOCK X GRANT 55 bigpubs2008 sales OBJECT LOCK X GRANT 55 bigpubs2008 679707671068672 PAGE LOCK I GRANT 55 bigpubs2008 679707671068672 KEY LOCK X GRANT 55 bigpubs2008 398232694358016 KEY LOCK X GRANT 55 bigpubs2008 398232694358016 PAGE LOCK I GRANT 55 bigpubs2008 0 DATABASE LOCK S GRANT 56 msdb 0 DATABASE LOCK S GRANT 58 bigpubs2008 sales OBJECT LOCK I WAIT 58 bigpubs2008 0 DATABASE LOCK S GRANT Note that the query in Listing 37.1 contains a CASE expression for displaying the object name. If the resource type is OBJECT and the database ID of the locked resource is the same as the current database context, it returns the object name; otherwise, it returns the object ID because the object_name() function operates only in the current database context. TIP To save yourself the trouble of having to type in the query listed in Listing 37.1, or hav- ing to read it in from a file each time you want to run it, you might want to consider cre- ating your own stored procedure or view that invokes this query. NOTE In SQL Server 2005, you could monitor lock activity via the Activity Monitor in SQL Server Management Studio (SSMS). If you’re looking for this tool in SQL Server 2008, you won’t find it. For some reason, this feature was removed from SSMS in SQL Server 2008. The only locking information provided by the SSMS Activity Monitor in SQL Server 2008 is the indication of lock blocking and wait time provided by the Process Monitor and the Lock Waits information provided by the Resource Waits Monitor. There is no GUI-based lock monitoring tool provided with SQL Server 2008 to display the spe- cific locks being held by processes or the locks being held on objects as there was in SQL Server 2005. CHAPTER 37 Locking and Performance ptg 1355 Monitoring Lock Activity in SQL Server 37 Viewing Locking Activity with SQL Server Profiler Another tool to help you monitor locking activity in SQL Server 2008 is SQL Server Profiler. SQL Server Profiler provides a number of lock events that you can capture in a trace. The trace information can be viewed in real-time or saved to a file or database table for further analysis at a later date. Saving the information to a table allows you to run different reports on the information to help in the analysis. NOTE This chapter provides only a brief overview of how to capture and view locking informa- tion using SQL Server Profiler. For more information on the features and capabilities of SQL Server Profiler and how to use it, see Chapter 6, “SQL Server Profiler.” SQL Profiler provides the following lock events that can be captured in a trace: . Lock:Acquired—Indicates when a lock on a resource, such as a data page or row, has been acquired. . Lock:Cancel—Indicates when the acquisition of a lock on a resource has been canceled (for example, as the result of a deadlock). . Lock:Deadlock—Indicates when two or more concurrent processes have dead- locked with each other. . Lock:Deadlock Chain—Provides the information for each of the events leading up to a deadlock. This information is similar to that provided by the 1204 trace flag, which is covered in the “Deadlocks” section, later in this chapter. . Lock:Escalation—Indicates when a lower-level lock has been converted to a higher-level lock (for example, when page-level locks are escalated to table-level locks). . Lock:Released—Indicates that a process has released a previously acquired lock on a resource. . Lock:Timeout—Indicates that a lock request that is waiting on a resource has timed out due to another transaction holding a blocking lock. . Lock:Timeout (timeout >0)—Is similar to Lock:Timeout but does not include any events where the lock timeout is 0 seconds. . Deadlock Graph—Generates an XML description of a deadlock. Figure 37.1 shows an example of choosing a set of locking events to monitor with SQL Server Profiler. ptg 1356 SQL Server Profiler also provides a number of data values to display for the events being monitored. You might find the following data columns useful when monitoring locking activity: . spid—The process ID of the process that generated the event. . EventClass—The type of event being captured. . Mode—For lock monitoring, the type of lock involved in the captured event. . ObjectID—The ID of the object involved in the locking event—that is, the object that the lock is associated with. . DatabaseID—The ID of the database involved in the locking event . TextData—The query that generated the lock event. . LoginName—The login name associated with the process. . ApplicationName—The name of the application generating the lock event. Keep in mind that many internal system processes also acquire locks in SQL Server. If you want to filter out those processes and focus on specific processes, users, or applications, you use the filters in SQL Server Profiler to include the information you want to trace or exclude the information you don’t want to trace (see Figure 37.2). After you set up your events, data columns, and filters, you can begin the trace. Figure 37.3 shows an example of the type of information captured. CHAPTER 37 Locking and Performance FIGURE 37.1 Choosing lock events in SQL Server Profiler. ptg 1357 Monitoring Lock Activity in SQL Server 37 FIGURE 37.2 Filtering out unwanted information in SQL Server Profiler. Monitoring Locks with Performance Monitor Another method of monitoring locking in SQL Server is through the Performance Monitor. The sys.dm_tran_locks view and SSMS Activity Monitor provide a snapshot of the actual locks currently in effect in SQL Server. If you want to monitor the locking activity as a whole on a continuous basis, you can use the Windows Performance Monitor and monitor the counters available for the SQLServer:Locks performance object (see Figure 37.4). FIGURE 37.3 Lock information captured in a SQL Server Profiler trace. ptg 1358 FIGURE 37.4 Choosing counters for the SQLServer:Locks performance object in Performance Monitor. NOTE If you are monitoring a SQL Server 2008 named instance rather than a default instance of SQL Server 2008, the SQL Server performance counters are listed under the name of the SQL Server instance rather than under the generic SQLServer perfor- mance counters. You can use the SQLServer:Locks object to help detect locking bottlenecks and contention points in the system as well as to provide a summary of the overall locking activity in SQL Server. You can use the information that Performance Monitor provides to identify whether locking problems are the cause of any performance problems. You can then take appropriate corrective actions to improve concurrency and the overall performance of the system. The counters that belong to the SQLServer:Locks object are as follows: . Average Wait Time—This counter represents the average wait time (in milliseconds) for each lock request. A high value is an indication of locking contention that could be affecting performance of concurrent processes. . Lock Requests/sec—This counter represents the total number of new locks and lock conversion requests made per second. A high value for this counter is not necessarily a cause for alarm; it might simply indicate a system with a high number of concur- rent users. . Lock Timeouts (timeout > 0)/sec—This counter is similar to the LockTimeouts/sec counter but does not include NOWAIT lock requests that time out immediately. CHAPTER 37 Locking and Performance ptg 1359 SQL Server Lock Types 37 . Lock Timeouts/sec—This counter represents the total number of lock timeouts per second that occur for lock requests on a resource that cannot be granted before the lock timeout interval is exceeded. By default, a blocked process waits indefinitely unless the application specifies a maximum timeout limit, using the SET LOCK_TIMEOUT command. A high value for this counter might indicate that the timeout limit is set to a low value in the application or that you are experiencing excessive locking contention. . Lock Wait Time—This counter represents the cumulative wait time for each lock request. It is given in milliseconds. A high value here indicates that you might have long-running or inefficient transactions that are causing blocking and locking contention. . Lock Waits/sec—This counter represents the total number of lock requests gener- ated per second for which a process had to wait before a lock request on a resource was granted. A high value might indicate inefficient or long-running transactions or a poor database design that is causing a large number of transactions to block one another. . Number of Deadlocks/sec—This number represents the total number of lock requests per second that resulted in deadlocks. Deadlocks and ways to avoid them are discussed in the “Deadlocks” section, later in this chapter. For more information on using Windows Performance Monitor for monitoring SQL Server performance, see Chapter 39, “Monitoring SQL Server Performance.” SQL Server Lock Types Locking is handled automatically in SQL Server. The Lock Manager chooses the type of lock, based on the type of transaction (such as SELECT, INSERT, UPDATE, or DELETE). Lock Manager uses the following types of locks: . Shared locks . Update locks . Exclusive locks . Intent locks . Schema locks . Bulk update locks In addition to choosing the type of lock, the Lock Manager in SQL Server 2008 automati- cally adjusts the granularity of the locks (for example, row, page, table), based on the nature of the statement that is executed and the number of rows that are affected. ptg 1360 CHAPTER 37 Locking and Performance Shared Locks By default, SQL Server uses shared locks for all read operations. A shared lock is, by defini- tion, not exclusive. Theoretically, an unlimited number of shared locks can be held on a resource at any given time. In addition, shared locks are unique in that, by default, a process locks a resource only for the duration of the read on the resource (row, page, or table). For example, the query SELECT * from authors locks the first row in the authors table when the query starts. After the first row is read, the lock on that row is released, and a lock on the second row is acquired. After the second row is read, its lock is released, and a lock on the third row is acquired, and so on. In this fashion, a SELECT query allows other data rows that are not being read to be modified during the read operation. This increases concurrent access to the data. Shared locks are compatible with other shared locks as well as with update locks. A shared lock does not prevent the acquisition of additional shared locks or an update lock by other processes on a given row or page. Multiple shared locks can be held at any given time, for a number of transactions or processes. These transactions do not affect the consistency of the data. However, shared locks do prevent the acquisition of exclusive locks. Any transaction attempting to modify data on a page or a row on which a shared lock is placed is blocked until all the shared locks are released. NOTE It is important to note that within a transaction running at the default isolation level of Read Committed, shared locks are not held for the duration of the transaction or even the duration of the statement that acquires the shared locks. Shared lock resources (row, page, table, and so on) are normally released as soon as the read operation on the resource is completed. SQL Server provides the HOLDLOCK clause for the SELECT statement, which you can use if you want to continue holding the shared lock for the duration of the transaction. HOLDLOCK is explained later in this chapter, in the section “Table Hints for Locking.” Another way to hold shared locks for the duration of a trans- action is to set the isolation level for the session or the query to Repeatable Read or Serializable Reads. Update Locks Update locks are used to lock rows or pages that a user process intends to modify. When a transaction tries to update a row, it must first read the row to ensure that it is modifying the appropriate record. If the transaction were to put a shared lock on the resource initially, it would eventually need to get an exclusive lock on the resource to modify the record and prevent any other transaction from modifying the same record. The problem is that this could lead to deadlocks in an environment in which multiple transactions are trying to modify data on the same resource at the same time. Figure 37.5 demonstrates how deadlocks can occur if lock conversion takes place from shared locks to exclusive locks. When both processes attempt to escalate the shared lock they both hold on a resource to an exclusive lock, it results in a deadlock situation. ptg 1361 SQL Server Lock Types 37 Update locks in SQL Server are provided to prevent this kind of deadlock scenario. Update locks are partially exclusive in that only one update lock can be acquired at a time on any resource. However, an update lock is compatible with shared locks, in that both can be acquired on the same resource simultaneously. In effect, an update lock signifies that a process wants to change a record, and it keeps out other processes that also want to change that record. However, an update lock allows other processes to acquire shared locks to read the data until the UPDATE or DELETE statement is finished locating the records to be affected. The process then attempts to escalate each update lock to an exclusive lock. At this time, the process waits until all currently held shared locks on the same records are released. After the shared locks are released, the update lock is escalated to an exclusive lock. The data change is then carried out, and the exclusive lock is held for the remainder of the transaction. NOTE Update locks are not used just for update operations. SQL Server uses update locks any time a search for data is required prior to performing the actual modification, such as with qualified updates and deletes (that is, when a WHERE clause is specified). Update locks are also used for insertions into a table with a clustered index because SQL Server must first search the data and clustered index to identify the correct posi- tion at which to insert the new row to maintain the sort order. After SQL Server has found the correct location and begins inserting the record, it escalates the update lock to an exclusive lock. Exclusive Locks As mentioned earlier, an exclusive lock is granted to a transaction when it is ready to perform data modifications. An exclusive lock on a resource makes sure no other transac- tion can interfere with the data locked by the transaction that is holding the exclusive lock. SQL Server releases the exclusive lock at the end of the transaction. Transaction 1 Update T1 SET coll=Coll Acquires SHARED lock Needs an EXCLUSIVE lock Waits for Lock Release by Transaction 2 Transaction 2 Update T1 SET coll=Coll + 1 Acquires SHARED lock Needs an EXCLUSIVE lock Waits for Lock Release by Transaction 1 FIGURE 37.5 A deadlock scenario with shared and exclusive locks. ptg 1362 CHAPTER 37 Locking and Performance Exclusive locks are incompatible with other lock types. If an exclusive lock is held on a resource, any other read or data modification request for the same resource by other processes is forced to wait until the exclusive lock is released. Likewise, if a resource currently has read locks held on it by other processes, the exclusive lock request is forced to wait in a queue for the resource to become available. Intent Locks Intent locks do not really constitute a locking mode; rather, they act as a mechanism to indicate at a higher level of granularity the types of locks held at a lower level. The types of intent locks mirror the lock types previously discussed: shared intent locks, exclusive intent locks, and update intent locks. SQL Server Lock Manager uses intent locks as a mechanism to indicate that a shared, update, or exclusive lock is held at a lower level. For example, a shared intent lock on a table by a process signifies that the process currently holds a shared lock on a row or page within the table. The presence of the intent lock prevents other transactions from attempting to acquire a table-level lock that would be incompatible with the existing row or page locks. Intent locks improve locking performance by allowing SQL Server to examine locks at the table level to determine the types of locks held on the table at the row or page level rather than searching through the multiple locks at the page or row level within the table. Intent locks also prevent two transactions that are both holding locks at a lower level on a resource from attempting to escalate those locks to a higher level while the other transac- tion still holds the intent lock. This prevents deadlocks during lock escalation. You typically see three types of intent locks when monitoring locking activity: intent shared ( IS) locks, intent exclusive (IX) locks, and shared with intent exclusive (SIX) locks. An IS lock indicates that the process currently holds, or has the intention of holding, shared locks on lower-level resources (row or page). An IX lock indicates that the process currently holds, or has the intention of holding, exclusive locks on lower-level resources. An SIX (pronounced as the letters S-I-X, not like the number six) lock occurs under special circumstances when a transaction is holding a shared lock on a resource, and later in the transaction, an IX lock is needed. At that point, the IS lock is converted to an SIX lock. In the following example, the SELECT statement running at the serializable level acquires a shared table lock. It then needs an exclusive lock to update the row in the sales_big table: SET TRANSACTION ISOLATION LEVEL serializable go BEGIN TRAN select sum(qty) FROM sales_big UPDATE sales_big SET qty = 0 WHERE sales_id = 1001 COMMIT TRAN ptg 1363 SQL Server Lock Types 37 Because the transaction initially acquired a shared (S) table lock and then needed an exclusive row lock, which requires an intent exclusive ( IX) lock on the table within the same transaction, the S lock is converted to an SIX lock. NOTE If only a few rows were in sales_big, SQL Server might acquire only individual row or key locks rather than a table-level lock. SQL Server would then have an intent shared ( IS) lock on the table rather than a full shared (S) lock. In that instance, the UPDATE statement would then acquire a single exclusive lock to apply the update to a single row, and the X lock at the key level would result in the IS locks at the page and table levels being converted to an IX lock at the page and table level for the remainder of the transaction. Schema Locks SQL Server uses schema locks to maintain structural integrity of SQL Server tables. Unlike other types of locks that provide isolation for the data, schema locks provide isolation for the schema of database objects, such as tables, views, and indexes within a transaction. The Lock Manager uses two types of schema locks: . Schema stability locks—When a transaction is referencing either an index or a data page, SQL Server places a schema stability lock on the object. This ensures that no other process can modify the schema of an object—such as dropping an index or dropping or altering a stored procedure or table—while other processes are still refer- encing the object. . Schema modification locks—When a process needs to modify the structure of an object (for example, alter the table, recompile a stored procedure), the Lock Manager places a schema modification lock on the object. For the duration of this lock, no other transaction can reference the object until the changes are complete and com- mitted. Bulk Update Locks A bulk update lock is a special type of lock used only when bulk copying data into a table using the bcp utility or the BULK INSERT command. This special lock is used for these operations only when either the TABLOCK hint is specified to bcp or the BULK INSERT command or when the table lock on bulk load table option has been set for the table. Bulk update locks allow multiple bulk copy processes to bulk copy data into the same . Lock Activity in SQL Server 37 Viewing Locking Activity with SQL Server Profiler Another tool to help you monitor locking activity in SQL Server 2008 is SQL Server Profiler. SQL Server Profiler. you are monitoring a SQL Server 2008 named instance rather than a default instance of SQL Server 2008, the SQL Server performance counters are listed under the name of the SQL Server instance rather. Performance Monitor for monitoring SQL Server performance, see Chapter 39, “Monitoring SQL Server Performance.” SQL Server Lock Types Locking is handled automatically in SQL Server. The Lock Manager chooses