Performance Tuning with SQL Server Dynamic Management Views

Chapter 4: Transactions
As noted, this is normal behavior but, in conditions of highly concurrent user access, the
potential for blocking will increase. The situation will be exacerbated, for example, by
transactions that are longer than they need to be or are poorly written, causing locks to
be held for longer than necessary. As locking and blocking increase, so does the overhead
on the RDBMS and the end result is a significant reduction in concurrency.
READ UNCOMMITTED – Don't do it
If you want concurrency at all costs, then READ UNCOMMITTED isolation level will shun locks as far as
possible. This mode allows dirty reads, so use it at the expense of your data consistency and integrity.
In READ COMMITTED mode, shared read locks are released as soon as a query completes,
so data modification transactions can proceed at that point, even if the transaction to
which the query belongs is still open. Therefore, non-repeatable reads are possible; if the
same data is read twice in the same transaction, the answer may be different. If this is not
acceptable, the isolation level can be made more restrictive. The REPEATABLE READ level
will ensure that all the rows that were read cannot be modified or deleted until the
transaction which reads them completes. However, even this level does not prevent new
rows (called phantom rows) being inserted that satisfy the query criteria, meaning that
reads are not, in the true sense, repeatable. To prevent this, you could switch to
SERIALIZABLE, the most restrictive isolation level of all, which basically ensures
that a transaction is completely isolated from the effects of any other transaction in
the database.
However, as the isolation level becomes more restrictive, so the use of locks becomes
more prevalent and the likelihood of blocking, and even deadlocking, where transaction
A is waiting for a resource that is held by B and vice versa, increases dramatically. Note
also, that it is not only competing modifications that can cause a deadlock. It is just as
possible for a modification to deadlock with a reporting query.
118