檢查點（Checkpoint）過程如何處理未提交的事務

每次我講解SQL Server之前，我都會先簡單談下當我們執行查詢時，在SQL Server內部發生了什么。執行一個SELECT語句非常簡單，但是執行DML語句更加復雜，因為SQL Server要修改內存中的相關頁，並在事務日志里記錄整個事務。

介紹完這些特定步驟后，我總會問同樣的問題：當我們有個未提交的事務，這個時候剛好有檢查點（Checkpoint）發生，SQL Server會崩潰么？在我們數據文件里有我們未提交的數據么？先思考下，然后再寫下你的答案。

創建測試場景

現在我想和你一起重建這個特定場景，最后你會看到你是否回答對了。這個場景的第一步，我創建了一個新的數據庫，一個新的表，並插入一些記錄。

-- Create a new database
CREATE DATABASE Checkpointing
GO

-- Use it
USE Checkpointing
GO

-- Create a new table
CREATE TABLE Foo
(
    Col1 CHAR(100) NOT NULL,
    Col2 CHAR(100) NOT NULL,
    Col3 CHAR(100) NOT NULL
)
GO

-- Insert a record
INSERT INTO Foo VALUES
(
    REPLICATE('A', 100),
    REPLICATE('B', 100),
    REPLICATE('C', 100)
)
GO

-- Retrieve the record
SELECT * FROM Foo
GO

在我們插入數據后，我想知道SQL Server存儲特定記錄的頁號。我們可以使用DBCC IND命來來返回特定表的所有頁。在我的服務器上SQL Server使用的Page id是79。

-- Retrieve the first data page for the specified table (columns PageFID and PagePID)
DBCC IND(Checkpointing, Foo, -1)
GO

現在當我們用DBCC PAGE命令輸出頁內容時（使用這個命令前，要先啟用3604跟蹤標記），我們可以看到插入的A，B，C的16進制值。

-- Enable DBCC trace flag 3604
DBCC TRACEON(3604)
GO

-- Dump the first data page of the table Customers retrieved by DBCC IND previously
DBCC PAGE (Checkpointing, 1,79, 3)
GO

現在當我們進行檢查點（Checkpoint）過程，並最終殺掉SQL Server會發生什么？未提交的數據會物理寫入數據文件么？我們來試驗下...

崩潰並恢復SQL Server

現在我們開始一個新的事務，並更新插入記錄的第一列。

-- Begin a new transaction without committing it...
BEGIN TRANSACTION

UPDATE Foo
SET Col1 = REPLICATE('X', 100)

從代碼里你可以看到，我們並沒有提交這個事務！它還是待定的，未提交的事務。現在我們打開另一個會話，我們人為進行一次檢查點（Checkpoint）過程，並最終關閉SQL Server。

-- Execute it in a different session
CHECKPOINT
GO

SHUTDOWN WITH NOWAIT
GO

現在你認為未提交的事務已經寫入數據文件了么？不確定？我們來找出答案！我們在16進制的編輯器（例如XVI32）里打開數據文件。跳到頁號79的開始。在數據文件里，頁號是物理偏移量，即頁開始的地方——乘上8192字節，因為在SQL Server里頁的大小是8kb。因此頁79的開始整數偏移量是647168（79*8192）.當我們查看hex值時，我們看到了我們未提交的數據。

檢查點（Checkpoint）過程不會區分提交和未提交的事務。它只會到緩存管理器（Buffer Manager）索取所有臟頁，不管它們事務的狀態。

現在我們有不一致，損壞的數據庫了么？沒有，並不真的是。因為現在當我們啟動SQL Server，每個數據庫都經過故障恢復階段，所有沒提交的事務都會回滾。當SQL Server啟動的時候，我們可以在SQL Server日志里看到這個行為：

小結

檢查點（Checkpoint）不會在意你的事務狀態。來自緩存池（Buffer Pool）的每個臟頁會寫入數據頁。如果SQL Server崩潰了也沒關系，因為故障恢復能恢復你的數據庫到完全一致的狀態。我希望這篇日志能讓你更好的理解檢查點（Checkpoint）過程，還有它如何與未提交的事務打交道。

作為家庭作業，你能否留言告訴我，還有哪些情形，SQL Server需要運行故障恢復為你的數據庫還原到一致狀態。在SQL Server里你知道多少個不同的場景呢？

參考文章：https://www.sqlpassion.at/archive/2016/01/25/how-the-checkpoint-process-deals-with-uncommitted-transactions/