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

As with most things in life, however, there is a trade-off. Consistency and concurrency can, in a practical
sense, be thought of as polar opposites. Making things SERIALIZABLE can prevent other users from
getting to the objects they need — that equates to lower concurrency. The reverse is also true — increasing
concurrency (by going to a REPEATABLE READ, for example) reduces the consistency of your database.
My personal recommendation on this is to stick with the default (READ COMMITTED) unless you have
a specific reason not to.
SNAPSHOT
Chapter 14: Transactions and Locks
SNAPSHOT is the newest of the isolation levels (it was added in SQL Server 2005) and most closely
resembles a combination of the READ COMMITTED and READ UNCOMMITTED. It’s important to note
that SNAPSHOT is not available by default — instead it becomes available only if a special option,
ALLOW_SNAPSHOT_ISOLATION, has been activated for the database.
Much like READ UNCOMMITTED, SNAPSHOT does not create any locks, nor does it generally honor them.
The primary difference between the two is that they recognize changes taking place in the database at
different times. Any change in the database, regardless of when or if it is committed, is seen by queries
running the READ UNCOMMITTED isolation level. With SNAPSHOT only changes that were committed prior
to the start of the SNAPSHOT transaction are seen. From the start of the SNAPSHOT transaction, all data is
viewed exactly as it was committed at the start of the transaction.
There are two special things to note relating to SNAPSHOT. First, a special database option has to be
turned on before you can even use the SNAPSHOT isolation level, and that option must be on for every
database included in your transaction (keep this in mind in case your queries span databases). Next,
while SNAPSHOT does not generally pay attention to or set locks, there is one special instance where it
will. If there is a database recovery rollback in progress when the SNAPSHOT takes place, then the SNAPSHOT
transaction will set a special lock in place to serve as something of a placeholder and then wait for the
rollback to complete. As soon as the rollback is complete, the lock is removed and the SNAPSHOT will
move forward normally.
Dealing with Deadlocks (aka “a 1205”)
OK, so now you’ve seen locks, and you’ve also seen transactions. Now that you’ve got both, we can
move on to the rather pesky problem of dealing with deadlocks.
As we’ve already mentioned, a deadlock is not a type of lock in itself, but rather a situation where a paradox
has been formed by other locks. Like it or not, you’ll bump into these on a regular basis (particularly
when you’re just starting out), and you’ll be greeted with an error number 1205. So prolific is this
particular problem that you’ll hear many a database developer refer to them simply by the number.
Deadlocks are caused when one lock can’t do what it needs to do in order to clear, because a second lock
is holding that resource, and vice versa. When this happens, somebody has to win the battle, so SQL
Server chooses a deadlock victim. The deadlock victim’s transaction is then rolled back and is notified
that this happened through the 1205 error. The other transaction can continue normally (indeed, it will
be entirely unaware that there was a problem, other than seeing an increased execution time).
445