維護 SQL 日誌文件
我今天收到一封電子郵件，說我們有一個增長到 278GB 的日誌文件，並詢問是否有人在維護它。我已經知道答案是否定的，因為我們沒有 dba（除了我自己。我對 sql 了解很多，但我是一名開發人員）。
我們的數據庫規模適中；一些表有數以百萬計的記錄。不過，這對於日誌文件來說似乎相當大，我想要一些方向來確定這是否異常，我們是否可以配置更好的東西，或者最好的解決方案是否只是接受我們需要餵野獸更多高畫質空間。
如果有更多資訊我可以在此處發布以幫助我獲得更好的答案，請告訴我。
聽起來數據庫設置為完全恢復模式，並且沒有執行事務日誌備份。這是一個非常普遍的問題。
如果您不想進行時間點恢復、日誌傳送或任何類似的操作，並且您對只能恢復到上次完整備份完成的點感到滿意，請將您的數據庫設置為簡單恢復模式並將您的日誌文件縮小到理智的東西。
如果您正在進行日誌備份，請確保它們執行時沒有錯誤，並考慮增加它們的頻率。
也有可能某事在幾小時/幾天/幾週/幾個月前開始了交易，但從未送出過。日誌的活動部分不能被截斷，並且這些部分在事務送出或回滾之前不會變為非活動狀態。使用 DBCC OPENTRAN（MSDN 目前已關閉，因此我現在無法提供連結）進行故障排除，它將向您顯示有關數據庫中執行時間最長的事務的資訊。如果您發現您有一個長時間執行的事務，您可能很難讓應用程序送出。當然，您可以終止該連接，但您將失去它在這些小時/天/週/月內所做的任何數據庫修改。您可能需要在應用程序的某處修復一些程式碼。
同樣，在你解決了問題之後，你會想要把你的日誌文件縮小到一些正常的東西。您可以使用性能監視器查看隨著時間的推移實際使用了多少空間。作為一個從臀部開始的總數量，我的目標是大小為最大表格的 1.25 倍（以 GB 為單位，而不是以行為單位），並將文件配置為增長。