关于SQL server 2008 R2 数据库日志收缩的疑问
 最近在进行SQL server 2008 数据库数据的还原。。发现日志文件太大很影响操作。
由于2008版本无法沿用2005模式的还原方法。。所以特地从百度当中找寻了一些数据库日志的收缩方法。我有按照上面的方式去测试过。。确实可以达到效果。。但是我心里还是不踏实。。。不知道这些方法会不会导致以后有什么不良后果：如下：

(SQL2008):
在SQL2008中清除日志就必须在简单模式下进行，等清除动作完毕再调回到完全模式。
USE [master]
    GO
    ALTER DATABASE hr_sbs SET RECOVERY SIMPLE WITH NO_WAIT
    GO
    ALTER DATABASE hr_sbs SET RECOVERY SIMPLE   --简单模式
    GO
    USE hr_sbs 
    GO
    DBCC SHRINKFILE (N'hr_sbs_Log' , 11, TRUNCATEONLY)
    GO
    USE [hr_sbs]
    GO

    ALTER DATABASE hr_sbs SET RECOVERY FULL WITH NO_WAIT
    GO
    ALTER DATABASE hr_sbs SET RECOVERY FULL  --还原为完全模式
    GO
--USE [hr_ldx_cs]
--DECLARE @LogFileLogicalName sysname
--SELECT @LogFileLogicalName=Name FROM sys.database_files WHERE Type=1
--PRINT @LogFileLogicalName
--DBCC SHRINKFILE (@LogFileLogicalName, 1);
--DBCC LOGINFO(hr_ldx_cs) 

优点：此清除日志所运行消耗的时间短，90GB的日志在分钟左右即可清除完毕，做完之后做个完全备份在分钟内
即可完成。
缺点： 不过此动作最好不要经常使用，因为它的运行会带来系统碎片。普通状态下LOG和DIFF的备份即可截断日志。
此语句使用的恰当环境：当系统的日志文件异常增大或者备份LOG时间太长可能影响生产的情况下使用。
查看日志截断延迟原因 
活跃(active)的日志无法通过收缩来截断，有各种原因会使日志截断延迟，具体表现就是事务日志的物理文件无法通过截断、收缩来减小，通过下面的代码可以看到实例上每个数据库的日志截断延迟原因：
1 USE [master]
2 SELECT [name] ,[database_id] ,[log_reuse_wait] ,[log_reuse_wait_desc] FROM [sys].[databases]
各种原因及解释如下：
log_reuse_wait_desc 值  说明 
NOTHING          当前有一个或多个可重复使用的虚拟日志文件自上次日志截断之后，尚未出现检查点，或者日志头部尚未
                   跨一个虚拟日志文件移动（所有恢复模式）。

CHECKPOINT        这是日志截断延迟的常见原因。有关详细信息，请参阅检查点和日志的活动部分。
                  需要日志备份，以将日志的头部前移（仅适用于完整恢复模式或大容量日志恢复模式）。

LOG_BACKUP  注意：日志备份不会妨碍截断。
                   完成日志备份后，日志的头部将前移，一些日志空间可能变为可重复使用。
                   数据备份或还原正在进行（所有恢复模式）。
ACTIVE_BACKUP      数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。有关详细信息
_OR_RESTORE  请参阅本主题后面的“数据备份操作与还原操作”部分事务处于活动状态（所有恢复模式）。

ACTIVE_TRANSACTION  一个长时间运行的事务可能存在于日志备份的开头。在这种情况下，可能需要进行另一个日志备份
                   才能释放空间。有关详细信息，请参阅本主题后面的“长时间运行的活动事务”部分。
         事务被延迟（仅适用于 SQL Server 2005 Enterprise Edition 及更高版本）。“延迟的事务 ”是有效
                  的活动事务，因为某些资源不可用，其回滚受阻。有关导致事务延迟的原因以及如何使它们摆脱延迟状态
                  的信息，请参阅延迟的事务。 

DATABASE_MIRRORING
数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库（仅限于完整恢复模式）。
有关详细信息，请参阅本主题后面的“数据库镜像与事务日志”部分。