运行环境：windows server2003，sql
server2008 R2，数据库上布置CDC
用户反应系统报错是日志已满，系统不能运行。查看日志文件时，发现日志文件已经达到15G，后来为了解决问题，干脆把数据库移到另一个F盘，D盘专门放日志文件，空间有80G。当时想这80G至少保证系统运行一周吧！谁知道系统刚运行两天，日志文件已爆涨到80G，D盘空间仅剩余10MB，数据库做任何动作都不可以。又一次为了应急把日志文件直接删除（先停掉服务，删除日所文件，再通过DBCC
CheckDB()命令检查数据库一致性问题），系统恢复了正常。
这时空间是有了，但是问题依旧没有解决，但是日志文件依然猛涨，以前用的截断和收缩日志方法完全不起作用？
解决方法：
步骤一：
查看日志信息，在查询分析器中执行如下代码来查看日志信息：
DBCC LOGINFO(‘数据库名称‘)
可以看到status=0的日志，代表已经备份到磁盘的日志文件；而status=2的日志还没有备份。当收缩日志文件时，收缩掉的空间其实就是 status=0的空间，如果日志物理文件无法减小，这里一定能看到非常多status=2的记录。
步骤二：
查看日志不能截断原因
活跃(active)的日志无法通过收缩来截断，有各种原因会使日志截断延迟，具体表现就是事务日志的物理文件无法通过截断、收缩来减小，通过下面的代码可以看到实例上每个数据库的日志截断延迟原因：
usemaster
go
select*
from sys.databases
发现当前数据库的log_reuse_wait_desc的值为REPLICATION，其他数据库的log_reuse_wait_desc值为LOG_BACKUP、NOTHING…
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
备份日志后再执行收缩即可。
REPLICATION
这是我遇到的情况，但我根本没有启用过REPLICATION，是已离职同事原来创建一个复制数据库，后来没有删除干净而导致。还有另一说法，这好像是SQLSERVER2008的一个BUG，解决方法是给标有“REPLICATION”的数据库任意一个表创建数据库事务复制（TRANSACTIONREPLICATION），然后再删除，执行数据库与日志备份后，就可以收缩了。
注明：在创建数据库复制时，我也遇到了一个大麻烦，提示：在执行 xp_cmdshell 的过程中出错。调用 ‘CreateProcess‘ 失败，错误代码: ‘5‘。使用了各种方法，均无效果。后来在网上找一个帖子说有可能是系统安装360的原因而导致，我就把把360先停掉，结果真的解决问题了。