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

purchased. Process 2 records sales; it updates the total amount of products sold in the Suppliers table,
then decreases the inventory quantity in Products.
If we run these two processes at the same time, we’re begging for trouble. Process 1 will grab an exclusive
lock on the Products table. Process 2 will grab an exclusive lock on the Suppliers table. Process 1
then attempts to grab a lock on the Suppliers table, but it will be forced to wait for Process 2 to clear its
existing lock. In the meantime, Process 2 tries to create a lock on the Products table, but it will have to
wait for Process 1 to clear its existing lock. We now have a paradox — both processes are waiting on
each other. SQL Server will have to pick a deadlock victim.
Now let’s rearrange that scenario, with Process 2 changed to first decrease the inventory quantity in
Products, then update the total amount of products sold in the Suppliers table. This is a functional
equivalent to the first way we organized the processes, and it will cost us nothing to perform it this new
way. The impact though, will be stunning — no more deadlocks (at least not between these two
processes)! Let’s walk through what will now happen.
When we run these two processes at the same time, Process 1 will grab an exclusive lock on the Products
table (so far, it’s the same). Process 2 will then also try to grab a lock on the Products table, but
will be forced to wait for Process 1 to finish (notice that we haven’t done anything with Suppliers yet).
Process 1 finishes with the Products table, but doesn’t release the lock because the transaction isn’t
complete yet. Process 2 is still waiting for the lock on Products to clear. Process 1 now moves on to grab
a lock on the Suppliers table. Process 2 continues to wait for the lock to clear on Products. Process 1
finishes and commits or rolls back the transaction as required, but frees all locks in either case. Process 2
now is able to obtain its lock on the Products table and moves through the rest of its transaction without
further incident.
Just swapping the order in which these two queries are run has eliminated a potential deadlock problem. Keep
things in the same order wherever possible and you, too, will experience far less in the way of deadlocks.
Keeping Transactions as Short as Possible
This is another of the basics. Again, it should become just an instinct — something you don’t really think
about, something you just do.
This is one that never has to cost you anything really. Put what you need to put in the transaction and
keep everything else out — it’s just that simple. Why this works isn’t rocket science — the longer the
transaction is open and the more it touches (within the transaction), the higher the likelihood that you’re
going to run into some other process that wants one or more of the objects that you’re using (reducing
concurrency). If you keep your transaction short, you minimize the number of objects that can potentially
cause a deadlock, plus you cut down on the time that you have your lock on them. It’s as simple as that.
Keeping transactions in one batch minimizes network roundtrips during a transaction, reducing possible
delays in completing the transaction and releasing locks.
Use the Lowest Transaction Isolation Level Possible
Chapter 14: Transactions and Locks
This one is considerably less basic and requires some serious thought. As such, it isn’t surprising just
how often it isn’t thought of at all. Consider it Rob’s axiom — that which requires thought is likely not to
be thought of. Be different: Think about it.
447