检查点（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/