本篇文章是系列文章中的第五篇，是对前一个日志系列的补充篇。如果您对日志的基本概念还没有一个比较系统的了解，可以参看本系列之前的文章： 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架 浅谈SQL Server中的事务日志(二)----事务日志在修
本篇文章是系列文章中的第五篇，是对前一个日志系列的补充篇。如果您对日志的基本概念还没有一个比较系统的了解，可以参看本系列之前的文章：
浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架
浅谈SQL Server中的事务日志(二)----事务日志在修改数据时的角色
浅谈SQL Server中的事务日志(三)----在简单恢复模式下日志的角色
浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色
简介
日志的作用是保证持久性和数据一致性，通过日志可以实现数据的Undo与Redo，因此通过日志，SQL Server不仅仅可以实现灾难恢复，还可以通过日志的Redo来实现高可用性。本篇文章主要讲述日志在SQL Server中提供的几种高可用性中的作用以及在灾难恢复中的角色。
日志损坏
日志可能会由于IO子系统的故障而损坏，当出现日志损坏时，如果您对日志的原来略有了解，并能在日志损坏的情况下尽量挽救数据，那么感觉一定是非常好的：-)，下面我们来了解几种日志损坏的情况下的恢复情况。
1.数据库正常关闭，日志损坏。
当数据库正常关闭时，日志损坏就不是那么重要了，因为此时数据库中所有提交的事务对应的脏数据都已经CheckPoint到物理磁盘，因此不存在数据不一致的问题。因此，如果MDF和NDF文件完好，直接指定 FOR ATTACH_REBUILD_LOG参数后附加即可，如图1所示。
图1.如果数据库正常关闭，直接附加即可
但值得注意的是，使用该方式附加数据库会自动重建日志文件，日志文件大小为0.5MB，也就是2个VLF，自动增长为10%，因此您需要手动再来设置一下日志的大小，避免出现太多VLF的情况。
2.数据库非正常关闭，日志损坏
在讲述这种情况之前，我们首先来看数据库所能处在的几种状态，一个完整的模型如图2所示。
图2.数据库所能处在的状态关系
上面的几种状态的具体转换关系超出了本文的讨论范围，香港虚拟主机，但是这里我会强调两种和日志损坏关系很大的状态：RECOVERY_PENDING和SUSPECT状态。
假如出现了数据库没有正常关闭，也就是还有数据没有CheckPoint到磁盘，如果数据库要启动就必须经历Recovery过程，如果日志损坏，则无法进行该Recovery过程，就会造成数据不一致的问题。
此时，数据库可能处于下面两种状态之一：
RECOVERY_PENDING:需要运行crash recovery，但该过程由于资源等待无法开始，比如说日志完全损坏
SUSPECT：crash recovery已经开始，但无法完成
因此处理该类情况要基于您所在的业务环境是否允许数据损失，可以选择从备份中恢复数据，或是将数据库状态改为EMERGENCY。EMERGENCY模式意味着数据库跳过crash recovery阶段，虚拟主机，香港虚拟主机，此时虽然可以访问数据库，但是会存在数据事务不一致的问题，如果仅仅是某些数据页不一致还好，但如果是对表结构修改的事务存在，那就可能存在数据库架构不一致的问题。如果您没有合适的备份集，那只能通过该方式来恢复数据。将数据库设置为EMERGENCY模式非常简单，如代码清单1所示。
ALTER DATABASE AdventureWorks2012 SET EMERGENCY
本文原创发布php中文网，转载请注明出处，感谢您的尊重！
