私は、トランザクションを全期間オープンにしておく長期実行プロセスを持っています。
私はこれが実行される方法を制御することはできません。
トランザクションはトランザクションログがいっぱいになると、開いたままになるので、SQL Serverはログファイルのサイズを増やすことはできません。
そのため、プロセスはエラー"The transaction log for database 'xxx' is full"
で失敗します。
データベースのプロパティでトランザクションログファイルのサイズを増やすことでこれを防ぐことを試みましたが、同じエラーが発生します。
次に何を試すべきかわからない。このプロセスは数時間実行されるため、試行錯誤するのは簡単ではありません。
何か案は?
誰かが興味を持っているのであれば、そのプロセスはMicrosoft Dynamics CRM 4.0.
内の組織のインポートです。
十分なディスク容量があります。ログを簡易ログモードにして、プロセスを開始する前にログをバックアップしました。
- = - = - = - = - UPDATE - = - = - = - = -
これまでのコメントをありがとう。以下は、オープントランザクションが原因でログが大きくならないと私に信じさせたものです。
次のようなエラーが表示されます。
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/ja-jp/library/ms345414(v = sql.105).aspx
それは次のことを意味します。
トランザクションはアクティブです(すべての復旧モデル)。 •ログバックアップの開始時に長時間のトランザクションが存在する可能性があります。この場合、スペースを解放すると、別のログバックアップが必要になる可能性があります。詳細については、このトピックの後半の「長期アクティブトランザクション」を参照してください。
?トランザクションが遅延されている(SQL Server 2005 Enterprise Edition以降のバージョンのみ)。遅延トランザクションは事実上アクティブなトランザクションであり、そのロールバックは利用できないリソースのためにブロックされます。遅延トランザクションの原因とそれらを遅延状態から移行する方法については、「遅延トランザクション」を参照してください。
私は何かを誤解しましたか?
- = - = - = - UPDATE 2 - = - = - = -
初期ログファイルのサイズを30GBに設定してプロセスを開始したところです。これが完了するまでに数時間かかります。
- = - = - = - 最終更新 - = - = - = -
この問題は実際には、ログファイルが使用可能なすべてのディスク容量を消費したために発生しました。最後の試みで私は120GBを解放しました、そしてそれはまだそれのすべてを使い果たして、そして最終的に失敗しました。
プロセスが一晩実行されていたときに失敗したときにロールバックしていたので、私はこれが以前に起こっていたことに気づかなかった。今回はロールバックの前にログファイルのサイズをチェックすることができました。
ご意見ありがとうございました。
これは一時的なスクリプトですか、それとも定期的に発生する仕事ですか?
以前は、ログファイル用に一時的に多くのスペースを必要とする特別なプロジェクトのために、2番目のログファイルを作成し、それを巨大にしました。プロジェクトが完了したら、余分なログファイルを削除しました。
この問題を解決するには、リカバリモデルを単純に変更し、次にファイルログを縮小
1.データベースのプロパティ>オプション>回復モデル>単純
2.データベースタスク>縮小>ファイル>ログ
完了しました。
次に、[データベースのプロパティ]> [ファイル]> [データベースファイル]> [パス]でdbログファイルのサイズを確認します。
完全なSQL Serverログを確認するには、次の手順を実行します。SSMS>データベース> Management> SQL Server Logs> CurrentでLog File Viewerを開きます。
私は一度このエラーに遭遇し、それはディスクスペースを使い果たすサーバーのハードドライブになってしまいました。
ログファイルに対して自動成長を有効にするとファイルの無制限の拡大の両方が有効になっていますか。 SSMS経由で[データベースのプロパティ]> [ファイル]でこれらを編集できます。
これは昔ながらの方法ですが、SQLで反復的な更新または挿入操作を実行している場合は、定期的に(プログラム的に) "checkpoint"を呼び出すことをお勧めします。 "checkpoint"を呼び出すと、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'のためにいっぱいになりました。 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