Locking and Blocking (8) – Lock Hints

Lock hints are used to customize the locking behavor of SQL Server from 3 main perspectives, granularity, mode, and duration. Available hints are HoldLock, NoLock, NoWait, PagLock, ReadCommtted, ReadCommittedLock, ReadPast, ReadUncommitted, RepeatableRead, RowLock, Serializable, TabLock, TabLockX, UpdLock, and XLock. A full understanding of them is important before using them.

Let’s assume you are running your SQL within a transaction. I assume all are running under READ COMMITTED transaction isolation mode. If you are interested, you can use the script posted in here to verify what I explained below.

Mode and Duration, Shared and Intent Shared locks are default locks used while performing date reading. While a Shared lock is on the record, there’s always an IS lock on the page the record located, and an IS lock on the object. Shared locks are released when the records and pages are no longer needed, which is not bound to a transaction scope.

  • NoLock, ReadUncommitted: no lock will be putting on the page or row but S lock will be placed on HOBT for HEAP and SCH-S on the object. The duration of such will be at statement level regard less number of statements within the transaction.
  • UpdLock: When this hint specified, an IX lock is placed on the object and IU lock is on the page. SQL Server use U lock to perform search the records. U lock will be released if the row is not the one to be returned regardless the duration of the transactioin. When a record satisfies the predicates and is needed to be returned, the U lock on the record along with IU lock on the page and IX lock on the object will NOT be released until transaction finishes
  • XLock: This hint will place exclusive lock on the record, IX lock on the page, and IX lock on the object. It behaves very differently than S lock in which it locks all the records the SQL Server engine “touched” regardless whether the records are returned back to the client or just for searching. For instance, you have a table with 5 records but does not have any indexes. Your query returns one record in the middle. If you are using XLock hint, all records will be locked, because there is no index on the table, SQL Server has to perform a full table scan by using exclusive lock. As just said, all records touched by SQL Server will have exclusive locks held on it unil transaction complete. In this case, creating proper index is the only way to improve the concurrency
  • ReadCommittedLock: it converts the locking behavor back to old Read Committed transaction isolation mode under read committed snapshot mode
  • ReadCommtted, ReadUncommitted, RepeatableRead, and Serializable: SQL Server support using different lock pattern on different table within the same query. See my last post of this series for details.
  • HoldLock: A synonym of Serializable.

Granularity, Locks can be applied to different granularities, such as, row, page, object, extent, schema, database, file, and partition. You can also apply locks on a string as known as application locks which will be discussed later.

  • RowLock: Putting locks on each record. It’s bit tricky. You will see it’s almost useless. If you are SELECTing records, Shared locks apply anyways. In order to reduce the overhead of requesting and releasing locks, if there is no locks on the page, SQL Server will not use Shared lock (us IS lock on the page instead) to scan the records event though you have a RowLock hint. If you combine UpdLock or XLock with RowLock, SQL Server will use update or exclusive lock to scan the record one by one anyways.
  • PagLock: Place lock on Page.
  • TabLockX: Place exclusive lock on the object (table).

ReadPast, a very useful hint especially when it’s combining with UpdLock, I will talk about it more in my later posts, it skips the records holding conflicting locks. For instance, there are 5 records in a table. Session 1 begins a transaction and updates one records. Before Session1’s transaction complete, session2 is selecting all record using ReadPast combining with ReadCommittedLock, session2 will not be blocked, it will return 4 records instead. In here, I use also ReadCommittedLock, this hint will let SQL Server perform as if no existance of snapshot when read committed snapshot is enabled.

NoWait, I have never used it. It will raises an error message 1222 “Lock request time out period exceeded.” whenever there is an blocking.

you can combine multiple hints for one table. Some of them are conflicting each other, such as NoLock and RowLock. Once it happens, error message 1047 “Conflicting locking hints specified.” will be returned.