トランザクション ログ (SQL Server)

すべての SQL Server データベースにはトランザクション ログがあり、データベース内のすべてのトランザクションとそれらのトランザクションによって加えられた変更が記録されます。 トランザクション ログは、満杯にならないように、定期的に切り捨てる必要があります。 ただし、いくつかの要因によってログの切り捨てが遅れる可能性があるため、ログのサイズを監視することは重要です。 一部の操作は、トランザクション ログのサイズへの影響を軽減するためにログへの記録を最小限に抑えることができます。

トランザクション ログはデータベースの重要なコンポーネントの 1 つであり、システム障害が発生すると、データベースを一貫性のある状態にするために求められる場合があります。 結果がどのようになるかを完全に把握できる場合を除き、トランザクション ログを削除または移動しないでください。

注
データベース復旧時にトランザクション ログの適用を開始する既知の最適なポイントがチェックポイントによって作成されます。 詳細については、「データベース チェックポイント (SQL Server)」を参照してください。

このトピックの内容

• 利点: トランザクション ログによりサポートされる操作

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

• ログの切り捨てが遅れる原因となる要因

• 最小ログ記録が可能な操作

• 関連タスク

利点: トランザクション ログによりサポートされる操作

トランザクション ログでは、次の操作がサポートされます。

• 個別のトランザクションの復旧

• SQL Server の起動時に未完了だったすべてのトランザクションの復旧

• 復元したデータベース、ファイル、ファイル グループ、またはページの障害時点までのロールフォワード

• トランザクション レプリケーションのサポート

• 高可用性および災害復旧ソリューションのサポート: AlwaysOn 可用性グループ、データベース ミラーリング、およびログ配布

[先頭に戻る]

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

ログの切り捨てによりログ ファイルの領域が解放され、トランザクション ログで再利用できるようになります。 ログの切り捨ては、ログがいっぱいにならないようにするために不可欠です。 ログの切り捨てでは、SQL Server データベースの論理トランザクション ログから非アクティブな仮想ログ ファイルが削除されます。また、論理ログの領域が解放され、物理トランザクション ログで再利用できるようになります。 トランザクション ログが切り捨てられなければ、物理ログ ファイルに割り当てられているディスク上の領域がいっぱいになってしまいます。

この問題を回避するために、何かの理由でログの切り捨てが遅れている場合を除き、次のイベントの後に切り捨てが自動的に発生します。

• 単純復旧モデルでは、チェックポイント以降。

• 完全復旧モデルまたは一括ログ復旧モデルでは、前回のバックアップ後にチェックポイントが発生した場合、ログ バックアップ (コピーのみのログ バックアップの場合を除く) の後に切り捨てが発生します。

詳細については、このトピックの「ログの切り捨てが遅れる原因となる要因」を参照してください。

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

[先頭に戻る]

ログの切り捨てが遅れる原因となる要因

ログ レコードが長い間アクティブなままになると、トランザクション ログの切り捨てが遅れて、トランザクション ログがいっぱいになる可能性があります。

重要
トランザクション ログがいっぱいになった場合の対処方法については、「満杯になったトランザクション ログのトラブルシューティング (SQL Server エラー 9002)」を参照してください。

ログの切り捨ては、さまざまな要因で遅延が発生する場合があります。 ログの切り捨てを妨げている原因は、sys.databases カタログ ビューの log_reuse_wait 列と log_reuse_wait_desc 列に対するクエリを実行して見つけることができます。 次の表では、これらの列の値について説明します。

[先頭に戻る]

最小ログ記録が可能な操作

最小ログ記録では、トランザクションの復旧に必要な情報だけが記録されます。特定の時点への復旧はサポートしません。 このトピックでは、一括ログ復旧モデルで (バックアップが実行されていない場合は単純復旧モデルで) 最小ログが記録される操作について説明します。

注
完全復旧モデルでは、すべての一括操作が完全にログに記録されます。 ただし、一括操作のためにデータベースを一時的に一括ログ復旧モデルに切り替えることで、一連の一括操作用のログ記録を最小限に抑えることができます。 最小ログ記録は、完全ログ記録より効率的であり、一括トランザクションの実行中に、使用可能なトランザクション ログ領域が大規模な一括操作でいっぱいになる可能性を低減します。 ただし、最小ログ記録が有効なときにデータベースが破損または消失した場合は、データベースを障害発生時点まで復旧できません。

次に示す操作は、完全復旧モデルで完全にログ記録されますが、単純復旧モデルと一括ログ復旧モデルでは最小限にしかログ記録されません。

• 一括インポート操作 (bcp、BULK INSERT、および INSERT...SELECT)。 テーブルへの一括インポートの最小ログ記録の詳細については、「一括インポートで最小ログ記録を行うための前提条件」を参照してください。

  注
  トランザクション レプリケーションが有効な場合、BULK INSERT 操作は、一括ログ復旧モデルでも完全にログ記録されます。

• SELECT INTO 操作。

  注
  トランザクション レプリケーションが有効な場合、SELECT INTO 操作は、一括ログ復旧モデルでも完全にログ記録されます。

• 新規データの挿入時または追加時の、UPDATE ステートメントの .WRITE 句を使用した、大きな値のデータ型の部分更新。 既存の値を更新する場合は、最小ログ記録は使用されません。 大きな値のデータ型の詳細については、「データ型 (Transact-SQL)」を参照してください。

• text、ntext、image の各データ型列に新規データを挿入または追加するときの WRITETEXT ステートメントおよび UPDATETEXT ステートメント。 既存の値を更新する場合は、最小ログ記録は使用されません。

  注
  WRITETEXT ステートメントおよび UPDATETEXT ステートメントの使用は推奨されなくなりました。新しいアプリケーションでは、これらを使用しないようにしてください。

• データベースが単純復旧モデルまたは一括ログ復旧モデルに設定されている場合、一部のインデックス DDL 操作は、オフラインで実行されても、オンラインで実行されても、最小ログ記録の対象になります。 最小ログ記録が行われるインデックス操作は、次のとおりです。

  • CREATE INDEX 操作 (インデックス付きビューを含む)。

  • ALTER INDEX REBUILD 操作または DBCC DBREINDEX 操作。

    注
    DBCC DBREINDEX ステートメントの使用は推奨されなくなりました。新しいアプリケーションでは、これを使用しないようにしてください。

  • DROP INDEX による新しいヒープの再構築 (適用可能な場合)。

    注
    DROP INDEX 操作中のインデックス ページの割り当て解除は、常に完全にログ記録されます。

[先頭に戻る]

関連タスク

Managing the transaction log

• トランザクション ログ ファイルのサイズの管理

• 満杯になったトランザクション ログのトラブルシューティング (SQL Server エラー 9002)

トランザクション ログのバックアップ (完全復旧モデル)

• トランザクション ログのバックアップ (SQL Server)

トランザクション ログの復元 (完全復旧モデル)

• トランザクション ログ バックアップの復元 (SQL Server)

[先頭に戻る]

関連項目

概念

一括インポートで最小ログ記録を行うための前提条件

SQL Server データベースのバックアップと復元

データベース チェックポイント (SQL Server)

データベースのプロパティの表示または変更

復旧モデル (SQL Server)