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

Chapter 14: Transactions and Locks
Transaction 1
Absolutely nothing would happen. The transaction has already been through a checkpoint and has been
fully committed to the database. There is no need to do anything at recovery, because any data that is
read into the data cache would already reflect the committed transaction.
Transaction 2
Even though the transaction existed at the time that a checkpoint was issued, the transaction had not been
committed (the transaction was still going). Without that commitment, the transaction does not actually
participate in the checkpoint. This transaction would, therefore, be rolled forward. This is just a fancy way
of saying that we would need to read all the related pages back into cache, then use the information in
the log to rerun all the statements that we ran in this transaction. When that’s finished, the transaction
should look exactly as it did before the system failed.
Figure 14-2
Transaction 3
432
Transaction 1
Checkpoint Checkpoint
Transaction 2
Transaction 5
Checkpoint System Failure
Transaction 3
Transaction 4
It may not look the part, but this transaction is exactly the same as Transaction 2 from the standpoint of
what needs to be done. Again, because Transaction 3 wasn’t finished at the time of the last checkpoint, it
did not participate in that checkpoint — just like Transaction 2 didn’t. The only difference is that Transaction
3 didn’t even exist at that time, but from a recovery standpoint that makes no difference — it’s
where the commit is issued that makes all the difference.