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

The syntax for switching between them is pretty straightforward:
SET TRANSACTION ISOLATION LEVEL
The change in isolation level will affect only the current connection, so you don’t need to worry about
adversely affecting other users (or them affecting you).
Let’s start by looking at the default situation (READ COMMITTED) a little more closely.
READ COMMITTED
With READ COMMITTED, any shared locks you create will be automatically released as soon as the statement
that created them is complete. That is, if you start a transaction, run several statements, run a
SELECT statement, and then run several more statements, the locks associated with the SELECT statement
are freed as soon as the SELECT statement is complete — SQL Server doesn’t wait for the end of the
transaction.
Action queries (UPDATE, DELETE, and INSERT) are a little different. If your transaction performs a query
that modifies data, then those locks will be held for the duration of the transaction (in case you need to
roll back).
By keeping this level of default with READ COMMITTED, you can be sure that you have enough data
integrity to prevent dirty reads. However, non-repeatable reads and phantoms can still occur.
READ UNCOMMITTED
Chapter 14: Transactions and Locks
READ UNCOMMITTED is the most dangerous of all isolation level choices, but also has the highest performance
in terms of speed.
Setting the isolation level to READ UNCOMMITTED tells SQL Server not to set any locks and not to honor
any locks. With this isolation level, it is possible to experience any of the various concurrency issues we
discussed earlier in the chapter (most notably a dirty read).
Why would one ever want to risk a dirty read? When I watch the newsgroups on Usenet, I see the question
come up on a regular basis. It’s surprising to a fair number of people, but there are actually good
reasons to have this isolation level, and they almost always have to do with reporting.
In an OLTP environment, locks are both your protector and your enemy. They prevent data integrity
problems, but they also often prevent or block you from getting at the data you want. It is extremely
commonplace to see a situation where the management wants to run reports regularly, but the data
entry people are often prevented from or delayed in entering data because of locks held by the manager’s
reports.
By using READ UNCOMMITTED, you can often get around this problem — at least for reports where the
numbers don’t have to be exact. For example, let’s say that a sales manager wants to know just how
much has been done in sales so far today. Indeed, we’ll say he’s a micro-manager and asks this same
question (in the form of rerunning the report) several times a day.
443