?

如果回话是runnable，running或suspended状态，那么可能问题的根源是长时间运行，而不是孤立的事务。但是，只有进一步的调查才能确认。很有可能刚才的事务失败且连接重置，使用连接池，当前运行的语句不是打开事务所关联的。

?

在SQL Server 2005和后续版本，我们可以使用sys.dm_tran_session_transactions和sys.dm_tran_database_transactions对打开的事务收集信息，包括事务开始事件，打开事务使用的日志数，以及日志空间使用字节数，如我们刚才代码7.1所见。代码7.9展示了一个简单的版本，带有范例输出。

（代码7.9：收集打开事务的信息）

?

除非应用程序设计来检查，处理孤立的事务，清除事务的唯一方法是KILL会话，它会造成事务回滚，和连接中断一样，在下一次日志备份期间，允许日志里的空间是可以被重用的。但是，回滚的执行后果必须要理解的。

?

其他引起日志增长的可能原因

除了刚才提到的原因之外，还有其他一些问题阻止日志里空间重用，导致日志过度增长。这里我会谈其中的一些，这个问题的更多信息，可以看下Gail Shaw的文章，为什么我的事务日志满了？

?

REPLICATION

?

在事务复制期间，日志读取代理的任务是读取事务日志， 查找关联修改的日志记录，复制到订阅者（例如，“待定的复制”）。一旦修改被复制，会标记日志为“已复制”。缓慢或延迟的日志读取活动会导致记录剩为“待 定的复制”很长时间，在此期间它们还是活动日志的一部分，因此母VLF不能被截断。对于通过变更数据捕获（ Change Data Capture (CDC)）功能需要的日志记录也有类似的问题存在。

?

不管任何情况，sys.databases的 log_reuse_wait_desc列会显示REPLICATION作为问题根源。在事务磁盘阵列的输出性能里，这个问题本身也暴露了瓶颈。尤其是， 在并发写加载下的延迟读取操作。写入日志文件会持续发生，但用日志读取代理相关的和日志备份文件读取的读操作也要持续的。同一时间有持续的读和写发生，取 决于系统中的日志活跃级别和活动日志部分的大小，会导致磁头随机的I/O活动，因为磁头需要改变位置来读取活动日志的头，然后活动日志的尾。我们可以使用性能监视器（PerfMon）里磁盘计数器 Physical Disk\Disk Reads/sec 和 Physical Disk\Disk Writes/sec来故障排除这类问题，看下SQL Server的故障排除的免费电子书的第2章来进一步了解这个问题的细节：https://www.simple-talk.com/books/sql-books/troubleshooting-sql-server-a-guide-for-the-accidental-dba/

?

这些复制等待问题的故障排除的第一步是识别日志读取器，SQL 代理作业是否正常运行。如果不是的话，尝试启动它们。如果启动失败，你要找出为什么。

?

如果作业是运行的，但是复制一直等待，事务日志快速增长，你需要找到一些方法让相关的日志标记为“已复制”，这样的话它们的母VLF可以被重用。遗憾的是，没有完美的解决方案来避免复制或在CDC环境里的副作用，但你可以尝试下面方法中的一种。

?

在事务日志复制的情况下，使用sp_repldone命令来标记在日志读取器上当前正等待的所有日志记录为已复制，但还是需要重新初始化订阅者，CDC的话，这个命令不会解决事务日志增长的问题。

?

停用CDC或复制，进行数据的人为同步。停用CDC或复制后，事务日志中的待定复制的日志记录不会是待定，在完整或大容量日志恢复模式里的下次日志备份，或简单恢复模式里的检查点操作，会清除掉。但是，换来的代价是对于CDC环境需要数据的人为的同步，对于复制需要人为初始化订阅者，如果这个功能加回到数据库的话。

记住直接切换到简单恢复模式，希望能截断日志，是不行的，因为复制和CDC2个均不支持简单恢复模式，还是继续需要日志读取器直到日志读取器的SQL代理处理完成处理。

?

快照复制架构改变问题

?

在SQL Server 2005里使用快照复制有一个已知的问题，当架构修改时，它会导致应该标记为复制的架构修改没被标记。这个问题可以看下这个文章的解决方法：http://blogs.msdn.com/b/sqlserverfaq/archive/2009/06/01/size-of-the-transaction-log-increasing-and-cannot-be-truncated-or-shrinked-due-to-snapshot-replication.aspx

?

ACTIVE_BACKUP_OR_RESTORE

?

当log_reuse_wait_desc column列显示为ACTIVE_BACKUP_OR_RESTORE作为当前等待描述，长时间运行的数据库完整或差异备份是最有可能导致日志重用问题。在数据库完整或差异备份期间，备份过程会延迟日志截断，这样的话事务日志的活动部分会被包含为完整备份的一部分。在备份操作没完成期间，允许修改到数据库的页，当备份用WITH RECOVERY恢复时，可以让数据库恢复到一致的状态。如果这样的等待造成持续的问题，你会需要调查下优化备份过程的方式，例如提高备份性能（提供备份压缩）或者提高硬盘I/O系统的性能。

?

DATABASE_MIRRORING

?

当log_reuse_wait_desc column列显示为DATABASE_MIRRORING，作为当前等待描述，异步数据库镜像操作可能导致日志重用问题。

?

在异步镜像里，主上的事务只有一旦提交，相关的日志记录才会传输到镜像数据库。对于异步数据库镜像，主的日志不能截断直到日志记录已传输。当镜像问题发生时，主上大量的日志记录会保持为活动日志的一部分，阻止日志空间重用，直到复制到镜像完成。

?

对于异步数据库镜像，如果镜像不可用我们会看到DATABASE_MIRRORING，归因于断开或非常慢的连接，或镜像会话的挂起。对于异步数据库镜像，在正常操作和连接问题期间，我们会看到这个值。

?

在这个情况下，首先我会检查下受影响数据库的镜像会话状态。如果它们没有正确同步，那么你需要在主和镜像之间故障排除失败连接的原因。数据库镜像一个最常见的原因，当证书用来保证安全终端时，是证书过期，需要重新颁发证书。进一步讨论镜像连接问题处理已经不是这个文章的讨论范围，除非数据库已经正常同步，那么日志记录会发送到镜像，在主上事务日志的活动部分会继续增长，不能截断直到中断镜像配置。

?