Microsoft SQL Server - 這意味着事務日誌已滿？

Question

這意味着事務日誌已滿？我有它需要的時候增長20％的文件。驅動器上剩下4GB。我該如何永久解決這個問題？ 運行這些命令，暫時解決了這個問題：

 
DBCC SHRINKFILE('MyDatabase_log', 1) 
BACKUP LOG MyDatabase WITH TRUNCATE_ONLY 
DBCC SHRINKFILE('MyDatabase_log', 1) 

Answer 1

事務日誌是SQL服務器'記錄'它所做的每一個更改，以便如果出現問題（從軟件崩潰到電源故障，小行星罷工......也許不是一個小行星罷工），它可以通過從最後一致的「CheckPoint」中「撤消」它所做的所有更改來「恢復」 - 回到數據庫的最後一個「一致」狀態......在該檢查點。每次事務完成（或「提交」）時，存儲在事務日誌中的所有更改都會標記爲「正常」，並且CheckPopint標記可以在這些更改之後向前移動，以便將來進行恢復在那之後只會「撤銷」到某個點的變化。在發生這種情況之後，CheckPoint之前的事務日誌中的所有條目不再需要從系統崩潰中恢復......但是它們仍然可能需要從硬盤崩潰中恢復，所以...

正如另一位先生提到的那樣，您在服務器上設置的「恢復模式」控制着檢查點之前發生的事務日誌條目。在簡單模式下，當檢查點發生時，它們將被刪除，但是如果主數據磁盤崩潰，則存在風險，因爲事務日誌不包含自上次備份以來寫入磁盤的更改。

在其他恢復模式，事務日誌項不會被刪除，直到你做一個備份，從而保護您免受這種風險...

所以，通常，發生此問題時，那是因爲服務器在其中一個「正常」（而不是簡單）恢復模式設置，（增量或完整），他們沒有做備份......。在這種情況下，交易日誌只是不斷增長...，並且增長...有點像電視上的那些前列腺廣告...

Answer 2

你應該看看SQL Server Recovery models。簡單的答案是將恢復模式更改爲「簡單」，但這會影響備份/恢復。

Answer 3

我不會做20％的增長率。當它需要增長時會產生很大的後果。如果它增長到100GB，那麼在下一次增長時它將不得不增長20GB--爲系統的減速做準備，而不是發生這種情況......相反，我將它設置爲固定速率 - 比如100MB 。當然，我們不知道目前的尺寸以作出更準確的建議。

Answer 4

備份通常會在每次備份數據庫時清除事務日誌。

Answer 5

這聽起來像你沒有適當的備份策略。執行任何備份 - 完全備份，差異備份或事務日誌 - 將會截斷日誌，同時還可以節省您可以在發生故障時從中恢復的點。您可以運行數據庫維護向導來幫助您設置定期運行的備份計劃。

如果你真的不關心你的數據（在這種情況下，我想你爲什麼有一個數據庫），那麼你可以設置數據庫的恢復模式爲「簡單」，這將阻止TLog從成長。最後一件事：如果您正在進行批量加載操作，您也可以在進行批量操作時考慮更改爲「批量記錄」。

Answer 6

您必須備份事務日誌而不僅僅是數據庫，否則日誌將繼續增長，直到空間用完。

Answer 7

有許多不同的方法來解決這個問題。這取決於您的備份要求。

主要問題是您的事務日誌不會定期備份，這會導致事務日誌不斷增長。

SQL Server 2005中有一個簡單恢復模式，這是我在開發和測試環境中主要使用其中不要求每小時的快照（屬性/數據庫本身的選項），事務日誌只生長足以應付最大的事務在服務器上運行。此恢復模式不需要計劃或維護計劃。

在SQL Server 2000中，你基本上已經跑你使用相同的命令定時備份腳本，每小時左右：

BACKUP LOG MyDatabase WITH TRUNCATE_ONLY

對於生產環境，通常我們有一個小時事務日誌備份數據庫維護計劃中預定的每日完整備份。這使得事務日誌被截斷爲合理的大小（顯然，這個大小可以保存1小時的事務數據）。

Answer 8

另一個簡單的答案是您的備份可能沒有安排。在升級週期中，我們的一個數據庫備份計劃已從作業中刪除。日誌增長直到我們發現備份沒有運行。