數據庫的事務日誌已滿

我有一個長時間運行的進程，在整個持續時間內保持打開一個事務。數據庫的事務日誌已滿

我無法控制它的執行方式。

因爲事務在整個持續時間內保持打開狀態，所以當事務日誌填滿時，SQL Server不能增加日誌文件的大小。

因此該過程失敗，並顯示錯誤"The transaction log for database 'xxx' is full"。

我試圖通過增加數據庫屬性中事務日誌文件的大小來防止這種情況，但是我得到了同樣的錯誤。

不知道接下來應該嘗試什麼。該過程運行幾個小時，因此玩試驗和錯誤並不容易。

任何想法？

如果有人有興趣，這個過程是在Microsoft Dynamics CRM 4.0.

組織進口有足夠的磁盤空間，我們在日誌中簡單記錄模式和之前已經拉開過程中備份的日誌。

- = - = - = - = - 更新 - = - = - = - = -

感謝所有到目前爲止的意見。下面是什麼使我相信，日誌就不會發展，是因爲打開的事務：

我收到以下錯誤......

Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception: 
System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

所以下面這個建議我去「log_reuse_wait_desc column in sys.databases」並保持值「ACTIVE_TRANSACTION」。

據微軟稱： http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

這意味着：

事務處於活動狀態（所有恢復模式）。 •日誌備份開始時可能存在長時間運行的事務。在這種情況下，釋放空間可能需要另一個日誌備份。有關更多信息，請參閱本主題後面的「長時間運行的活動事務」。

•事務被延遲（僅SQL Server 2005 Enterprise Edition及更高版本）。延遲事務實際上是一個活動事務，其回滾由於某些不可用的資源而被阻止。有關延期交易原因以及如何將其移出延期狀態的信息，請參閱延期交易。

我誤解了一些東西嗎？

- = - = - = - UPDATE 2 - = - = - = -

剛啓動了與設定爲30GB初始日誌文件的大小的過程。這將需要幾個小時才能完成。

- = - = - = - 最後的更新 - = - = - = -

這個問題實際上是由日誌文件消耗所有可用磁盤空間所致。在最後一次嘗試中，我釋放了120GB，它仍然使用了所有這些，最終失敗了。

我沒有意識到這是以前發生的，因爲當這個過程在一夜之間運行時，它會在失敗時回滾。這次我能夠在回滾之前檢查日誌文件的大小。

謝謝大家的意見。

來源

2013-07-16 Jimbo

重新「...並備份了日誌」....如果數據庫處於簡單模式，您將無法備份日誌，日誌備份不適用於簡單模式。它是否被批量記錄？ – SqlACID

我備份了整個數據庫並對其進行了縮小，導致日誌縮小到1MB。然後，我將日誌文件的大小最初增加到20GB，現在增加到30GB。 – Jimbo

這是一次性腳本還是定期發生的工作？

過去，對於臨時需要大量日誌文件空間的特殊項目，我創建了第二個日誌文件並使其變得非常龐大。一旦項目完成，我們將刪除額外的日誌文件。

來源

2013-07-16 11:35:01

我不會說這是一項一次性工作，但我們必須這樣做是很少見的。我沒有創建第二個日誌文件，但我確實將當前日誌文件的初始大小增加到30GB。在我上次運行時，它被設置爲20GB，但仍然失敗。 – Jimbo

考慮到我只有一個驅動器可以使用，會有第二個日誌文件比以前更好嗎？ – Jimbo

現在我記得，附加文件主要使我們能夠訪問另一個更大的驅動器。 –

您是否有啓用自動增長功能和無限制文件增長是否都啓用了日誌文件？您可以在「數據庫屬性>文件」中通過SSMS編輯這些文件

來源

2013-07-16 11:21:54

是的。它設置爲自動增長10％，不受限制。問題是自動增長在存在未完成事務時不起作用。 – Jimbo

你知道這筆交易有多大嗎？嘗試設置事務日誌大小大於估計值，無論如何，如果磁盤分配不是問題，請在開始時分配足夠的空間以用於數據和日誌。它提高了性能。不要我們*自動增長10％*，由少數幾個GB來做，所以性能會足夠好。 –

SQL Server *將在事務處理期間自動增長日誌，如果它需要更多空間來完成該事務。 –

這是一種老派的方法，但是如果您在SQL中執行迭代更新或插入操作，而且運行很長時間，則定期（以編程方式）調用「檢查點」是個好主意。調用「檢查點」會導致SQL向磁盤寫入所有這些僅限內存的更改（髒頁面，它們被調用）以及存儲在事務日誌中的項目。這具有定期清理您的事務日誌的效果，從而防止像所描述的問題。

來源

2013-07-16 12:17:33 Brian

不幸的是，我無法控制過程的執行方式。 Dynamics CRM是一個Microsoft應用程序，組織導入過程是該應用程序的一部分。 – Jimbo

明白...祝你好運 – Brian

以下內容將截斷日誌。

USE [yourdbname] 
GO 

-- TRUNCATE TRANSACTION LOG -- 
DBCC SHRINKFILE(yourdbname_log, 1) 
BACKUP LOG yourdbname WITH TRUNCATE_ONLY 
DBCC SHRINKFILE(yourdbname_log, 1) 
GO 

-- CHECK DATABASE HEALTH -- 
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN RETURN 0 END 
GO

來源

2014-04-05 14:43:26 Pinal

嘿Pinal，這個功能從SQL Server 2008和以上版本完全刪除：http://www.brentozar.com/archive/2009/08/backup-log-with-truncate-only-in -sql-server-2008/ – Conor

對於更高版本，請嘗試備份日誌 TO DISK = N'NUL：' – HansLindgren

我有這個錯誤一次，它最終成爲服務器的硬盤驅動器用完磁盤空間。

來源

2014-06-05 13:59:18 PretoriaCoder

要解決此問題，更改恢復模式到簡單然後收縮文件日誌

1. 數據庫屬性>選項>恢復模式>簡單

2. 數據庫任務>收縮>文件>日誌

完成。

然後在檢查你的數據庫日誌文件的大小數據庫屬性>文件>數據庫文件>路徑

要查看完整的SQL Server日誌：打開日誌文件查看器在 SSMS>數據庫>管理器> SQL Server日誌>當前

來源

2014-07-14 03:16:34 user3774600

不，這不能解決問題。問題在於日誌文件在長時間運行過程中增長，直到磁盤空間用完。通過將日誌文件臨時移到另一個具有1TB可用空間的驅動器進行更正。您正在進行一項長時間運行的流程 - 即保持打開一個事務 - 的過程中，您無法收縮日誌文件。這個過程全權負責文件的增長。 – Jimbo

正如@Jimbo所說，這並不能解決OP的問題。它可能釋放一些當前未使用的空間，但一旦長時間交易再次運行，空間將再次被佔用（甚至可能更早失敗） – Marcel

完美！謝謝！ –

如果您的數據庫恢復模式已滿並且您沒有日誌備份維護計劃，則會出現此錯誤，因爲事務日誌因LOG_BACKUP而變滿。

這將阻止對此數據庫的任何操作（例如收縮），並且SQL Server數據庫引擎將引發9002錯誤。

爲了克服這種行爲，我建議你檢查這個The transaction log for database ‘SharePoint_Config’ is full due to LOG_BACKUP，它顯示瞭解決問題的詳細步驟。

來源

2016-07-06 00:04:05 DevoWorx

數據庫的事務日誌已滿

回答

相關問題