トランザクション ログの物理アーキテクチャ
トランザクション ログは、データベースのデータ整合性を保証するため、およびデータ復旧のために使用します。このセクションのトピックでは、トランザクション ログの物理アーキテクチャについて説明します。物理アーキテクチャを理解することで、トランザクション ログを効率的に管理できるようになります。
データベースのトランザクション ログは、1 つ以上の物理ファイルにマップされます。概念的には、ログ ファイルは一続きのログ レコードです。物理的には、一連のログ レコードは、トランザクション ログを実装する一連の物理ファイルに効率的に格納されます。
SQL Server データベース エンジンにより、各物理ログ ファイルは内部的に多くの仮想ログ ファイルに分割されています。仮想ログ ファイルのサイズは固定されておらず、1 つの物理ログ ファイルに対する仮想ログ ファイルの数も決まっていません。仮想ログ ファイルのサイズは、ログ ファイルの作成時や拡張時にデータベース エンジンにより動的に選択されます。データベース エンジンでは、管理する仮想ファイルの数を少なく保とうとします。ログ ファイルを拡張した後の仮想ファイルのサイズは、既存のログのサイズと増加した新しいファイルのサイズの合計になります。管理者が仮想ログ ファイルのサイズや数を構成または設定することはできません。
仮想ログ ファイルがシステムのパフォーマンスに影響を与えるのは、小さな size 値と growth_increment 値でログ ファイルを定義した場合のみです。小さな増加が繰り返されることにより、これらのログ ファイルが大きいサイズに拡張された場合、多くの仮想ログ ファイルが生成されます。このような状況では、データベースの起動、ログのバックアップ操作、およびログの復元操作の速度が低下する場合があります。ログ ファイルの size には最終的に必要なサイズに近い値を割り当て、growth_increment には比較的大きい値を割り当てることをお勧めします。
トランザクション ログは、循環して使用されるファイルです。たとえば、4 つの仮想ログ ファイルに分割された 1 つの物理ログ ファイルが格納されたデータベースがあるとします。このデータベースの作成時、論理ログ ファイルは物理ログ ファイルの先頭から始まります。新しいログ レコードは論理ログの末尾に追加され、物理ログの末尾に向かって拡張されます。ログの切り捨てにより、最小復旧ログ シーケンス番号 (MinLSN) より前にあるすべての仮想ログ レコードが解放されます。MinLSN は、データベース全体を正常にロールバックするために必要な最も古いログ レコードのログ シーケンス番号です。例として挙げたデータベースのトランザクション ログは、次の図のようになります。
.gif "4 つの仮想ログ ファイルに分割されたログ ファイル")
論理ログの末尾が物理ログ ファイルの末尾に達すると、新しいログ レコードはまた物理ログ ファイルの先頭から記録されていきます。
.gif "ログ ファイルの先頭に循環されるログ レコード")
このサイクルは、論理ログの末尾が論理ログの先頭に達しない限り、無限に繰り返されます。古いログ レコードが頻繁に切り捨てられ、次のチェックポイントで作成されるすべての新規ログ レコードを格納するのに必要な領域が常に確保されている場合、論理ログがいっぱいになることはありません。ただし、論理ログの末尾が論理ログの先頭に達した場合には、次のいずれかの処理が発生します。
ログで FILEGROWTH の設定が有効になっていて、ディスクの領域が使用できる場合、ファイルは growth_increment で指定した量だけ拡張され、新規ログ レコードがその拡張部分に追加されます。FILEGROWTH の設定の詳細については、「ALTER DATABASE (Transact-SQL)」を参照してください。
ログで FILEGROWTH の設定が有効になっていない場合、またはログ ファイルを保持しているディスクの空き領域が growth_increment で指定した量よりも少ない場合は、エラー 9002 が生成されます。
ログに複数の物理ログ ファイルが含まれている場合、論理ログは、すべての物理ログ ファイルの領域を使用し終えてから、最初の物理ログ ファイルの先頭に戻ります。