SQL Server日誌文件在簡單恢復模式下填充

我在SQL Server 2008 R2中有一個數據庫，其中有數百萬個文件存儲爲varbinary blob。我上週設置了一個過程來執行以下操作：SQL Server日誌文件在簡單恢復模式下填充

使用一些實體框架代碼來獲取具有blob的行（即實體）。
將blob流複製到對象存儲。
使用商店中的新對象ID更新數據庫中的實體。

我有30個線程經常這樣做，這個過程仍然需要幾天。幾天前，數據庫日誌文件已填滿，我相信它必須由此過程引起。我確定時間點備份對於此數據庫並不重要，並且將數據庫設置爲使用簡單恢復模式。然後昨天我再次從我的過程中得到錯誤，說日誌文件填滿了！這在簡單模式下如何實現？！任何想法我能做些什麼來阻止這種情況的發生？當我監視日誌文件時，SQL Server會讓它達到7％的飽和度，然後將其截斷爲零，所以我感到非常困惑。看起來好像當完整備份開始時日誌文件開始增長未被選中...

來源

2012-12-26 influent

即使在簡單恢復模式下，SQL Server也會填充日誌文件以保持ACID合規性並允許回滾（或「轉發「在某些災難恢復情況下）。因此，您需要有足夠的空間來至少處理它可能一次收到的交易，否則它將自動增長或出現錯誤。

現在作爲一個實際問題，您有幾個選項。最簡單的就是給它足夠的空間來處理交易。另一種方法是將其分解爲更少的事務，因爲在簡單恢復中，一旦事務完全提交併最終完成，它將允許重用該空間。

爲清晰起見並對意見進行編輯：即使未調用明確的操作，SQL Server也會在隱式事務中放置幾乎所有的操作（這裏有一些例外，但這些操作並不重要）。所以，如果你說執行一個插入一百萬行的命令，它將爲該插入提供一個隱式事務，並且即使在簡單恢復模式下，所有這百萬行都會影響事務日誌，直到事務完全提交併完成。如果你想讓它更快地釋放空間，重寫你的代碼，以便插入一百萬行而不是一條語句，而你有十條語句插入十萬條。

從您的問題中可以看出，在完整備份過程中，只有只有增長，但是備份過程確實會影響其在發生日誌時釋放空間的能力。這是因爲完整備份還包含日誌文件中的數據，因此服務器需要確保在備份過程中信息可用。在In Recovery有相關的討論。

我通常會極度不願推遲計劃的備份，但它可能有助於這種特殊情況。這聽起來像是把你的交易分成小塊可能最終成爲一種方式。

來源

2012-12-26 17:32:38 TimothyAWiseman

我根本沒有使用事務，至少沒有明確地說，我沒有剩餘的空間來分配。我不認爲你的回答告訴我爲什麼它只在完全備份期間增長，是嗎？我的猜測是，這與那裏沒有任何活動的休息點有關。 – influent

@influent我編輯了答案來澄清。 SQL Server不*需要一個沒有活動的休息點，但它確實需要在備份開始之前啓動的事務完成。 – TimothyAWiseman

謝謝。每條語句只更新一行，沒有批次。我明白現在發生了什麼（http://technet.microsoft.com/en-us/library/ms345414.aspx，ACTIVE_BACKUP_OR_RESTORE），但我不知道如何解決它，因爲我沒有任何剩餘空間。我可能必須在另一個驅動器上添加第二個日誌文件，以便完整備份可以在日誌文件沒有填滿的情況下完成。 – influent

它好像日誌文件開始全面備份開始時增長未選中...

所以，當你正在做一個完整的備份只生長？這是有道理的，因爲完整備份包含所有數據頁面以及在備份過程中生成的日誌記錄範圍。

所以，當備份運行時，日誌可能無法被截斷。請注意，這是（受過教育的）我的猜測。

您可以通過查看sys.databases.log_reuse_wait_desc值來確認這一點。

來源

2012-12-26 18:12:04 usr

我確認了，謝謝。 – influent

SQL Server日誌文件在簡單恢復模式下填充

回答

相關問題