Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 14: Transactions and Locks
If the report happened to be a long-running one, then there’s a high chance that his running it would
damage the productivity of other users due to locking considerations. What’s nice about this report,
though, is that it is a truly nebulous report — the exact values are probably meaningless. The manager is
really just looking for ballpark numbers.
By having an isolation level of READ UNCOMMITTED, we do not set any locks, so we don’t block any other
transactions. Our numbers will be somewhat suspect (because of the risk of dirty reads), but we don’t
need exact numbers anyway and we know that the numbers are still going to be close, even on the off
chance that a dirty read is rolled back.
You can get the same effect as READ UNCOMMITTED by adding the NOLOCK optimizer hint in your query.
The advantage to setting the isolation level is that you don’t have to use a hint for every table in your
query or use it in multiple queries. The advantage to using the NOLOCK optimizer hint is that you
don’t need to remember to set the isolation level back to the default for the connection. (With READ
UNCOMMITTED you do.)
REPEATABLE READ
The REPEATABLE READ escalates your isolation level somewhat and provides an extra level of concurrency
protection by preventing not only dirty reads (the default already does that), but also preventing
non-repeatable reads.
That prevention of non-repeatable reads is a big upside, but holding even shared locks until the end of
the transaction can block users’ access to objects, and therefore hurt productivity. Personally, I prefer to
use other data integrity options (such as a CHECK constraint together with error handling) rather than
this choice, but it remains an available option.
The equivalent optimizer hint for the REPEATABLE READ isolation level is REPEATABLEREAD (these are
the same, only no space).
SERIALIZABLE
444
SERIALIZABLE is something of the fortress of isolation levels. It prevents all forms of concurrency issues
except for a lost update. Even phantoms are prevented.
When you set your isolation to SERIALIZABLE, you’re saying that any UPDATE, DELETE, or INSERT to
the table or tables used by your transaction must not meet the WHERE clause of any statement in that
transaction. Essentially, if the user was going to do something that your transaction would be interested
in, then it must wait until your transaction has been completed.
The SERIALIZABLE isolation level can also be simulated by using the SERIALIZABLE or HOLDLOCK optimizer
hint in your query. Again, like the READ UNCOMMITTED and NOLOCK debate, the option of not having
to set it every time versus not having to remember to change the isolation level back is the big issue.
Going with an isolation level of SERIALIZABLE would, on the surface, appear to be the way you want
to do everything. Indeed, it does provide your database with the highest level of what is called consistency
— that is, the update process works the same for multiple users as it would if all your users did
one transaction at a time (processed things serially).