因為 Replication 移除時發生錯誤，導致後續雖然復原模式設定為 Simple，但交易記錄檔仍然持續長大。
這幾天正想要花時間好好消化一下 Techday 2013 的資料時，忽然收到一個同事傳來的訊息，要幫忙看一下他所遇到的一個資料庫的問題。
從傳來的圖像上看起來，這個是一個 SQL Server 2005 的資料庫，復原模式設定為「簡單」，但是很特別的是 Log 檔案居然成長到 14G，實在有點特別。
LOG 檔案大的嚇人
同事也嘗試使用「DBCC SHRINKDATABASE」的指令來進行壓縮，但看起來並沒有多大的效果。
於是想到把這次 Techday 2013 時，剛好有聽到百敬老師所介紹的「深入了解 SQL Server 交易紀錄」，於是立刻現學現賣，當下先使用 「DBCC LOGINFO」 的指令來查看 Log 檔案的資訊
看起來的確怪怪的，正常來說復原模式是 SIMPLE 的話，當發生 CheckPoint 的時候，則應該會有 VLF ( virtual log files ) 的 Status 應該是要有 0 ，這樣才能 Reuse ，但目前看到的所有都是紀錄為 2，似乎沒有任何一個 VLF 是可以 Reuse 的，因此才會導致 LOG FILE 一值在成長。
因此這個時候就要想到當時有作筆記，記得要查看 sys.databases 裡面的 log_euse_wait_desc 資訊
1: select name, recovery_model_desc, log_reuse_wait_desc
2: from sys.databases
3: where name = 'TEST'
果然找到罪魁兇手了，原來是可能該資料庫可能之前有設定 REPLICATION，後來移機或者是備份還原的時候，沒有去注意到之前有設定過，造成這個資料庫一值以為自己處在 Replication 的狀態，導致當 Checkpoint 發生之後，依然無法 reuse VLF。
可是遇到這樣的狀況該如何來解決呢 ? 檢查一下的確沒有設定 Replication 的話，那麼就可以使用以下的指令
1: use [master]
2: EXEC sp_removedbreplication @dbname = 'TEST'
接下來就可以重新再使用 DBCC SHRINKDATABASE 的指令來壓縮資料庫了，從訊息中看起來 LOG 檔案似乎有真的縮小了。
再檢查一下真的如我們想要的縮小到我們想到的狀況了。
