From the previous blog
SQL Server Storage Engine: Select Statement life cycle summary
Now we will start learning about What happens in database engine when an update statement will be issued. Same structure follows as with select statement for SNI, and Rational Engine and Access Method part, as we can see till Point 5 from the previous post and we can also see this in attached picture.
At the point of Access Method as in Select statement It goes to Buffer Manager here it goes to Transaction Manager.
SQL Server Storage Engine: Select Statement life cycle summary
Now we will start learning about What happens in database engine when an update statement will be issued. Same structure follows as with select statement for SNI, and Rational Engine and Access Method part, as we can see till Point 5 from the previous post and we can also see this in attached picture.
At the point of Access Method as in Select statement It goes to Buffer Manager here it goes to Transaction Manager.
Transaction Manager
Write-ahead logging (WAL): 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.
Writing to the transaction log is the only part of a data modification
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.
What’s actually stored in the transaction log is details of the
page changes that occurred as the result of a modification statement. This is
all that SQL Server needs in order to undo any change.
The actual data modification can only be performed when confirmation
is received that the operation has been physically written to the transaction
log. This is why transaction log performance is so crucial.
Once confirmation is received by the Access Methods, it passes
the modification request on to the Buffer Manager to complete.
Buffer Manager
The page that needs to be modified is already in cache, the page
is modified in the cache, and confirmation is sent back to Access Methods and
ultimately to the client.
The key point here is that the UPDATE statement has changed the data in the data cache,
not in the actual
database file on disk.
This is done for performance reasons, and the page is now what’s
called a dirty page because it’s different in memory from what’s on disk.
These dirty pages will be written back to the database file
periodically whenever the free buffer list is low or a checkpoint occurs.
No comments:
Post a Comment