SQL Server的实例恢复解析

在 SQL Server 数据库中，事务日志用于记录事务在 Buffer Cache 中的做的页更改。

当我们更新一些数据时，数据库会把相关数据页的前镜像和后镜像都记录在事务日志中，并为每个事务生成一个唯一的 LSN（log seq number），在检查点发生时 SQL Server 确保检查点 LSN 之前的脏块被全部写入到磁盘。因此 SQL Server 的事务日志兼有 redo 和 undo 的作用。

但是，如果我们的 数据库被强制关闭或者服务器异常掉电重启，数据库就将处于非一致性的状态 （没业务的库除外），这意味检查点之后的所有事务（无论是提交还是未提交的），都出现了异常，提交的事务可能脏块未被写入磁盘，未提交的长事务可能有一部分脏块已经被写入到磁盘，数据库必须处于一致状态才能被正常打开，因此 此时必须进行实例恢复。

SQL Server 的实例恢复分两个阶段：

1. 前滚

此阶段只处理已提交的事务，根据 boot page 中记录的检查点和事务日志的记载，SQL Server 重构检查点之后的内存脏块并按正常机制提交已提交事务的脏块。

对未提交事务的脏块暂时不做操作。

2. 回滚

此阶段处理未提交的事务，SQL Server 根据事务日志中记载的更改块前镜像，去覆盖硬盘上那些未提交事务涉及的数据块。

总结一下：

1）实例恢复的目的：

• 将所有已提交事务的脏块写入磁盘。
• 回滚未提交的事务。
• 将检查点推进至已被写入磁盘的事务 LSN。

2）实例崩溃之前：

• 一些已提交的事务被事务日志记录，但是脏块未被写入到磁盘
• 一些未提交的长事务中的脏块已经被写入到磁盘
• 一些未提交的事务，其日志还留在 log buffer 中未被写入到磁盘中的事务日志文件。

3）实例恢复阶段：

• Log buffer 中所有未提交事务的日志在掉电时全部被清空。（已提交事务的日志默认被写入了磁盘事务日志文件）
• 从 boot page 中识别出上一个检查点，作为实例恢复的起点。
• 在前滚阶段，SQL Server 根据事务日志的记录对所有脏块进行重现。（无论是提交还是未提交的事务）然后将已提交事务的脏块写入磁盘，对未提交事务的脏块暂不作操作。
• 在回滚阶段，SQL Server 根据事务日志中记载的前镜像对所有未提交的事务进行回滚。
• 更新 boot page 中的检查点 LSN 和事务日志中的 LSN。

在以上的介绍中我们提到了 boot page，那么什么是 boot page 呢？

每个数据库都会有一个记录数据库重要信息的页，只有一页一般是 PRIMARY filegroup 的第 9 个页。我们可以使用如下命令查看这一页的信息：

检查点 LSN 被记录在 boot page 中，这是实例恢复的起点，如果这个 page 无法被访问，那么数据库就不能被附加，打开，或者做其他任何操作。检查点 LSN 只会被记录在 bootpage 中，因此这是一个对于实例恢复来说不可或缺的页。

对于 SQL Server 中检查点的解释：

当检查点发生时，无论这个检查点是如何触发的（手动执行检查点命令，或者数据库执行差异差异备份，或者数据库自动生成的检查点），数据库都会做以下操作：

• 所有的脏块都被写入磁盘，无论事务是否已提交。
• 在这些脏块被写入磁盘之前，所有关于这些脏块更改的事务日志也要被从 log buffer 中写入到磁盘，这样可以确保实例恢复的有效性和有序性，这个操作被称作 write-ahead logging（日志先写），日志被写入硬盘的操作是严格按时间序列化的，不可能以事务为单位来离散的写入到磁盘，因此某个脏块的写入磁盘操作，可能引发 log buffer 中一些之前的、与本脏块无关的事务日志也被写入磁盘。但这是有好处的，事务日志总是被越早写入磁盘越好。
  
• 检查点的 LSN 会被记录到数据库 boot page 中的dbi_checkptLSN���域。

这里可以复习一些 Oracle 的检查点机制，也是 CKPT 进程触发 DBWR 写脏块，同时如果要写的脏块的 scn 大于 LGWR 的 scn，DBWR 也会触发 LGWR 把要写的脏块的相关 log buffer 写入 redo 文件中，与 SQL Server 日志先写的机制相似。