IT工程師數位筆記本

前言

今天算是遇到了一個罕見的案例。

SQL日志文件不斷增長的各種實例不用多說，園子里有很多牛人有過介紹，如果我再闡述這些陳谷子芝麻，想必已會被無數次吐槽。

但這次我碰到的問題確實比較詭異，其解決方式也是我第一次使用。

下文將為各位看管詳細介紹我的解決思路。

現象

一客戶反饋數據庫的日志文件不斷增長，已分配的磁盤空間快使用完，嘗試過事務日志截斷（事務日志備份）的操作，但沒有任何效果。

分析

遇到這個問題，我最直接的感受：肯定有大的事務一直在執行，導致日志備份無法截斷事務日志的大小。

首先，我在該數據庫下運行DBCC loginfo()

                                          圖一

從圖一的紅色框可以看到，數據庫的多個VLF的狀態都為2，也就是active狀態。（如果為0 ，表示為inactive）。

這表明這些日志文件確實都在活動狀態，一般而言，導致這種現象的原因主要有三種：長事務的運行、replication和mirroring延遲。

但這個客戶沒有采用replication和mirroring，所以我初步鎖定問題是因為長事務的運行導致。按照常規的方法，我只需分析下這個事務是否遇到阻塞、死鎖等情況，然后給出對應的解決方案即可。（但實際情況并非如此）

為保險起見，我運行如下語句來驗證下我的判斷：

SELECT log_reuse_wait_desc, * FROM sys.databases WHERE NAME='dbname'

                                                                                           圖二

顯然，我的判斷錯了，可以看到，目前【log_reuse_wait_desc】的狀態為【REPLICATION】。也就是說正是事務日志分發導致日志文件不斷增大的原因。

正如前文分析的，這個數據庫并沒有用作發布訂閱，怎么會出現這個狀態呢？

經與客戶溝通，了解這個數據庫其實是從一個發布訂閱的數據庫中還原過來的，盡管新的數據庫并沒有采用發布訂閱，但數據庫中發布訂閱的一些配置選項還在，從而導致了數據庫的誤判，致使日志文件不斷增大。

方案

知道了原因就好辦了。

起初我想通過sp_droppublication來完全刪除分發訂閱的配置，但無法通過sp_helppublication獲取到@publication的名字（提示：命令已執行完！），因此這條路走不通了。

在網上找些資料，發現了sp_removedbreplication這個存儲過程，執行后再去收縮日志文件，問題果然解決！

EXEC sp_removedbreplication dbname

DBCC SHRINKFILE(Logfilename)

DBCC loginfo()

                                                  圖三

總結

盡管本文的場景比較少見，但總體解決的思路與其他（日志文件不斷增長）其實是一樣的。少許地方不太明白可以通過網絡等一些工具獲得。這也說明了SQL原理的重要性，借用一本書的序言中的一句話【越接觸本質越不會迷茫！】。多接觸原理，很多東西都是觸類旁通的。