有两种情况，可能出现这个问题。一是应用系统给SQL Server发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。二是客户端向SQL Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。

　　对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志。因为给SQL Server发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。

　　对于第二种情况，道理也同上。只是在处理它时，需慎重从事。如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。若该事务被强行回滚，SQL Server需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。