本篇文章是系列文章中的第五篇，是对前一个日志系列的补充篇。如果您对日志的基本概念还没有一个比较系统的了解，可以参看本系列之前的文章： 浅谈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