检查点(Checkpoint)过程如何处理未提交的事务
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了检查点(Checkpoint)过程如何处理未提交的事务相关的知识,希望对你有一定的参考价值。
每次我讲解SQL Server之前,我都会先简单谈下当我们执行查询时,在SQL Server内部发生了什么。执行一个SELECT语句非常简单,但是执行DML语句更加复杂,因为SQL Server要修改内存中的相关页,并在事务日志里记录整个事务。
介绍完这些特定步骤后,我总会问同样的问题:当我们有个未提交的事务,这个时候刚好有检查点(Checkpoint)发生,SQL Server会崩溃么?在我们数据文件里有我们未提交的数据么?先思考下,然后再写下你的答案。
创建测试场景
现在我想和你一起重建这个特定场景,最后你会看到你是否回答对了。这个场景的第一步,我创建了一个新的数据库,一个新的表,并插入一些记录。
1 -- Create a new database 2 CREATE DATABASE Checkpointing 3 GO 4 5 -- Use it 6 USE Checkpointing 7 GO 8 9 -- Create a new table 10 CREATE TABLE Foo 11 ( 12 Col1 CHAR(100) NOT NULL, 13 Col2 CHAR(100) NOT NULL, 14 Col3 CHAR(100) NOT NULL 15 ) 16 GO 17 18 -- Insert a record 19 INSERT INTO Foo VALUES 20 ( 21 REPLICATE(‘A‘, 100), 22 REPLICATE(‘B‘, 100), 23 REPLICATE(‘C‘, 100) 24 ) 25 GO 26 27 -- Retrieve the record 28 SELECT * FROM Foo 29 GO
在我们插入数据后,我想知道SQL Server存储特定记录的页号。我们可以使用DBCC IND命来来返回特定表的所有页。在我的服务器上SQL Server使用的Page id是79。
1 -- Retrieve the first data page for the specified table (columns PageFID and PagePID) 2 DBCC IND(Checkpointing, Foo, -1) 3 GO
现在当我们用DBCC PAGE命令输出页内容时(使用这个命令前,要先启用3604跟踪标记),我们可以看到插入的A,B,C的16进制值。
1 -- Enable DBCC trace flag 3604 2 DBCC TRACEON(3604) 3 GO 4 5 -- Dump the first data page of the table Customers retrieved by DBCC IND previously 6 DBCC PAGE (Checkpointing, 1,79, 3) 7 GO
现在当我们进行检查点(Checkpoint)过程,并最终杀掉SQL Server会发生什么?未提交的数据会物理写入数据文件么?我们来试验下...
崩溃并恢复SQL Server
现在我们开始一个新的事务,并更新插入记录的第一列。
1 -- Begin a new transaction without committing it... 2 BEGIN TRANSACTION 3 4 UPDATE Foo 5 SET Col1 = REPLICATE(‘X‘, 100)
从代码里你可以看到,我们并没有提交这个事务!它还是待定的,未提交的事务。现在我们打开另一个会话,我们人为进行一次检查点(Checkpoint)过程,并最终关闭SQL Server。
1 -- Execute it in a different session 2 CHECKPOINT 3 GO 4 5 SHUTDOWN WITH NOWAIT 6 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里你知道多少个不同的场景呢?
以上是关于检查点(Checkpoint)过程如何处理未提交的事务的主要内容,如果未能解决你的问题,请参考以下文章