SQL Server Architecture - SQL Server 2012 Internals and Troubleshooting - page 16

The good news is that the process is exactly the same as the process for the SELECT statement you
just looked at until you get to the Access Methods.
The Access Methods need to make a data modii cation this time, so before the I/O request is
passed on, the details of the change need to be persisted to disk. That is the job of the Transaction
Manager.
Transaction Manager
The Transaction Manager has two components that are of interest here: a Lock Manager and a Log
Manager. The Lock Manager is responsible for providing concurrency to the data, and it delivers
the coni gured level of isolation (as dei ned in the ACID properties at the beginning of the chapter)
by using locks.
NOTE The Lock Manager is also employed during the SELECT query life cycle
covered earlier, but it would have been a distraction; it is mentioned here because
it's part of the Transaction Manager, but locking is covered in depth in Chapter 6.
The real item of interest here is actually the Log Manager. The Access Methods code requests that the
changes it wants to make are logged, and the Log Manager writes the changes to the transaction
log. This is called write-ahead logging (WAL).
Writing to the transaction log is the only part of a data modii cation transaction that always needs
a physical write to disk because SQL Server depends on being able to reread that change in the event
of system failure (you'll learn more about this in the “Recovery” section coming up).
What's actually stored in the transaction log isn't a list of modii cation statements but only details of
the page changes that occurred as the result of a modii cation statement. This is all that SQL Server
needs in order to undo any change, and why it's so difi cult to read the contents of a transaction log
in any meaningful way, although you can buy a third-party tool to help.
Getting back to the UPDATE query life cycle, the update operation has now been logged. The actual
data modii cation can only be performed when coni rmation is received that the operation has been
physically written to the transaction log. This is why transaction log performance is so crucial.
Once coni rmation is received by the Access Methods, it passes the modii cation request on to the
Buffer Manager to complete.
Figure 1-6 shows the Transaction Manager, which is called by the Access Methods and the
transaction log, which is the destination for logging our update. The Buffer Manager is also in play
now because the modii cation request is ready to be completed.