トランザクション ログ (SQL Server)
すべての SQL Server データベースにはトランザクション ログがあり、データベース内のすべてのトランザクションとそれらのトランザクションによって加えられた変更が記録されます。 トランザクション ログは、いっぱいにならないように、定期的に切り捨てる必要があります。 ただし、いくつかの要因によってログの切り捨てが遅れる可能性があるため、ログのサイズを監視することは重要です。 一部の操作は、トランザクション ログのサイズへの影響を軽減するためにログへの記録を最小限に抑えることができます。
トランザクション ログはデータベースの重要なコンポーネントの 1 つであり、システム障害が発生すると、データベースを一貫性のある状態にするために求められる場合があります。 結果がどのようになるかを完全に把握できる場合を除き、トランザクション ログを削除または移動しないでください。
Note
データベース復旧時にトランザクション ログの適用を開始する既知の最適なポイントがチェックポイントによって作成されます。 詳細については、「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 | NOTHING | 現在 1 つ以上の再利用可能な仮想ログ ファイルがある。 |
| 1 | CHECKPOINT | 最後にログの切り捨てを行ってからチェックポイントが発生していないか、ログの先頭が仮想ログ ファイルを超えて移動していない (すべての復旧モデル)。 これは、ログの切り捨てが遅れる一般的な原因です。 詳細については、「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 | レプリケーション | トランザクション レプリケーション中、パブリケーションに関連するトランザクションがディストリビューション データベースにまだ配信されていない (完全復旧モデルのみ)。 トランザクション レプリケーションの詳細については、「 SQL Server Replication」を参照してください。 |
| 7 | DATABASE_SNAPSHOT_CREATION | データベース スナップショットが作成されている (すべての復旧モデル)。 これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。 |
| 8 | LOG_SCAN | ログ スキャンが行われている (すべての復旧モデル)。 これは、通常、短い時間ログの切り捨てが遅れる一般的な原因となります。 |
| 9 | AVAILABILITY_REPLICA | 可用性グループのセカンダリ レプリカが、このデータベースのトランザクション ログ レコードを対応するセカンダリ データベースに適用中である (完全復旧モデル)。 詳細については、「AlwaysOn 可用性グループの概要 (SQL Server)」を参照してください。 |
| 10 | - | 内部使用のみ |
| 11 | - | 内部使用のみ |
| 12 | - | 内部使用のみ |
| 13 | OLDEST_PAGE | データベースが間接的なチェックポイントを使用するように構成されている場合、データベース上の最も古いページはチェックポイントの LSN よりも古くなることがある。 この場合、最も古いページのログの切り捨てが遅れる可能性があります (すべての復旧モデル)。 間接チェックポイントの詳細については、「データベース チェックポイント (SQL Server)」を参照してください。 |
| 14 | OTHER_TRANSIENT | この値は現在使用されていません。 |
| 16 | XTP_CHECKPOINT | データベースにメモリ最適化ファイル グループがある場合、OLTP チェックポイントの自動In-Memoryがトリガーされるまでトランザクション ログが切り詰められません (ログの増加が 512 MB ごとに発生します)。 注: トランザクション ログを 512 MB サイズより前に切り捨てるには、問題のデータベースに対して Checkpoint コマンドを手動で実行します。 |
最小ログ記録が可能な操作
最小ログ記録 では、トランザクションの復旧に必要な情報だけが記録されます。特定の時点への復旧はサポートしません。 このトピックでは、一括ログ復旧モデルで (バックアップが実行されていない場合は単純復旧モデルで) 最小ログが記録される操作について説明します。
注意
最小ログ記録は、メモリ最適化テーブルではサポートされていません。
注意
完全復旧モデルでは、すべての一括操作が完全にログに記録されます。 ただし、一括操作のためにデータベースを一時的に一括ログ復旧モデルに切り替えることで、一連の一括操作用のログ記録を最小限に抑えることができます。 最小ログ記録は、完全ログ記録より効率的であり、一括トランザクションの実行中に、使用可能なトランザクション ログ領域が大規模な一括操作でいっぱいになる可能性を低減します。 ただし、最小ログ記録が有効なときにデータベースが破損または消失した場合は、データベースを障害発生時点まで復旧できません。
次に示す操作は、完全復旧モデルで完全にログ記録されますが、単純復旧モデルと一括ログ復旧モデルでは最小限にしかログ記録されません。
一括インポート操作 (bcp、BULK INSERT、INSERT...SELECT)。 テーブルへの一括インポートの最小ログ記録の詳細については、「 Prerequisites for Minimal Logging in Bulk Import」を参照してください。
注意
トランザクション レプリケーションが有効な場合、BULK INSERT 操作は、一括ログ復旧モデルでも完全にログ記録されます。
SELECT INTO 操作。
Note
トランザクション レプリケーションが有効な場合、SELECT INTO 操作は、一括ログ復旧モデルでも完全にログ記録されます。
新規データの挿入時または追加時の、 UPDATE ステートメントの .WRITE 句を使用した、大きな値のデータ型の部分更新。 既存の値を更新する場合は、最小ログ記録は使用されません。 大きな値のデータ型の詳細については、「データ型 (Transact-SQL)」を参照してください。
、、および データ型の列に新しいデータを挿入または追加する場合の
textntextWRITETEXT ステートメントとimageUPDATETEXT ステートメント。 既存の値を更新する場合は、最小ログ記録は使用されません。Note
WRITETEXT ステートメントおよび UPDATETEXT ステートメントは非推奨とされます。新しいアプリケーションでは、これらを使用しないようにしてください。
データベースが単純復旧モデルまたは一括ログ復旧モデルに設定されている場合、一部のインデックス DDL 操作は、オフラインで実行されても、オンラインで実行されても、最小ログ記録の対象になります。 最小ログ記録が行われるインデックス操作は、次のとおりです。
CREATE INDEX 操作 (インデックス付きビューを含む)。
ALTER INDEX REBUILD 操作または DBCC DBREINDEX 操作。
Note
DBCC DBREINDEX ステートメントは非推奨とされます。新しいアプリケーションでは、これを使用しないようにしてください。
DROP INDEX による新しいヒープの再構築 (適用可能な場合)。
Note
DROP INDEX 操作中のインデックス ページの割り当て解除は、常に完全にログ記録されます。
Related Tasks
Managing the transaction log
トランザクション ログのバックアップ (完全復旧モデル)
トランザクション ログの復元 (完全復旧モデル)
参照
トランザクションの持続性の制御
一括インポートで最小ログ記録を行うための前提条件
SQL Server データベースのバックアップと復元
データベース チェックポイント (SQL Server)
データベースのプロパティの表示または変更
復旧モデル (SQL Server)