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

Chapter 14: Transactions and Locks
How SQL Server Figures Out There’s a Deadlock
Every five seconds SQL Server checks all the current transactions for what locks they are waiting on, but
haven’t yet been granted. As it does this, it essentially makes a note that the request exists. It will then
recheck the status of all open lock requests again and, if one of the previous requests has still not been
granted, it will recursively check all open transactions for a circular chain of lock requests. If it finds such
a chain, then one or more deadlock victims will be chosen.
How Deadlock Victims Are Chosen
By default, a deadlock victim is chosen based on the cost of the transactions involved. The transaction
that costs the least to rollback will be chosen (in other words, SQL Server has to do the least number of
things to undo it). You can, to some degree, override this by using the DEADLOCK_PRIORITY SET option
available in SQL Server; this is, however, generally both ill advised and out of the scope of this book.
Avoiding Deadlocks
Deadlocks can’t be avoided 100 percent of the time in complex systems, but you can almost always
totally eliminate them from a practical standpoint — that is, make them so rare that they have little relevance
to your system.
To cut down or eliminate deadlocks, follow these simple (OK, usually simple) rules:
❑ Use your objects in the same order.
❑ Keep your transactions as short as possible and in one batch.
❑ Use the lowest transaction isolation level necessary.
❑ Do not allow open-ended interruptions (user interactions, batch separations) within the same
transaction.
❑ In controlled environments, use bound connections.
Nearly every time I run across deadlocking problems, at least one (usually more) of these rules has been
violated. Let’s look at each one individually.
Use Objects in the Same Order
446
This is the most common problem area within the few rules that I consider to be basic. What’s great
about using this rule is that it almost never costs you anything to speak of — it’s more a way of thinking.
You decide early in your design process how you want to access your database objects — including
order — and it becomes a habit in every query, procedure, or trigger that you write for that project.
Think about it for a minute — if our problem is that our two connections each have what the other wants,
then it implies that we’re dealing with the problem too late in the game. Let’s look at a simple example.
Consider that we have two tables: Suppliers and Products. Now say that we have two processes that
make use of both of these tables. Process 1 accepts inventory entries, updates Products with the new
amount of products on hand, and then updates Suppliers with the total amount of products that we’ve