SQL SERVER 检查点

xuke123

　　1.msdn官方检查点概述：
　　出于性能方面的考虑，数据库引擎对内存（缓冲区缓存）中的数据库页进行修改，但在每次更改后不将这些页写入磁盘。 相反，数据库引擎定期发出对每个数据库的检查点命令。 “检查点”将当前内存中已修改的页（称为“脏页”）和事务日志信息从内存写入磁盘，并记录有关事务日志的信息。数据库引擎支持几种类型的检查点：自动、间接、手动和内部。对于自动、手动和内部检查点，在数据库恢复期间只有在最新检查点后所做的修改需要前滚。 这将减少恢复数据库所需的时间。
　　2.根据描述，得到两个结论：
　　2.1.检查点设计的初衷是为了提高性能
　　没有必要做一次数据修改就去将更新应用到磁盘，这种同步操作性能不好。我的理解是这种同步操作将会很频繁，既然有缓冲区，不如把修改数据，也就是脏页放在缓冲区中，做集中批量更新，减少io操作次数。
　　2.2.检查点机制可以降低恢复时间
　　因为之后如果数据库意外关闭或者崩溃，那么在恢复的过程中，数据库引擎就不需要恢复所有事务日志，而是从 该检查点 开始应用日志中所做的修改。
　　先看两个概念：
　　①已经提交的事务（comitted）：日志中记录了事务的开始和commit提交事务，这说明日志已经完整地记录了事务的所有更新活动。
　　②没有提交的事务(uncomitted)：日志中记录了事务的开始记录，但没有日志的提交记录，这说明日志记录的事务没有最后提交。
　　完整日志模式数据库的故障及恢复机制都离不开日志文件。每次恢复过程都需要从头到尾扫描日志文件以确定哪些事务是committed事务，哪些事务是uncommitted事务，才能分别进行Redo或Undo操作，保证数据的一致性。如果日志的体量很大的话，那么扫描日志和应用日志的时间将会非常长，即使是已经提交的圆满事务，也会需要扫描到。那么有没有办法不要扫描这么多日志呢？解决办法就是检查点。就从检查点后面开始恢复，进行应用日志。这样就会大幅度减少应用日志的体量，当然会降低恢复时间。
　　3.检查点分类：

• 　　自动检查点
  
  
• 　　间接检查点
  
  
• 　　内部检查点
  
  

　　如下图：
　　TARGET_RECOVERY_TIME
　　'recovery interval'
　　使用的检查点类型
　　0
　　0
　　目标恢复间隔为 1 分钟的自动检查点。
　　0
　　>0
　　自动检查点，其目标恢复间隔由 sp_configurerecovery interval 选项的用户定义的设置指定。
　　>0
　　不适用。
　　间接检查点，其目标恢复时间由 TARGET_RECOVERY_TIME 设置确定，以秒为单位。

　　上面两个参数

recovery interval 针对于整个数据库实例，默认为0，参数定义的时候，分为 0 跟 >0两种情况。
target_recovery_time 针对于某个数据库，默认为0，参数定义的时候，也分为0 跟 >0 两种情况。
3.1自动检查点
3.1TARGET_RECOVERY_TIME
　　当TARGET_RECOVERY_TIME设置为0的时候，检查点为自动检查点。
　　　　3.2recovery_interval
　　自动检查点的生成频率，取决于数据库 recovery_interval 配置值，可通过管理视图 sys.sysconfigures查看配置值。
　　recovery_interval的配置值 指定 服务器实例在系统启动期间 从最近一个检查点之后应用日志来恢复数据库 的最长时间，也就是当 目标恢复间隔为1分钟时，那么数据库就会检查，那么数据库就会估算，在 DB重启恢复期间，1分钟内能够处理的最大日志记录数，如果从最近一个检查点之后到当前的日志记录数达到了这个 值，那么数据库就会自动发起一个检查点命令。所以，自动检查点之间的 命令执行时间并非是固定的，在业务高峰期，可能比较密集，而在业务的低峰期，则相对较长时间才允许一次检查点命令。
　　自动检查点之间的时间间隔可以变化很大。 具有大量事务工作负荷的数据库的检查点生成频率将高于主要用于只读操作的数据库的检查点生成频率。 在简单恢复模式下，如果日志填充 70％，则自动检查点还将排队。msdn给出的解释我的理解是，简单恢复模式，如果不足70%的情况，不急着按时发出检查点，等待这个临界阈值的触发。
　　在简单恢复模式下，除非某些因素延迟了日志截断，否则自动检查点将截断事务日志中没有使用的部分。 相反，在完整恢复模式或大容量日志恢复模式下，一旦建立了日志备份链，自动检查点将不会引起日志截断。
　　注：在系统崩溃后恢复给定数据库所需的时间主要取决于重做崩溃时的脏页所需的随机 I/O 量。 这意味着 recovery interval 设置不可靠。 它不能确定准确的恢复持续时间。 此外，正在执行自动检查点操作时，数据的常规 I/O 活动显著增加并且无法预测。
　　--修改 recovery interval 参数

　　对于OLTP系统（少大事务跟少开始事务后迟迟没有提交事务的情况），recovery interval 是确定恢复时间的主要因素。 但是，recovery interval 选项不影响撤消长时间运行的事务所需的时间。比如，设置的recovery interval为0，则是默认为 1分钟的恢复间隔，但是修改数据执行了2个小时，那么，实际的恢复将长于 recovery interval。
通常情况下，默认值是最佳。但是，如果出现以下情况来，则可通过修改配置值来提高性能（建议逐渐增大该值来评估，而非突然修改较大值）：

• 在长时间运行的大事务没有回滚时，数据库恢复所耗费的时间通常都超过了1分钟；
  
• 检查点过于频繁，内存数据页写入到磁盘影响了数据库的IO性能
  

修改recovery interval配置如下：
/*查看当前值*/　　

select * from sys.sysconfigures where comment like '%recovery%interval%'　　/*打开数据库高级选项*/
　　调整样式& to be continued..