有兩種情況，可能出現這個問題。一是應用系統給SQL Server發送了一個用戶自定義事務，一直未提交，這個最早活躍事務阻礙系統截斷日志。二是客戶端向SQL Server發送了一個修改數量大的事務，清日志時，該事務還正在執行之中，此事務所涉及的日志只能等到事務結束後，才能被截掉。
對於第一種情況，只要督促用戶退出應用或者提交事務，系統管理員便可清掉日志。因為給SQL Server發送Dump transaction with no-log或者with truncate-only，它截掉事務日志的非活躍部分。所謂非活躍部分是指服務器檢查點之間的所有已提交或回退的事務。而從最早的未提交的事務到最近的日志記錄之間的事務日志記錄被稱為活躍的。從此可以看明，打開的事務能致使日志上漲，因為在最早活躍事務之後的日志不能被截除。
對於第二種情況，道理也同上。只是在處理它時，需慎重從事。如果這個大事務已運行較長時間，應盡量想法擴大數據庫日志空間，保證該事務正常結束。若該事務被強行回滾，SQL Server需要做大量的處理工作，往往是正向執行時間的幾倍，系統恢復時間長，可能會影響正常使用的時間。
