機房在四月份改造中對數據庫的軟硬件進行了升級，具體情況是：原先舊有的數據庫是采用主備兩臺1u的單機，在windows 2000的系統下分別安裝好sql server 2000后，在主數據庫上做一天一次的完整備份和每隔兩小時的差異備份，在完整備份的同時進行發布；備數據庫則對主數據庫的完整備份進行訂閱。改造后的配置則是使用了帶兩個節點sdb01和sdb02的群集，并使用sdb03進行原先的備數據庫的訂閱工作。由于sdb01和sdb02兩臺機器上使用了windows 2003的系統，考慮到使用群集的情況，選用sql server 2005的兼容性會更好。于是就需要將sql2000上的數據庫遷移到sql2005，根據網上的方法在sql2000上進行了數據庫備份，然后在sql2005上新建一個同名數據庫，并使用還原數據庫的方法覆蓋該數據庫，接著對還原后的數據庫用戶進行必要的修改，一切看似遷移成功。

但隨著時間遷移，發現日志文件逐漸變大，三四個月后竟然達到10g之巨。期間有嘗試過處理，方法如下：

1.清空日志
DUMP TRANSACTION 庫名 WITH NO_LOG

2.截斷事務日志：
BACKUP LOG 數據庫名 WITH NO_LOG

3.收縮數據庫文件（如果不壓縮,數據庫的文件不會減小）
同時也注意到將數據庫的恢復模式從“完整”改為“簡單”。但是操作后的日志非但沒有減小，反而略有增大。也考慮到是否要使用分離數據庫的方法將日志文件刪除后，再附加數據庫。但這只是治標不治本的方法，且對系統的運行存在影響。

這時看到一篇文章介紹，用DBCC UPDATEUSAGE命令修復數據庫的行記錄數，修復了一些錯誤，但是還是無法收縮。根據該文章的提示，使用了這樣一個函數：DBCC OPENTRAN(Db_Name)，顯示類似下面的信息：

已復制的事務信息:
最早的分布式 LSN : (0:0:0)
最早的非分布式 LSN : (1051867:2025:1)
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。

而在其它正常的數據庫上運行這個命令，則沒有前面三行東西。接著使用了exec sp_removedbreplication ‘Db_Name’,奇跡出現了，該數據庫日志文件立馬減少到了1兆多。

為什么會出現這樣的情況呢？sp_removedbreplication的msdn解釋是：該存儲過程在發布服務器的發布數據庫中或在訂閱服務器的訂閱數據庫中執行。 該過程將從執行它的數據庫中刪除所有復制對象，但它不會從其他數據庫（例如，分發數據庫）中刪除對象。非常的拗口，難于理解。下面這句話相信同樣不好理解：如果將數據庫附加到的服務器不是該數據庫從中分離的服務器，并且啟用了分離的數據庫以進行復制，則應該運行 sp_removedbreplication 從數據庫刪除復制。

換言之，通常如果你設置過數據庫復制或發布，而后來設置失敗并沒有啟用，可能會導致這個問題，你看不到跟復制有關的內容，但是在數據庫里卻存在這樣的東西，于是日志被它堵住了，這成了一個永遠無法完成的命令，所以后續的日志都無法截斷。執行了這個命令以后，強制清除了復制內容。

因此我們的日志文件變得過大且無法正常截斷問題的根源可能在于：從sql2000升級到sql2005的過程中存在兼容性問題或者sql2005存在bug，因為在升級過后群集的數據庫發布與sdb03的訂閱是正常的。

轉載于:https://www.cnblogs.com/y0umer/archive/2011/07/05/3839314.html

總結

以上是生活随笔為你收集整理的sql server 2005日志文件过大问题解决后分析--针对发布订阅产生的日志问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。