データベースのトランザクションログがいっぱいです

トランザクションを開いたままにしておく長時間のプロセスがあります。

これを実行する方法を制御できません。

トランザクションは全期間開いたままになっているため、トランザクションログがいっぱいになると、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"を保持しました。

Microsoftによると：http : //msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

つまり、次のことを意味します。

トランザクションがアクティブです（すべての復旧モデル）。•ログバックアップの開始時に、長時間実行されているトランザクションが存在する可能性があります。この場合、スペースを解放するには、別のログバックアップが必要になる場合があります。詳細については、このトピックで後述する「長時間実行されるアクティブトランザクション」を参照してください。

•トランザクションは遅延されます（SQL Server 2005 Enterprise Edition以降のバージョンのみ）。遅延トランザクションは、リソースが使用できないためにロールバックがブロックされるアクティブなトランザクションです。遅延トランザクションの原因と、それらを遅延状態から移動する方法については、遅延トランザクションを参照してください。

私は何かを誤解しましたか？

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

最初のログファイルサイズを30GBに設定してプロセスを開始しました。完了するまでに数時間かかります。

-=-=-=-最終更新-=-=-=-

この問題は実際には、ログファイルが使用可能なすべてのディスク領域を消費していることが原因でした。最後の試みで私は120GBを解放しましたが、それでもすべてを使用し、最終的に失敗しました。

プロセスが夜間に実行されていたときに、障害が発生するとロールバックされていたため、これが以前に発生していることに気付きませんでした。今回は、ロールバック前にログファイルのサイズを確認できました。

ご協力ありがとうございます。

これは1回限りのスクリプトですか、それとも定期的に発生するジョブですか？

以前は、一時的にログファイルに多くのスペースを必要とする特別なプロジェクトのために、2つ目のログファイルを作成して巨大にしました。プロジェクトが完了したら、余分なログファイルを削除しました。

この問題を解決するには、リカバリモデルをシンプルに変更してから、ファイルログを圧縮します

1. データベースのプロパティ>オプション>復旧モデル>シンプル

2. データベースタスク>圧縮>ファイル>ログ

できました。

次に、[データベースのプロパティ]> [ファイル]> [データベースファイル]> [パス]でdbログファイルのサイズを確認します。

SQLサーバーの完全なログを確認するには、SSMS>データベース>管理> SQLサーバーログ>現在のログファイルビューアーを開きます。

一度このエラーが発生し、サーバーのハードドライブがディスク領域を使い果たしました。

あなたが持っている自動拡張を有効にし、無制限のファイルの成長をログファイルの両方に有効？これらは、「データベースのプロパティ>ファイル」のSSMSで編集できます。

これは古いアプローチですが、SQLで反復的な更新または挿入操作（長時間実行されるもの）を実行している場合は、定期的に（プログラムで）「チェックポイント」を呼び出すことをお勧めします。「チェックポイント」を呼び出すと、SQLはメモリのみの変更（ダーティページ、それらが呼び出される）とトランザクションログに格納されているアイテムをすべてディスクに書き込みます。これにより、トランザクションログが定期的に消去されるため、上記のような問題を回避できます。

以下はログを切り捨てます。

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

データベースの復旧モデルがいっぱいで、ログバックアップのメンテナンスプランがない場合は、トランザクションログがいっぱいになるため、このエラーが発生しLOG_BACKUPます。

これにより、このデータベースでのアクション（縮小など）が防止され、SQL Serverデータベースエンジンで9002エラーが発生します。

この問題を解決するには、これを確認することをお勧めします。問題を解決するための詳細な手順を示すLOG_BACKUPが原因で、データベース 'SharePoint_Config'のトランザクションログがいっぱいです。

「データベース '...'のトランザクションログは、ディスクスペースを解放するためにデータベースのテーブルから古い行を削除しているときに 'ACTIVE_TRANSACTION'が原因でいっぱいになりました。行数が私の場合、削除されるサイズが1000000より大きいため、1つのDELETEステートメントを使用する代わりに、DELETE TOP（1000000）....ステートメントを使用して削除タスクを分割しました。

例えば：

このステートメントを使用する代わりに：

DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

次のステートメントを繰り返し使用します。

DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

制限付き削除を複数回実行することで問題が解決しましたなどの

前

DELETE FROM TableName WHERE Condition

後

DELETE TOP(1000) FROM TableName WHERECondition

質問への答えは、テーブルから行を削除することではありませんが、アクティブなトランザクションが原因で使用されているtempDBスペースです。これは主に、更新の挿入とトランザクションの削除を試みるマージ（アップサート）が実行されているときに発生します。唯一のオプションは、DBが単純な復旧モデルに設定されていることを確認し、ファイルを最大スペースに増やす（他のファイルグループを追加する）ことです。これには独自の長所と短所がありますが、これらは唯一のオプションです。

もう1つのオプションは、マージ（アップサート）を2つの操作に分割することです。1つは挿入を行い、もう1つは更新と削除を行います。

これを試して：

USE YourDB;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE YourDB
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 50 MB.  
DBCC SHRINKFILE (YourDB_log, 50);  
GO  
-- Reset the database recovery model.  
ALTER DATABASE YourDB
SET RECOVERY FULL;  
GO 

お役に立てば幸いです。

これが私のヒーローコードです。私はこの問題に直面しました。そして、このコードを使用してこれを修正します。

 USE master;

    SELECT 
        name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled 
    FROM 
        sys.databases 
    WHERE 
        name = 'XX_System';

    SELECT DATABASEPROPERTYEX('XX_System', 'IsPublished');


    USE XX_System;
    EXEC sp_repldone null, null, 0,0,1;
    EXEC sp_removedbreplication XX_System;


    DBCC OPENTRAN;
    DBCC SQLPERF(LOGSPACE);
    EXEC sp_replcounters;



    DBCC SQLPERF(LOGSPACE);

これを試して：

可能であれば、サービスMSSQLSERVERおよびSQLSERVERAGENTを再起動します。