[转]SQLServer2008日志文件无法收缩处理方法

各种原因及解释如下： log_reuse_wait_desc 值说明  
NOTHING 
    当前有一个或多个可重复使用的虚拟日志文件。 
   
CHECKPOINT 
    自上次日志截断之后，尚未出现检查点，或者日志头部尚未跨一个虚拟日志文件移动（所有恢复模式）。 
    这是日志截断延迟的常见原因。有关详细信息，请参阅检查点和日志的活动部分。

LOG_BACKUP 
    需要日志备份，以将日志的头部前移（仅适用于完整恢复模式或大容量日志恢复模式）。 
    注意：日志备份不会妨碍截断。 完成日志备份后，日志的头部将前移，一些日志空间可能变为可重复使用。

ACTIVE_BACKUP_OR_RESTORE 
    数据备份或还原正在进行（所有恢复模式）。 
    数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。

ACTIVE_TRANSACTION 
    事务处于活动状态（所有恢复模式）。 一个长时间运行的事务可能存在于日志备份的开头。在这种情况下，可能需要进行另一个日志备份才能释放空间。有关详细信息，请参阅本主题后面的“长时间运行的活动事务”部分。 
    事务被延迟（仅适用于 SQL Server 2005 Enterprise Edition 及更高版本）。“延迟的事务 ”是有效的活动事务，因为某些资源不可用，其回滚受阻。有关导致事务延迟的原因以及如何使它们摆脱延迟状态的信息，请参阅延迟的事务。  
   
DATABASE_MIRRORING 
    数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库（仅限于完整恢复模式）。
   
REPLICATION 
    在事务复制过程中，与发布相关的事务仍未传递到分发数据库（仅限于完整恢复模式）。 有关详细信息，请参阅本主题后面的“事务复制与事务日志”部分。 
   
DATABASE_SNAPSHOT_CREATION 
    正在创建数据库快照（所有恢复模式）。 这是日志截断延迟的常见原因，通常也是主要原因。 
   
LOG_SCAN 
    正在进行日志扫描（所有恢复模式）。 这是日志截断延迟的常见原因，通常也是主要原因。

针对延迟日志截断原因的部分解决方案 
LOG_BACKUP  
    备份日志后再执行收缩即可backup log [database] with nolog 
   
REPLICATION 
    这种情况我遇到过两次，但我根本没有启用过REPLICATION，据查，这好像是SQLSERVER2008的一个BUG，解决方法是给标有“REPLICATION”的数据库任意一个表创建数据库事务复制（TRANSACTION REPLICATION），然后再删除，执行数据库与日志备份后，就可以收缩了。

附，sqlserver收缩日志：

http://www.cnblogs.com/zhaoguan_wang/p/4949176.html

[转]SQLServer2008日志文件无法收缩处理方法

标签：