Download Locks and Concurrency

SQL Server 2000 Notes
Chapter 14
Page 1 of 3
Chapter 14B: Locks and Concurrency






Concurrency is when two or more users try to interact with the same object at the same time.
Locking is a mechanism for preventing something from being done to an object that conflicts with
something already being done to that object.
o Locking can be implemented with transaction isolation levels
o Locking can be implemented with optimizer hints
Five types of concurrency issues:
o Dirty reads – when a transaction reads a record that us part of another transaction that isn’t
complete yet
o Unrepeatable reads – when a transaction reads a record twice in the same transaction, and the
data is altered in the interim.
o Phantoms – when a transaction makes an update, but another transaction inserts a record at the
same time that would meet the WHERE criteria of that update
o Lost updates – when one transaction makes a successful update, and then another transaction
comes along that undoes that update.
o Deadlocks – a situation where two transactions can not proceed because each is holding a lock
on the resource the other transaction needs
Lockable resources:
o Database (can happen during schema changes)
o Table – includes all rows, keys, indexes, etc.
o Extent – 8 pages…
o Page – all data or index on a page
o Key – a lock on a particular key
o Row Identifier (RID) – used for locking a row
Escalation occurs when SQL Server locks more and more resources to conserve overhead – e.g., you
might think you are locking a few rows, but they turn out to be so numerous that SQL Server may lock
the page, extent, or even table holding them.
Lock Modes – i.e., ways to lock resources
o Shared Locks – indicates data is being looked at, but is still available – useful for preventing
dirty reads
o Exclusive Locks – a lock that prevents anyone else from changing locked data or placing another
lock on the data
o Update Locks – places a shared lock on data until the WHERE clause is evaluated, then places
an exclusive lock on the data once the update is to occur – useful for preventing deadlocks
o Intent Shared Locks – indicates a shared lock is or will be established at a lower level of the
database hierarchy
o Intent Exclusive Lock - indicates an exclusive lock is or will be established at a lower level of
the database hierarchy
o Shared with Intent Exclusive Lock – kind of indicates an update lock will be established at a
lower level of the database hierarchy
o Schema modification lock – no changes can be made to an object because a schema change is
being made
o Schema stability lock - ???
o Bulk update lock – locks a table while bulk inserts or bcp operations are being performed
SQL Server 2000 Notes


Chapter 14
Page 2 of 3
You can specify your own lock type instead of relying on the lock manager…use the optimizer hint in
the SELECT statement:
o Syntax: SELECT <fields> FROM <table> [AS < alias >] [[WITH] (<hint>)]
o SERIALIZABLE / HOLDLOCK – indicates that a lock is not to be released until a transaction is
ended (via ROLLBACK or COMMIT) – highest isolation level – guarantees absolute data
consistency
o READUNCOMITTED / NOLOCK – obtains no lock, and honors no other locks – very fast –
can generate dirty reads, etc. …
o READCOMMITTED – default hint – honors all locks, but releases all locks as soon as the object
in question is no longer needed – same as READ COMMITTED isolation level
o REPEATABLEREAD – lock is not released by a statement in a transaction until the transaction
is ended – new data can be inserted
o READPAST – skip all locked rows when reading
o ROWLOCK – sets a row level lock
o PAGLOCK – sets a page level lock
o TABLOCK – locks a whole table – can speed up table scanning, but also create big concurrency
issues
o TABLOCKX – creates an exclusive lock on the whole table for duration of statement or
transaction (depending on TRANSACTION ISOLATION LEVEL)
o UPDLOCK – sets an update lock
o XLOCK – specifies an exclusive lock to be held on a table or page
o Example: SELECT * FROM Orders as O WITH (PAGLOCK)
Isolation level of a transaction:
o Syntax: SET TRANSACTION ISOLATION LEVEL <READ COMMITTED | READ
UNCOMMITTED | REPEATABLE READ | SERIALIZABLE>
o READ COMMITTED - Specifies that shared locks are held while the data is being read to avoid
dirty reads, but the data can be changed before the end of the transaction, resulting in
nonrepeatable reads or phantom data. This option is the SQL Server default.
o READ UNCOMMITTED - Implements dirty read, or isolation level 0 locking, which means that
no shared locks are issued and no exclusive locks are honored. When this option is set, it is
possible to read uncommitted or dirty data; values in the data can be changed and rows can
appear or disappear in the data set before the end of the transaction. This option has the same
effect as setting NOLOCK on all tables in all SELECT statements in a transaction. This is the
least restrictive of the four isolation levels.
o REPEATABLE READ - Locks are placed on all data that is used in a query, preventing other
users from updating the data, but new phantom rows can be inserted into the data set by another
user and are included in later reads in the current transaction. Because concurrency is lower than
the default isolation level, use this option only when necessary.
o SERIALIZABLE - Places a range lock on the data set, preventing other users from updating or
inserting rows into the data set until the transaction is complete. This is the most restrictive of the
four isolation levels. Because concurrency is lower, use this option only when necessary. This
option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a
transaction.
SQL Server 2000 Notes
Chapter 14
Page 3 of 3
Three “styles” of using locks:
1. Very Optimistic – assume everything will be A-okay…
Example: select records for updating where the OrderID = 10249
2. Very Pessimistic – lock all records before user even begins to update them
Repeat Example: select records for updating where the OrderID = 10249
3. Optimistic with Timestamps – check to see if the row changed while your transaction was working
Repeat example again: