My name is Kenneth Fisher and I am Senior DBA for a large (multi-national) insurance company. I have been working with databases for over 20 years starting with Clarion and Foxpro. I’ve been working with SQL Server for 12 years but have only really started “studying” the subject for the last 3. I don’t have any real "specialities" but I enjoy trouble shooting and teaching. Thus far I’ve earned by MCITP Database Administrator 2008, MCTS Database Administrator 2005, and MCTS Database Developer 2008. I’m currently studying for my MCITP Database Developer 2008 and should start in on the 2012 exams next year. My blog is at www.sqlstudies.com.

I’ve done a couple of posts now talking about how rolling back a transaction works. I thought this time I would back up a bit and talk about what exactly a transaction is and why we have them. A transaction is simply a unit of work. A unit of work is a series of inserts/updates/deletes that go together. So why do we care? Well one of my favorite examples is paying a bill.

Bob is paying $50 to his internet provider “ImaPain”. This is going to require two commands.

UPDATE Balances SET CurrentBalance = CurrentBalance-50
WHERE name = 'Bob'
UPDATE Balances SET CurrentBalance = CurrentBalance+50
WHERE name = 'ImaPain'

So what happens if we cancel the transfer in the middle and only the first command has occurred? Bob now has $50 less and his provider still hasn’t been paid. No one is happy at this point. But what if instead we wrap this “unit of work” in a transaction?

Now if we cancel the transfer in the middle (deliberately or through a crash) the whole process rolls back at once and Bob isn’t out any money. His provider hasn’t been paid yet but at least Bob still has the money to do so.

That was an explicit transaction. An explicit transaction is defined by BOL as “one in which you explicitly define both the start and end of the transaction.”. There are also implicit transactions that SQL creates and ends on its own. Again a unit of work but this time we don’t have to deliberately start and commit a transaction. Here we are giving everyone a raise!

UPDATE PayTable SET HourlyPay = HourlyPay + 1

Oh no! Our connection was lost about half way through the command! We have updated 20 employees of our total roster of 50. SQL uses an implicit transaction to make sure that any changes before the end of the command are rolled back. It wouldn’t do for a random half of the employees to get a raise and not the other.

If you stop there it sounds like the best thing to do is to wrap everything in transactions to prevent possible problems. Unfortunately this has its own set of problems. As a rule transactions should be as small as possible. Among other things this is to avoid blocking. Discussing transactions and blocking in detail is way beyond the scope of this post as you have to get into the various transaction isolation levels and how each handles blocking. In general though all locks held by a statement in a transaction are held until the end of the transaction. If this happens to block a statement in another transaction then that block will be held until the end of the first transaction. Another good reason to keep your transactions as small as possible is to avoid losing information during a crash. Using the example above let’s say we both Bob and James are paying their internet provider and it’s all put into a single transaction.

What happens if the connection fails or the server goes down in the middle of the transaction, say after the 3rd statement. Even though both statements required for Bob’s payment have completed his payment is rolled back along with James’. If however we had used 2 transactions then we would only have lost the one pair of updates instead of both.

Transactions are a big subject which I’m going to explore over several posts. I am by no means going to cover the subject exhaustively but if you have any subjects you would like me to cover or think I’ve missed something feel free to comment or email me.