すべての SQL Server データベースには、すべてのトランザクションと、各トランザクションによって行われたデータベースの変更を記録するトランザクション ログがあります。 トランザクションログがいっぱいにならないように、定期的に切り捨てる必要があります。 ただし、ログの切り捨てが遅れる要因もあるため、ログ サイズの監視が重要です。 一部の操作は、トランザクション ログ サイズへの影響を軽減するために、最小限のログ記録が可能です。
トランザクション ログはデータベースの重要なコンポーネントであり、システム障害が発生した場合は、データベースを一貫した状態に戻すためにトランザクション ログが必要になることがあります。 トランザクション ログは、これを行うことの影響を完全に理解していない限り、削除または移動しないでください。
注
データベースの復旧中にトランザクション ログの適用を開始する既知の良いポイントは、チェックポイントによって作成されます。 詳細については、「Database Checkpoints (SQL Server)」 (データベース チェックポイント (SQL Server)) をご覧ください。
このトピックでは：
利点: トランザクション ログでサポートされる操作
トランザクション ログでは、次の操作がサポートされています。
個々のトランザクションの復旧。
SQL Server の起動時に不完全なすべてのトランザクションを復旧します。
復元されたデータベース、ファイル、ファイル グループ、またはページを障害発生時点までロールフォワードする。
トランザクション レプリケーションのサポート。
高可用性とディザスター リカバリー ソリューションのサポート: Always On 可用性グループ、データベース ミラーリング、ログ配布。
トランザクション ログの切り捨て
ログの切り捨てにより、トランザクション ログで再利用するためにログ ファイル内の領域が解放されます。 ログがいっぱいになるのを防ぐためには、ログの切り捨てが不可欠です。 ログの切り捨てにより、SQL Server データベースの論理トランザクション ログから非アクティブな仮想ログ ファイルが削除され、物理トランザクション ログで再利用するために論理ログ内の領域が解放されます。 トランザクション ログが切り捨てられなければ、最終的には物理ログ ファイルに割り当てられているすべてのディスク領域がいっぱいになります。
この問題を回避するには、何らかの理由でログの切り捨てが遅れている場合を除き、次のイベントの後に切り捨てが自動的に発生します。
単純復旧モデルでは、チェックポイントの後。
完全復旧モデルまたは一括ログ復旧モデルでは、前のバックアップ以降にチェックポイントが発生した場合、(コピーのみのログ バックアップでない限り) ログ バックアップの後に切り捨てが行われます。
詳細については、このトピックで後述 する「ログの切り捨てを遅らせる要因」を参照してください。
注
ログの切り捨ては、物理ログ ファイルのサイズを小さくしません。 物理ログ ファイルの物理サイズを小さくするには、ログ ファイルを圧縮する必要があります。 物理ログ ファイルのサイズの縮小については、「トランザクション ログ ファイル のサイズの管理」を参照してください。
ログの切り捨てを遅らせる要因
ログ レコードが長時間アクティブなままの場合、トランザクション ログの切り捨てが遅れ、トランザクション ログがいっぱいになる可能性があります。
重要
完全なトランザクション ログに応答する方法については、「完全なトランザクション ログのトラブルシューティング (SQL Server エラー 9002)」を参照してください。
ログの切り捨ては、さまざまな要因によって遅れる可能性があります。 sys.databases カタログ ビューのlog_reuse_wait列とlog_reuse_wait_desc列に対してクエリを実行することで、ログの切り捨てが妨げているもの (ある場合) を検出できます。 次の表では、これらの列の値について説明します。
| log_reuse_wait 値 | log_reuse_wait_desc の値 | 説明 |
|---|---|---|
| 0 | 何もない | 現在、1 つ以上の再利用可能な仮想ログ ファイルがあります。 |
| 1 | チェックポイント | 最後のログの切り捨て以降、チェックポイントは発生していません。または、ログの先頭がまだ仮想ログ ファイルを超えて移動していません。 (すべての復旧モデル) これは、ログの切り捨てが遅れる一般的な原因です。 詳細については、「Database Checkpoints (SQL Server)」 (データベース チェックポイント (SQL Server)) をご覧ください。 |
| 2 | ログ_バックアップ | トランザクション ログを切り捨てる前に、ログ バックアップが必要です。 (完全復旧モデルまたは一括ログ復旧モデルのみ) 次のログ バックアップが完了すると、一部のログ領域が再利用可能になる可能性があります。 |
| 3 | アクティブバックアップまたはリストア | データ バックアップまたは復元が進行中です (すべての復旧モデル)。 データバックアップがログの切り詰めを妨げている場合、バックアップ操作をキャンセルすることで目下の問題が解決するかもしれません。 |
| 4 | アクティブトランザクション | トランザクションがアクティブです (すべての復旧モデル)。 ログ バックアップの開始時に実行時間の長いトランザクションが存在する可能性があります。 この場合、領域を解放するには、別のログ バックアップが必要になる場合があります。 実行時間が長いトランザクションは、単純復旧モデルを含むすべての復旧モデルにおいてログの切り捨てを妨げます。単純復旧モデルでは、通常は各自動チェックポイントでトランザクションログが切り捨てられます。 トランザクションは遅延されます。 遅延トランザクションは、実質的にアクティブなトランザクションであり、リソースが使用できないためにロールバックがブロックされます。 遅延トランザクションの原因と、遅延状態から移動する方法については、「 遅延トランザクション (SQL Server)」を参照してください。 実行時間の長いトランザクションでは、tempdb のトランザクション ログがいっぱいになる場合もあります。 Tempdb は、並べ替えの作業テーブル、ハッシュ用の作業ファイル、カーソル作業テーブル、行のバージョン管理などの内部オブジェクトのユーザー トランザクションによって暗黙的に使用されます。 ユーザー トランザクションにデータの読み取り (SELECT クエリ) のみが含まれている場合でも、内部オブジェクトがユーザー トランザクションの下で作成および使用される可能性があります。 その後、tempdb トランザクション ログを入力できます。 |
| 5 | データベース・ミラーリング | データベース ミラーリングが一時停止されているか、高パフォーマンス モードの場合、ミラー データベースはプリンシパル データベースの背後にあります。 (完全復旧モデルのみ) 詳細については、「 データベース ミラーリング (SQL Server)」を参照してください。 |
| 6 | レプリケーション | トランザクション レプリケーション中も、パブリケーションに関連するトランザクションはディストリビューション データベースに配信されません。 (完全復旧モデルのみ) トランザクション レプリケーションの詳細については、「 SQL Server レプリケーション」を参照してください。 |
| 7 | データベーススナップショットの作成 | データベース スナップショットが作成されています。 (すべての復旧モデル) これは遅延ログ切り捨ての一般的な原因であり、通常は短時間です。 |
| 8 | ログスキャン | ログ スキャンが発生しています。 (すべての復旧モデル) これは遅延ログ切り捨ての一般的な原因であり、通常は短時間です。 |
| 9 | 可用性レプリカ (AVAILABILITY_REPLICA) | 可用性グループのセカンダリ レプリカが、このデータベースのトランザクション ログ レコードを対応するセカンダリ データベースに適用しています。 (完全復旧モデル) 詳細については、「 AlwaysOn 可用性グループ (SQL Server) の概要」を参照してください。 |
| 10 | - | 内部使用のみ |
| 11 | - | 内部使用のみ |
| 12 | - | 内部使用のみ |
| 13 | 最古のページ | 間接チェックポイントを使用するようにデータベースが構成されている場合、データベースの最も古いページがチェックポイント LSN よりも古い可能性があります。 この場合、最も古いページでログの切り捨てが遅れる可能性があります。 (すべての復旧モデル) 間接チェックポイントの詳細については、「 データベース チェックポイント (SQL Server)」を参照してください。 |
| 14 | その他一時的 | この値は現在使用されていません。 |
| 16 | XTP_CHECKPOINT | データベースにメモリ最適化ファイル グループがある場合、トランザクション ログは、自動 In-Memory OLTP チェックポイントがトリガーされるまで切り捨てられない可能性があります (ログの増加は 512 MB ごとに発生します)。 注: トランザクション・ログを 512 MB サイズより前に切り捨てるには、問題のデータベースに対してチェックポイント・コマンドを手動で起動します。 |
最小限のログ記録が可能な操作
最小ログ記録 では、特定の時点の復旧をサポートせずに、トランザクションの復旧に必要な情報のみをログに記録します。 このトピックでは、一括ログ復旧モデル (およびバックアップが実行されている場合を除く単純復旧モデルの下) で最小ログ記録される操作を特定します。
注
最小ログ記録は、メモリ最適化テーブルではサポートされていません。
注
完全復旧モデルでは、すべての一括操作が完全にログに記録されます。 ただし、一括操作の場合は、データベースを一括ログ復旧モデルに一時的に切り替えることで、一連の一括操作のログ記録を最小限に抑えることができます。 最小ログ記録は完全なログ記録よりも効率的であり、大規模な一括操作が一括トランザクション中に使用可能なトランザクション ログ領域を埋める可能性を減らします。 ただし、最小限のログ記録が有効なときにデータベースが破損または失われた場合、障害が発生した時点までデータベースを復旧することはできません。
完全復旧モデルで完全にログに記録される次の操作は、単純復旧モデルと一括ログ復旧モデルで最小ログ記録されます。
一括インポート操作 (bcp、 BULK INSERT、 INSERT...SELECT)。 テーブルへの一括インポートが最小ログ記録されるタイミングの詳細については、「 一括インポートでの最小ログ記録の前提条件」を参照してください。
注
トランザクション レプリケーションが有効になっている場合、 BULK INSERT 操作は、一括ログ復旧モデルでも完全にログに記録されます。
SELECT INTO 操作。
注
トランザクション レプリケーションが有効になっている場合、SELECT INTO 操作は、一括ログ復旧モデルの下でも完全にログに記録されます。
を使用して、大きな値のデータ型に部分的に更新します。新しいデータを挿入または追加するときに、 UPDATE ステートメントの WRITE 句。 既存の値が更新されるときに、最小ログ記録は使用されないことに注意してください。 大きな値のデータ型の詳細については、「データ 型 (Transact-SQL)」を参照してください。
新しいデータを、、および
textデータ型の列に挿入または追加する場合のntextおよびimageステートメント。 既存の値が更新されるときに、最小ログ記録は使用されないことに注意してください。注
WRITETEXT ステートメントと UPDATETEXT ステートメントは非推奨であるため、新しいアプリケーションでは使用しないでください。
データベースが単純復旧モデルまたは一括ログ復旧モデルに設定されている場合、操作がオフラインまたはオンラインのどちらで実行されるかに関係なく、一部のインデックス DDL 操作は最小限に記録されます。 最小ログ記録インデックス操作は次のとおりです。
CREATE INDEX 操作 (インデックス付きビューを含む)。
ALTER INDEX REBUILD 操作または DBCC DBREINDEX 操作。
注
DBCC DBREINDEX ステートメントは非推奨であるため、新しいアプリケーションでは使用しないでください。
DROP INDEX 新しいヒープ再構築 (該当する場合)。
注
DROP INDEX操作中のインデックス ページの割り当て解除は、常に完全にログに記録されます。
関連タスク
Managing the transaction log
トランザクション ログのバックアップ (完全復旧モデル)
トランザクション ログの復元 (完全復旧モデル)
こちらもご覧ください
トランザクションの持続性の制御
一括インポートでの最小ログ記録の前提条件
SQL Server データベースのバックアップと復元
データベース チェックポイント (SQL Server)
データベースのプロパティを表示または変更する
復旧モデル (SQL Server)