Databases Reference
In-Depth Information
You may look at this table with a degree of hope that your locks never end up too far down the list.
It's quite understandable and reasonable to expect that your normal querying behavior should be
able to get away with just locking rows, pages, and occasionally a whole HoBT; but remember that
a single object's locks can cover many HoBT locks, which in turn, might cover thousands or mil-
lions of pages, and who knows how many rows. A trade-off must be made between having a smaller
number of locks with more data locked than strictly necessary and having less data locked with a
larger number of locks.
Lock escalation occurs when a number of locks are converted into a smaller number of locks at
levels further down that list (typically to the object level) — that is, making the trade-off to reduce
the number of locks through coarser granularity. This can be benei cial in that it reduces the amount
of overhead to manage the locks; but of course with more data locked, there is a higher likelihood of
processes being blocked by encountering locked data. Details about how this escalation occurs are
covered later in the chapter, after the lock modes and compatibility between the lock modes have
been considered. For now, be aware of the kinds of things that can be locked.
Lock Modes
Data in a database is not like a topic, which can only be in the possession of one person at a time. If
you are reading a topic, the topic is in your hands and other people can't read it. Data is more like a
notice on a board. You and other people can read it at the same time. However, if you want to change
it, then you need to take the notice down off the board, and no one else can change it at the same
time. Whether or not they can read it while it is being changed is a separate matter (the isolation
level), but this scenario is related to the concept of
lock modes
, and the compatibility matrix between
them, as described in the following sections.
Shared Lock Mode (S)
When a read request for a row of data is made by a task, by default, SQL Server will request a lock
in shared mode. Shared mode is compatible with most other locks, as it is only permitted to read the
row on the data page.
Update Lock Mode (U)
Update mode is a special kind of lock. It is used when searching data during a data modii ca-
tion request. The process is straightforward: SQL Server uses the update lock by locating the data
and then preventing others from updating it. It prevents other requests from modifying the data
by virtue of the update lock's compatibility with other locks. Any other requests wishing to lock
the resource with an update or exclusive lock are forced to wait. However, in order to effect the
data modii cation, the update lock must be converted to an exclusive lock. As the update lock has
blocked all other data modii cation locks, all it needs to do is wait until it can get an exclusive lock
when the last, if any, shared locks have been released. This allows for greater concurrency in the
system as opposed to all writers just taking exclusive locks. If the latter were the case, then blocking
would be a much greater problem. Concurrent queries would be blocked for the entire duration of
the update (the read part and the write) as opposed to just the write.
Search WWH ::
Custom Search