トランザクション ログの切り捨て

更新 : 2007 年 9 月 15 日

トランザクション ログからログ レコードが削除されないと、ログ レコードは物理ログ ファイルで利用可能なすべての領域がなくなるまで拡張されます。ログの切り捨てにより、ディスクの領域が自動的に解放されて、トランザクション ログで再利用できるようになります。

何らかの理由で遅延した場合を除き、ログの切り捨ては次のように自動的に行われます。

• 単純復旧モデルでは、チェックポイントの後に行われます。
• 完全復旧モデルまたは一括ログ復旧モデルでは、前のバックアップの後にチェックポイントが発生した場合、ログ バックアップの後に行われます。詳細については、後の「完全復旧モデルと一括ログ復旧モデルでのログの切り捨て」を参照してください。

ログの切り捨ては、自動的に行われますが、さまざまな要因で遅延する場合があります。ログの切り捨ての遅延要因の詳細については、「ログの切り捨てが遅れる要因」を参照してください。

重要 :
ログの切り捨てでログの遅延が発生した場合、トランザクション ログがいっぱいになる場合があります。トランザクション ログがいっぱいになった場合の処理方法の詳細については、「満杯になったトランザクション ログのトラブルシューティング (エラー 9002)」を参照してください。

ログ トランザクションのアーキテクチャに関する情報については、後の「ログを切り捨てるしくみ」を参照してください。

完全復旧モデルと一括ログ復旧モデルでのログの切り捨て

完全復旧モデルまたは一括ログ復旧モデルでは、ログ レコードがログ バックアップでキャプチャされるまでログの非アクティブな部分を切り捨てることができません。これは、ログ チェーンを保持するために必要です。ログ チェーンとは、連続したログ シーケンス番号 (LSN) が指定された一連のログ レコードです。以下の条件を満たしていれば、ログはトランザクション ログのバックアップ時に切り捨てられます。

• ログを最後にバックアップしてからチェックポイントが発生したこと。完全復旧モデルまたは一括ログ復旧モデルでログの切り捨てを行うためにチェックポイントは必要不可欠ですが、十分ではありません。チェックポイントの後、少なくとも次のトランザクション ログのバックアップまでログはそのまま保たれます。
  詳細については、「チェックポイントとログのアクティブな部分」を参照してください。
• ログ トランザクションを妨げる要因が他にないこと。
  一般的には、定期的なバックアップにより、ログ領域は将来の使用のために定期的に解放されます。ただし、実行時間の長いトランザクションなど、さまざまな要因で、ログの切り捨てが一時的に妨げられることがあります。詳細については、「ログの切り捨てが遅れる要因」を参照してください。
• BACKUP LOG ステートメントで WITH NO_TRUNCATE、WITH NO_LOG、または WITH COPY_ONLY を指定していないこと。

  重要 :
  BACKUP LOG ステートメントの NO_LOG オプションと TRUNCATE_ONLY オプションでは、バックアップ コピーを作成せずにログの非アクティブな部分が削除されるため、ログ チェーンが破壊されます。次の完全バックアップまたは差分バックアップまで、データベースをメディア障害から防ぐことはできません。この機能は、Microsoft SQL Server の次のバージョンで削除されます。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションはできるだけ早く修正してください。

トランザクション ログをバックアップするには

• トランザクション ログをバックアップする方法 (SQL Server Management Studio)
• トランザクション ログ バックアップを作成する方法 (Transact-SQL)

ログを切り捨てるしくみ

メモ :
ログの切り捨てを行っても、物理ログ ファイルのサイズは縮小されません。ログ ファイルの物理サイズを縮小するには、ファイルを圧縮する必要があります。物理ログ ファイルのサイズの圧縮の詳細については、「トランザクション ログの圧縮」を参照してください。

トランザクション ログは、循環して使用されるファイルです。このデータベースの作成時、論理ログ ファイルは物理ログ ファイルの先頭から始まります。新しいログ レコードは論理ログの末尾に追加され、物理ログの末尾に向かって拡張されます。データベースのトランザクション ログは、1 つ以上の物理ファイルにマップされます。SQL Server データベース エンジンにより、各物理ログ ファイルは内部的に多くの仮想ログ ファイルに分割されています。切り捨て処理では、論理ログの先頭から非アクティブな仮想ログ ファイルを削除することによって、論理ログの領域を解放します。トランザクション ログ アーキテクチャの詳細については、「トランザクション ログの論理アーキテクチャ」および「トランザクション ログの物理アーキテクチャ」を参照してください。

仮想ログ ファイルは再利用できる領域の単位です。非アクティブなログ レコードだけを含む仮想ログ ファイルのみを切り捨てることができます。トランザクション ログのアクティブな部分は、アクティブ ログといい、切り捨てることができません。これは、アクティブ ログがデータベースの復旧に必要だからです。アクティブ ログは、最新のチェックポイントで定義されます。このログは、そのチェックポイントの直前まで切り捨てることができます。

メモ :
仮想ログ ファイルの機能については、「トランザクション ログの物理アーキテクチャ」を参照してください。

チェックポイントが実行されると、トランザクション ログの非アクティブな部分は再利用できるようにマークが付けられます。その後、ログの切り捨てにより、非アクティブな部分を解放できます。切り捨てにより、非アクティブな仮想ログ ファイルは解放され、再利用できるようになります。最終的に、解放された仮想ログに新しいレコードが書き込まれると、その仮想ログ ファイルは再びアクティブになります。

チェックポイントで記録される情報は、データベース全体を正常にロールバックするために必要な最初のログ レコードのログ シーケンス番号 (LSN) です。この LSN は、最小復旧 LSN (MinLSN) といいます。ログのアクティブな部分の先頭は、MinLSN を含む仮想ログです。トランザクション ログが切り捨てられると、この仮想ログ ファイルより前にあるログ レコードのみが再利用のために解放されます。

次の図は、切り捨てを行う前と後のトランザクション ログを示しています。最初の図は、切り捨てが行われていないトランザクション ログを示しています。現在、4 つの仮想ログ ファイルが論理ログで使用されています。この論理ログは最初の仮想ログ ファイルの先頭から始まり、仮想ログ 4 で終了します。MinLSN レコードは仮想ログ 3 にあります。仮想ログ 1 および仮想ログ 2 には、非アクティブなログ レコードのみが含まれています。これらのレコードは切り捨てることができます。仮想ログ 5 はまだ使用されていないので、現在の論理ログには含まれていません。

2 番目の図は、切り捨て後のログの状態を示しています。仮想ログ 1 および仮想ログ 2 は再利用のために解放されています。この時点で、論理ログは仮想ログ 3 の先頭から始まっています。仮想ログ 5 はまだ使用されていないので、現在の論理ログには含まれていません。

参照

概念

チェックポイントとログのアクティブな部分
データベース オプションの設定
トランザクション ログのバックアップ
データベースの復旧モデルの選択
復旧モデルの概要

その他の技術情報

BACKUP (Transact-SQL)
Truncate Method

ヘルプおよび情報

SQL Server 2005 の参考資料の入手

変更履歴

リリース	履歴
2007 年 9 月 15 日	変更内容 : 導入部分を修正して、すべての仮想ログ ファイルにアクティブなログが含まれていない限りログの切り捨ては自動的に行われることを明記しました。 導入部分で扱っていたアーキテクチャに関する情報を「ログを切り捨てるしくみ」のセクションに移動しました。 トランザクション ログのバックアップ方法に関するトピックへのリンクを追加しました。
2006 年 4 月 14 日	変更内容 : ログの切り捨てに対する復旧モデルの影響の説明を拡充しました。 図の説明を明確にしました。