It is important to understand the step by step process of SQL Server making changes to the stored data.
SQL Server uses Write-Ahead Logging
algorithm to make any changes to the stored data in SQL Server. Following are the steps taken to make sure each statement/transaction maintains the ACID property of SQL Server.
- A copy of the page(s) [Rows] that needs updating are loaded into buffer cache.i.e all the related pages of the B-Tree and any non-clustered indexes(if any).
- Changes are made to the copy of pages in the buffer cache.
- At this point, the page is marked dirty.
- An entry is made in the Transaction log for each change made to the page in buffer cache.
Return response to the client about the successful/unsuccessful change.
Finally a checkpoint is issued (this could happen before the user response is sent or after, as this is a separate process), the process scans the buffer cache for dirty pages, write the changes to the disk and remove the dirty page records from the cache (process also knows as flushing the pages
). And only at this stage the changes are actually written to the disk.
The checkpoint process is the one that makes sure that no dirty pages ever get flushed. This process guarantees the ACID property of transactions in the SQL Server.
If the page has only been modified in the buffer cache and has not been written to the disk(dirty page) , at this point if SQL Server crashes, after coming back online SQL server will decide whether to roll forward or rollback the transaction but data is always left in the consistent state.
If the above mention process fails anywhere in the middle and cannot complete the whole process for any reason, SQL Server marks the data pages as suspect (database corruption) which does happen sometimes but not very often (at this point you will see your DBA sweating). But you shouldn't worry about this unless you are the DBA :)