SQL Server 损坏修复 之四 Database Mirroring和AlwaysOn的页面自动修复功能

在SQL Server 2008Enterprise或更高版本上有一个很诱人的新功能。如果某个配置了数据库镜像或者AlwaysOn的数据库发生数据页面访问错误（823、824和829），数据库伙伴会自动尝试解决错误。无法读取页的伙伴会从其他伙伴请求新副本。如果此请求成功，则将以新副本替换不可读的页，这通常会解决发生在镜像或AlwaysOn的主服务器上的页面损坏。

1. 数据库镜像的页面自动修复功能

例如，在镜像的主服务器上的主体数据库第100页上发生了824错误，SQL Server会到镜像伙伴服务器上的数据库里，把第100页的内容读出来。如果镜像伙伴服务器上的数据库没有损坏，这个页面读取请求就能够成功。SQLServer会自动将主服务器上损坏的页面替换成读到的正确内容，从而达到修复页面的目的。数据库镜像伙伴进行的自动页修复不同于DBCC修复。自动页修复会保留所有数据。相反，使用DBCC REPAIR_ALLOW_DATA_LOSS选项更正错误可能需要删除某些页（从而会删除数据）。

由于数据库损坏大部分和硬件有关系，而两套硬件同时损坏的概率是很小的，所以这个功能看上去的确很诱人。

当然它也有一定的局限性。数据库镜像自动页修复只尝试修复特定数据文件中的页，此数据文件是指对其执行的操作由于表10-2中列出的某一错误而失败的数据文件。

表 10- 2 Database Mirroring支持修复的错误类型

错误号	说　　明	导致自动页修复尝试的实例
823	仅当操作系统对数据执行循环冗余检查 （CRC）失败时才执行此操作	ERROR_CRC。此错误的操作系统值为23
824	逻辑错误	逻辑数据错误，例如残缺写或错误的页校验和
829	页已标记为还原已挂起	全部

也不是所有的页面都能被自动修复的。以下控制页类型无法通过数据库镜像修复：

·    文件头页（页ID 0）。

·    页9（数据库启动页）。

·    分配页：全局分配映射（GAM）页、共享全局分配映射（SGAM）页和页可用空间（PFS）页。

处理主体数据库中的I/O错误

在主体数据库中，仅当节点处于SYNCHRONIZED状态且主体服务器仍向镜像服务器发送日志记录时，才会尝试自动页修复。自动页修复尝试中操作的基本顺序如下：

（1）当主体数据库中的数据页上发生读取错误时，主体服务器将使用相应的错误状态在suspect_pages表中插入一行。然后，主体服务器从镜像服务器请求此页的副本。此请求指定当前在刷新日志末尾的页ID和LSN。此页将标记为“还原已挂起”。这会使它在自动页修复尝试期间不可访问。修复尝试期间对此页的访问尝试将失败，并显示错误829（还原已挂起）。

（2）收到页请求后，镜像服务器将等待，直到将日志重做到请求中指定的LSN处。然后，镜像服务器会尝试访问镜像数据库中的此页。如果可以访问此页，则镜像服务器将此页的副本发送到主体服务器。否则，镜像服务器将向主体服务器返回错误，并且自动页修复尝试失败。

（3）主体服务器处理包含此页新副本的响应。

（4）自动页修复尝试修复可疑页后，此页将在suspect_pages表中标记为已还原（event_type = 4)。

（5）如果此页I/O错误导致出现任何延迟的事务，则修复此页后，主体服务器将尝试解决这些事务。

处理镜像数据库中的I/O错误

SQL Server会用以下方式处理在镜像数据库中发生的数据页I/O错误。

（1）如果镜像服务器在其重做日志记录时遇到一个或多个页I/O错误，则镜像会话将进入SUSPENDED状态。此时，镜像服务器使用相应的错误状态在suspect_pages表中插入一行。然后，镜像服务器从主体服务器请求此页的副本。

（2）主体服务器尝试访问主体数据库中的此页。如果可以访问此页，则主体服务器将此页的副本发送到镜像服务器。

（3）如果镜像服务器收到它请求的每一页的副本，则镜像服务器将尝试恢复镜像会话。如果自动页修复尝试修复了可疑页，此页将在suspect_pages表中标记为已还原（event_type = 4）。

2. AlwaysOn的页面自动修复功能

AlwaysOn的页面自动修复功能和镜像非常相似。下面是它具体的工作过程：

主数据库上的页面损坏

1.    在主副本上访问页面，得到了823,824或829错误。访问操作被中止。Suspect_pages表中会插入一条记录来标示该质疑页面。该页面会被标记为“还原/挂起”状态，在自动修复操作完成之前（无论是修复成功还是失败），任何访问这个页面的操作都会得到829错误。

2.    主副本发送广播请求到所有辅助副本上，请求该页面的副本来修复受损页。广播请求中会包含所需页面的ID，以及主副本的当前LSN（被写入到LDF文件的最后一个日志）。

3.    当辅助数据库将日志重做到请求中所指定的LSN后，它就会尝试去访问请求中所包含的页ID。如果成功获得这个页面，就把这个页面发送给主副本。如果失败，那么整个自动修复就失败，辅助副本会返回一个错误给主副本。因此，修复页面所需要的时间主要取决于辅助数据需要多长时间才能追上主数据的LSN。

4.    主副本可能从多个辅助副本上都收到页面。第一个收到的页面会用来替代主数据库上损坏的页面。后续那些来自其他辅助副本的页面就被丢弃了。

5.    当自动修复完成工作后，suspect_pages 该页面所对应记录的event_type 列会被设置成5。

辅助数据库上的页面损坏

1.    如果辅助副本在其重做日志记录时遇到823,824或829错误，那么辅助数据库将进入挂起状态。 同时在辅助副本的suspect_pages 表中插入一行记录来表示这个损坏页面。

2.    辅助数据库向主数据库请求该页的当前副本。

3.    主数据库响应该请求将页面副本和当前的LSN发送给辅助副本，并且只允许辅助副本上的重做线程来访问这个页面。

4.    辅助副本上的重做线程继续运行。直到辅助数据库上重做的LSN达到并超过了主数据发送来的页面副本的LSN时，该页面才能被辅助副本上所有的工作线程所访问。从此，该页面就在内存中替换了辅助数据库中的损坏页面。等到下次checkpoint的时候，该页面就会被写回到磁盘上。

每当可用性组使用自动页面修复功能修复了一个受损页面后，在动态管理视图sys.dm_hadr_auto_page_repair中就会多出一条记录，代表了该自动修复操作。你可以通过监视该动态管理视图来了解系统中发生的自动修复情况。

所以，如果镜像或者AlwaysOn能够正常工作，数据库的安全性就能够得到很大的提升。虽然配置镜像或者AlwaysOn会增加维护成本，但是还是建议有条件的系统试一试。