SQL Server误区:CheckPoint只会将已提交的事务写入磁盘

误区 #15:CheckPoint只会将已提交的事务写入磁盘

错误

这个误区是由于太多人对日志和恢复系统缺少全面的了解而存在已久。CheckPoint会将自上次CheckPoint以来所有在内存中改变的页写回磁盘(译者注:也就是脏页),或是在上一个CheckPoint读入内存的脏页写入磁盘。无论事务是否已经提交,其所影响的页都会在Checkpoint时写回磁盘。但对于TempDB来说例外,因为TempDB的Checkpoint的事件周期中并不包含将脏页写回磁盘的步骤。

如果你想了解更多,请阅读下面文章:

Technet 杂志文章:Understanding Logging and Recovery in SQL Server

博文: How do checkpoints work and what gets logged

博文: What does checkpoint do for tempdb?

你可以使用如下两个跟踪标记查看CheckPoint是如何工作的。

3502: 当CheckPoint开始和结束时,将相关信息写入错误日志

3504: 将CheckPoint时写回磁盘的页的信息写入错误日志

为了使用这个跟踪标记,你必须针对所有线程开启,否则你将会在错误日志中什么都看不到。使用DBCC TRACEON (3502, 3504, -1) 针对所有线程开启这两个追踪标记。

下面的代码可以证明Checkpoint会将未提交的脏页写回磁盘,跟随下面的步骤。

更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/SQLServer/

CREATE DATABASE CheckpointTest; GO USE CheckpointTest; GO CREATE TABLE t1 (c1 INT IDENTITY, c2 CHAR (8000) DEFAULT 'a'); CREATE CLUSTERED INDEX t1c1 on t1 (c1); GO

SET NOCOUNT ON; GO

CHECKPOINT; GO

DBCC TRACEON (3502, 3504, -1); GO

下面那个事务会产生10MB的脏页,紧接着进行CheckPoint

BEGIN TRAN; GO INSERT INTO t1 DEFAULT VALUES; GO 1280

CHECKPOINT; GO

日志如你所见:

我们可以清楚的看出,在事务没有提交的情况下,脏页依然会被写入磁盘。

时间: 2024-11-01 21:57:26

SQL Server误区:CheckPoint只会将已提交的事务写入磁盘的相关文章

SQL Server误区30日谈 第15天 CheckPoint只会将已提交的事务写入磁盘

误区 #15:CheckPoint只会将已提交的事务写入磁盘 错误 这个误区是由于太多人对日志和恢复系统缺少全面的了解而存在已久.CheckPoint会将自上次CheckPoint以来所有在内存中改变的页写回磁盘(译者注:也就是脏页),或是在上一个CheckPoint读入内存的脏页写入磁盘.无论事务是否已经提交,其所影响的页都会在Checkpoint时写回磁盘.但对于TempDB来说例外,因为TempDB的Checkpoint的事件周期中并不包含将脏页写回磁盘的步骤. 如果你想了解更多,请阅读下

SQL Server误区:有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区30日谈 第30天 有关备份的30个误区_MsSql

误区 #30:有关备份的30个误区全是错的在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由完整恢

SQL Server误区30日谈 第30天 有关备份的30个误区

误区 #30:有关备份的30个误区 全是错的 在开始有关备份的误区之前,如果你对备份的基础没有了解,请看之前我在TechNet Magazine的文章:Understanding SQL Server Backups. 30-01)备份操作会导致阻塞 不,备份不会导致对用户对象加锁,虽然备份对IO系统的负担导致看起来阻塞了,但实际上不会.唯一的特例是当备份包含到那些最小日志操作涉及到的数据区需要被加锁时,这个操作会阻塞CheckPoint,但DML操作永远不会受到备份操作的阻塞. 30-02)由

SQL Server误区:26个有关还原(Restore)的误区

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步. 事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. Myth #24:26个有关还原(Restore)的误区 都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点 当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到

SQL Server误区30日谈 第24天 26个有关还原(Restore)的误区_MsSql

本系列文章一直所没有触及的就是有关"还原(Restore)"的话题,因为一旦牵扯到这个话题就会涉及大量的误区,多到我无法通过一篇文章说完的地步.事实上,我希望用字母表的顺序为每一个误区进行编号,希望你看了不要昏昏欲睡.下面开始揭穿这26个误区. 误区 #24: 26个有关还原(Restore)的误区都是错误的 24 a)可以通过WITH STOPAT参数在完整备份和差异备份的基础上还原到特定时间点当然不能.虽然这个语法看上去貌似能的样子,但这个语法的最佳实践是你在进行日志还原到特定时间

(初稿)SQL Server 复制(Replication)系列(2)——事务复制搭建

原文:(初稿)SQL Server 复制(Replication)系列(2)--事务复制搭建 本文演示如何搭建最基本的事务复制. 环境准备: 虚拟机2台: 服务器名分别为RepA和RepB,RepA为发布服务器,RepB为订阅服务器.均安装WindowsServer 2008R2英文版(在外企工作的原因).并确保两台服务器能互访. SQL Server: 在上面的虚拟机中分别安装SQLServer 2008 R2 x64 英文企业版. 演示数据库: 微软示例数据库AdventureWorks20

SQL Server误区:在破坏日志备份链后需要完整备份来重新开始日志链

误区 #20:在破坏日志备份链之后,需要一个完整备份来重新开始日志链 错误 事务日志备份会备份自上次事务日志备份以来所有的事务日志(如果从来没有过日志备份的话,那就从上一次完整备份开始).有好几种类型的操作会中断事务日志的连续性,也就是说除非重新开始新的日志链,SQL Server无法再进行日志备份.下面这几种操作都有可能引起日志链断裂: 由完整恢复模式或大容量事务日志恢复模式转为简单恢复模式 从数据库镜像进行恢复 备份日志时指定了NO_LOG 或 WITH TRUNCATE_ONLY(还好在S

SQL Server误区:TempDB的文件数和需要和CPU数目保持一致

误区 #12:TempDB的文件数和需要和CPU数目保持一致 错误 哎,由于上述误区是微软"官方"的建议,并且还有大量博文坚持这个观点,这个误区已经是老生常谈. 但让人困惑的是SQL CAT团队给出的建议就是1:1,但这个建议是源自扩展方面的原理来说,而不是一个通用法则.因为他们所面对的大型客户数据量服务器和IO子系统都是大部分人没有机会遇到的. 每个实例仅仅允许有一个TempDb,但需要用到TempDB的地方却有很多,所以TempDB很容易成为性能瓶颈,我想大家数人都了解这一点,而大