次の方法で共有

トランザクション ログ

  • [アーティクル]

適用対象: SQL Server

すべての SQL Server データベースにはトランザクション ログがあり、データベース内のすべてのトランザクションとそれらのトランザクションによって加えられた変更が記録されます。

トランザクション ログは、データベースの重要なコンポーネントです。 システム障害がある場合、データベースを一貫性のある状態に戻すには、そのログが必要になります。

警告

もたらされる影響を完全に理解していない限り、このログを削除または移動しないでください。

トランザクション ログのアーキテクチャと内部構造の詳細については、「SQL Server トランザクション ログのアーキテクチャと管理ガイド」を参照してください。

ヒント

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

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

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

  • 個別のトランザクションの復旧
  • SQL Server の起動時に未完了だったすべてのトランザクションの復旧。
  • 復元したデータベース、ファイル、ファイル グループ、またはページの障害時点までのロールフォワード
  • トランザクション レプリケーションのサポート
  • 高可用性とディザスター リカバリー ソリューションのサポート: Always On 可用性グループ、データベース ミラーリング、ログ配布。

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

アプリケーションで ROLLBACK ステートメントが実行されるか、データベース エンジンでクライアントとの通信の喪失などのエラーが検出された場合、未完了のトランザクションによって加えられた変更をロールバックするために、ログ レコードが使用されます。

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

サーバーに障害が発生すると、データベースは、バッファ キャッシュからデータ ファイルに一部の変更が書き込まれない状態のままになり、データ ファイル内に不完全なトランザクションによる一部の変更が残る可能性があります。 SQL Server のインスタンスは、起動時に各データベースの復旧を行います。 ログに記録されていて、データ ファイルに書き込まれなかった可能性があるすべての変更は、ロールフォワードされます。 その後、トランザクション ログに記録されている未完了のトランザクションは、データベースの整合性を確保するために、すべてロールバックされます。 詳細については、「復元と復旧の概要 (SQL Server)」を参照してください。

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

ハードウェアの故障やディスク障害などによりデータベース ファイルが影響を受けた場合、そのデータベースを障害が発生した時点まで復元できます。 まずデータベースの最新の完全バックアップまたは差分バックアップを復元し、次にその後の一連のトランザクション ログ バックアップを障害が発生した時点まで復元します。

各ログ バックアップを復元するときに、ログに記録されている変更がデータベース エンジンにより再適用されて、すべてのトランザクションがロールフォワードされます。 最後のログ バックアップまで復元されると、データベース エンジンはログ情報を使用して、障害の時点では完了していなかったすべてのトランザクションをロールバックします。 詳細については、「復元と復旧の概要 (SQL Server)」を参照してください。

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

ログ リーダー エージェントは、トランザクション レプリケーション用に構成された各データベースのトランザクション ログを監視し、レプリケーションのマークが付けられたトランザクションをトランザクション ログからディストリビューション データベースにコピーします。 詳しくは、「 トランザクション レプリケーションの動作方法」をご覧ください。

高可用性とディザスター リカバリー ソリューションのサポート

スタンバイ サーバー ソリューション、Always On 可用性グループ、データベース ミラーリング、ログ配布は、トランザクション ログに大きく依存しています。

Always On 可用性グループのシナリオでは、データベース (プライマリ レプリカ) に対するすべての更新は、別に存在するデータベースのすべてのコピー (セカンダリ レプリカ) で直ちに再現されます。 プライマリ レプリカにより各ログ レコードが直ちにセカンダリ レプリカに送信されます。そこでは、受信したログ レコードが可用性データベースに適用され、継続的にログが展開されます。 詳細については、「Always On フェールオーバー クラスター インスタンス (SQL Server)」を参照してください。

ログ配布シナリオでは、プライマリ データベースのトランザクション ログ バックアップがプライマリ サーバーから 1 つ以上の配布先に送信されます。 各セカンダリ サーバーでは、ログ バックアップがそのローカルのセカンダリ データベースに復元されます。 詳細については、「ログ配布について(SQL Server)」を参照してください。

データベース ミラーリング シナリオでは、プリンシパル データベースに対するすべての更新が、そのデータベースの完全なコピーである、独立したミラー データベースに直ちに再現されます。 各ログ レコードは、プリンシパル サーバー インスタンスからミラー サーバー インスタンスに直ちに送信されます。ここでは、受信したログ レコードがミラー データベースに適用され、継続的にロールフォワードされます。 詳細については、「データベース ミラーリング (SQL Server)」を参照してください。

トランザクション ログの特性

SQL Server データベース エンジン トランザクション ログの特性:

  • トランザクション ログは、データベース内に別個のファイルまたはファイル セットとして実装されます。 ログ キャッシュはデータ ページ用のバッファー キャッシュとは別に管理され、単純かつ高速の、堅牢なコードとして SQL Server データベース エンジン内に実装されています。 詳細については、「トランザクション ログの物理アーキテクチャ」を参照してください。

  • ログのレコードとページの形式は、データ ページの形式に従うように制約はされません。

  • トランザクション ログは、複数のファイルとして実装できます。 ログの FILEGROWTH 値を設定することで、これらのファイルが自動的に拡張されるように定義できます。 これにより、トランザクション ログが領域不足になる可能性が減り、同時に管理のオーバーヘッドも減少します。 詳細については、「ALTER DATABASE (Transact-SQL) の File および Filegroup オプション」を参照してください。

  • ログ ファイル内の領域を再利用するメカニズムは高速で、トランザクションのスループットに及ぼす影響も最小限で済みます。

トランザクション ログのアーキテクチャと内部構造の詳細については、「SQL Server トランザクション ログのアーキテクチャと管理ガイド」を参照してください。

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

ログの切り捨てによりログ ファイルの領域が解放され、トランザクション ログで再利用できるようになります。 トランザクション ログの定期的な切り捨ては、ログがいっぱいにならないようにするために不可欠です。 いくつかの要因によってログの切り捨てが遅れる可能性があるため、ログのサイズを監視することは重要です。 一部の操作は、トランザクション ログのサイズへの影響を軽減するためにログへの記録を最小限に抑えることができます。

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

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

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

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

  • 完全復旧モデルを使用してデータベースを初めて作成すると、完全データベース バックアップを作成するまで、トランザクション ログは必要に応じて再利用されます (単純復旧モデルを使用するデータベースと同様)。

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

ログの切り捨てを行っても、物理ログ ファイルのサイズは縮小されません。 物理ログ ファイルの物理サイズを削減するには、ログ ファイルを圧縮する必要があります。 物理ログ ファイルのサイズの圧縮の詳細については、「 トランザクション ログ ファイルのサイズの管理」を参照してください。 ただし、ログの切り捨てが遅れる原因となる要因には留意してください。 ログの圧縮後、ストレージ領域が再び必要になると、トランザクション ログが再び増え、その分のパフォーマンスのオーバーヘッドが発生します。

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

この記事で前述したように、ログ レコードが長い間アクティブなままになると、トランザクション ログの切り捨てが遅れて、トランザクション ログがいっぱいになります。

重要

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

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

log_reuse_wait の値 log_reuse_wait_desc の値 説明
0 NOTHING 現在 1 つ以上の再利用可能な仮想ログ ファイル (VLF) がある。
1 CHECKPOINT 最後のログ切り捨て以降にチェックポイントが発生していないか、ログの先頭が仮想ログ ファイル (VLF)(すべての復旧モデル) を超えて移動していません 。

これは、ログの切り捨てが遅れる一般的な原因です。 詳細については、「Database Checkpoints (SQL Server)」 (データベース チェックポイント (SQL Server)) をご覧ください。
2 LOG_BACKUP トランザクション ログを切り捨てる前にログ バックアップが必要である (完全復旧モデルまたは一括ログ復旧モデルのみ)。

次のログ バックアップが完了した時点で、ログ領域の一部が再利用可能になります。
3 ACTIVE_BACKUP_OR_RESTORE データ バックアップまたは復元が実行中である (すべての復旧モデル)。

データ バックアップによってログの切り捨てが妨げられる場合、バックアップ操作を取り消すと、当面の問題には対処できます。
4 ACTIVE_TRANSACTION トランザクションがアクティブである (すべての復旧モデル):

実行時間の長いトランザクションがログ バックアップの先頭に存在する可能性がある。 この場合、領域を解放するには再度ログ バックアップが必要になります。 単純復旧モデルを含むすべての復旧モデルでは、実行時間の長いトランザクションによってログの切り捨てが妨げられます。この場合、通常は自動チェックポイントのたびにトランザクション ログが切り捨てられます。

トランザクションが遅延している。 遅延トランザクション は、一部リソースが確保できないためにロールバックがブロックされている、実質的にはアクティブなトランザクションです。 遅延トランザクションの原因と、遅延状態を解決する方法については、「遅延トランザクション (SQL Server)」を参照してください。

長時間実行されるトランザクションによって、tempdb のトランザクション ログがいっぱいになる可能性もあります。 tempdb は、並べ替えの作業テーブル、ハッシュの作業ファイル、カーソル作業テーブル、行のバージョン管理といった、内部オブジェクトに対するユーザー トランザクションで暗黙的に使用されます。 ユーザー トランザクションにデータ読み取り (SELECTクエリ) だけが含まれる場合でも、ユーザー トランザクションで内部オブジェクトが作成され使用されることがあります。 その結果 tempdb のトランザクション ログがいっぱいになる可能性があります。
5 DATABASE_MIRRORING データベース ミラーリングが一時中断されるか、高パフォーマンス モードでは、ミラー データベースがプリンシパル データベースに大幅に遅れる (完全復旧モデルのみ)。

詳細については、「データベース ミラーリング (SQL Server)」を参照してください。
6 REPLICATION トランザクション レプリケーション中、パブリケーションに関連するトランザクションがディストリビューション データベースにまだ配信されていない (完全復旧モデルのみ)。

トランザクション レプリケーションの詳細については、「 SQL Server Replication」を参照してください。
7 DATABASE_SNAPSHOT_CREATION データベース スナップショットを作成しています (すべての復旧モデル)。

これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。
8 LOG_SCAN ログ スキャンが発生しています (すべての復旧モデル)。

これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。
9 AVAILABILITY_REPLICA 可用性グループのセカンダリ レプリカが、このデータベースのトランザクション ログ レコードを対応するセカンダリ データベースに適用中である (完全復旧モデルのみ)。

詳細については、Always On 常時可用性グループを参照してください。
10 - 内部のみで使用
11 - 内部のみで使用
12 - 内部のみで使用
13 OLDEST_PAGE データベースが間接的なチェックポイントを使用するように構成されている場合、データベース上の最も古いページはチェックポイントのログ シーケンス番号 (LSN) よりも古くなることがある。 この場合、最も古いページによってログの切り捨てが遅れる可能性があります (すべての復旧モデル)。

間接チェックポイントの詳細については、「データベース チェックポイント (SQL Server)」を参照してください。
14 OTHER_TRANSIENT この値は現在使用されていません。
16 XTP_CHECKPOINT インメモリ OLTP チェックポイントの実行が必要です。 メモリ最適化されたテーブルの場合、前回のチェックポイント以後、トランザクション ログ ファイルが 1.5 GB を超えると (ディスクベースのテーブルとメモリ最適化されたテーブルの両方を含む)、自動チェックポイントが取得されます。

詳細については、「メモリ最適化テーブルのチェックポイント操作」とインメモリ最適化テーブルのログ記録とチェックポイント プロセス (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/) に関する記事を参照してください

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

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

メモリ最適化テーブルでは最小ログ記録はサポートされていません。

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

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

  • 一括インポート操作 (bcp、BULK INSERT、INSERT)。 テーブルへの一括インポートの最小ログ記録の詳細については、「 Prerequisites for Minimal Logging in Bulk Import」を参照してください。

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

  • SELECT - INTO 句の操作。

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

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

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

    警告

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

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

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

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

      インデックス構築操作では最小限のログ記録が使用されますが、同時に実行されるバックアップがある場合は遅延する可能性があります。 このような遅延は、単純復旧モデルまたは一括ログ復旧モデルを使用するときに、最小限のログが記録されるバッファー プール ページの同期要件が原因で発生します。

      警告

      このDBCC DBREINDEXステートメントは非推奨です。新しいアプリケーションでは使用しないでください。

    • DROP INDEX による新しいヒープの再構築 (適用可能な場合)。 DROP INDEX 操作中のインデックス ページの割り当て解除は、常に完全にログ記録されます。

タスク [アーティクル]
トランザクション ログの管理 - トランザクション ログ ファイルのサイズの管理

- 満杯になったトランザクション ログのトラブルシューティング (SQL Server エラー 9002)
トランザクション ログのバックアップ (完全復旧モデル) - トランザクション ログをバックアップする

- データベースが破損したときのトランザクション ログのバックアップ (SQL Server)
トランザクション ログを復元する (完全復旧モデルのみ) - トランザクション ログ バックアップの復元 (SQL Server)

関連するコンテンツ