トランザクション ログについて

  • [アーティクル]

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2007-08-30

ここでは、Microsoft Exchange Server 2007 におけるトランザクション ログの詳細について説明し、循環ログについても簡単に説明します。

Exchange Server トランザクション ログは、データベースが突然停止した場合に Exchange データベースを確実に整合状態に復元するように設計された、Extensible Storage Engine (ESE) の強力な回復機構です。またログ機構はオンライン バックアップの復元時にも使用されます。 

Exchange トランザクション ログ

Exchange データベース ファイルに変更が加えられる前に、Exchange はトランザクション ログ ファイルにその変更を書き込みます。変更が正常にログ出力されると、その変更はデータベース ファイルに書き込めるようになっています。通常、変更をトランザクション ログに安全に記録した直後、データベース ファイルに書き込まれる前に、これらの変更がエンド ユーザーに対して有効になります。

Exchange では、高いパフォーマンスで機能し、数十ギガバイト (GB) のデータベース ページのキャッシュを効率よく管理できる洗練された内部メモリ管理システムを採用しています。このため、データベース ファイルに物理的に変更を書き込む処理は通常の運用では優先順位の低い作業です。

データベースが突然停止しても、メモリ キャッシュが破損しただけではキャッシュされた変更は失われません。Exchange では、データベースの再起動時にログ ファイルをスキャンし、データベース ファイルにまだ書き込まれていない変更をすべて再構築し、適用します。このプロセスを "ログ ファイルの再生" と呼びます。データベースは、ログ ファイルに記録された処理のうち、データベースに適用済みであるか、データベースにこれから適用する必要があるか、またはそのデータベースに属していないかを Exchange が判断できるように構築されています。

すべてのログ情報を 1 つの大きなファイルに書き込むのではなく、Exchange では一連のログ ファイルを使用し、各ファイルのサイズはちょうど 1 メガバイト (MB)、つまり 1,024 キロバイト (KB) です。1 つのログ ファイルがいっぱいになると、Exchange はそのファイルを閉じ、連続した番号に名前を変更します。最初のファイルがいっぱいになると、Enn00000001.log という名前を付けます。nn は、ベース名またはログ プレフィックスという 2 桁の数字です。

各ストレージ グループのログ ファイルは、E00、E01、E02、E03 などの番号の付いたプレフィックスのファイル名で識別されます。ストレージ グループで現在開いているログ ファイルは、いっぱいになって閉じられるまで Enn.log という名前だけで、シーケンス番号は付けられていません。

チェックポイント ファイル (Enn.chk) によって、Exchange はログ情報をデータベース ファイルのどこまで書き込んだかを追跡します。各ログ ストリームに 1 つのチェックポイント ファイルがあり、各ストレージ グループには 1 つのログ ストリームがあります。1 つのストレージ グループ内では、すべてのデータベースは 1 つのログ ストリームを共有します。つまり、1 つのログ ファイルには通常複数のデータベースの処理が含まれています。

ログ ファイルは 16 進数方式で番号を付けられているため、E0000000009.log の次のログ ファイルは、E0000000010.log ではなく E000000000A.log になります。Windows 電卓 (Calc.exe) アプリケーションを関数電卓モードで使用すると、ログ ファイルのシーケンス番号を 10 進数の値に変換できます。これを行うには、Calc.exe を実行し、[表示] メニューの [関数電卓] をクリックします。

特定のログ ファイルのシーケンス番号を 10 進数で表示するには、Exchange Server データベース ユーティリティ (Eseutil.exe) ツールを使用してそのヘッダーを確認できます。各ログ ファイルの最初の 4 KB に相当するページには、ログ ファイルとログ ファイルが属するデータベースを説明および識別するヘッダー情報が含まれています。Eseutil /ml [log file name] コマンドにより、ヘッダー情報が表示されます。Eseutil の詳細については、「Eseutil」を参照してください。

たとえば、データベース ヘッダーに /ml ではなく /mh を使用し、ヘッダーを表示するために間違ったスイッチを使用すると、エラーが表示されたり、あるいは文字化けした、または間違ったヘッダー情報が表示されたりする可能性があります。

マウントされている間、データベースはヘッダーを表示できません。また、ストレージ グループのデータベースがマウントされている間も現在のログ ファイル (Enn.log) のヘッダーを表示できません。Exchange では、1 つのデータベースで現在のログ ファイルを使用している限り、このログ ファイルは開いたままになります。ただし、チェックポイント ファイルのヘッダーはデータベースがマウント中でも表示できます。Exchange では 30 秒ごとにチェックポイント ファイルを更新し、更新を実行している間以外はヘッダーを表示できます。

Exchange 管理者の方は、Exchange ファイル ヘッダーについて理解しておくと役立ちます。ファイル ヘッダーについて理解しておくと、どのデータベースとログ ファイルが対応し、正常に回復させるにはどのファイルが必要なのかを判断できます。

次のログ ファイル ヘッダーの例で、最初の 4 行に注意してください。

Base name: e00
Log file: e00.log
lGeneration: 11 (0xB)
Checkpoint: (0xB,7DC,6F)

ログ ファイル ヘッダーのこれらの行には、ログ ファイル名にシーケンス番号が含まれていないため、このログ ファイルは現在のログ ファイルであることを示します。lGeneration 行は、このログがいっぱいになり閉じられるとシーケンス番号が 10 進数値の 11 に相当する B になることを示しています。ベース名は e00 なので、最終的なログ ファイル名は E000000000B.log になります。

前のヘッダー例にある Checkpoint 値は実際にはログ ファイル ヘッダーから読み取られたのではありませんが、このように表示されます。Eseutil.exe は Enn.chk から Checkpoint 値を直接読み取るため、チェックポイント ファイルの場所を調査するために別のコマンドを入力する必要はありません。チェックポイント ファイルが破損している場合、Checkpoint 値は NOT AVAILABLE として読み取られます。この例では、チェックポイントは現在のログ ファイル (0xB) にあり、数値 7DC および 6F はログ ファイルのどこにチェックポイントがあるかを示しています。この情報が実際に必要になることはめったにありません。

チェックポイント ファイルが破損しても、Exchange はログ ファイルを適切に回復し、再生できます。そのためには、Exchange はチェックポイント ログからではなく使用可能な最も古いログ ファイルからスキャンを開始します。Exchange では既にデータベースに適用されているデータはスキップされ、適用する必要のあるデータを検出するまでログを順次スキャンします。

通常、Exchange では既にデータベースに適用されたログ ファイルをスキャンするのに 1、2 秒しかかかりません。データベースに書き込む必要のある処理がログ ファイル内にある場合は、それら実行するために 10 秒から数分かかります。平均では、ログ ファイルの内容は 30 秒以内にデータベースに書き込まれます。

Exchange データベースが正常にシャットダウンすると、すべての未解決データはデータベース ファイルに書き込まれます。正常にシャットダウンすると、データベース ファイル セットは整合状態にあると見なされ、Exchange のデータベース ファイル セットはログ ストリームから切断されます。つまり、この時点でデータベース ファイルは独立した状態になり、完全に最新の状態になります。データベース ファイルを開始するためにトランザクション ログは必要ありません。

データベースが正常にシャットダウンしたかどうかは Eseutil /mh コマンドを実行し、ファイル ヘッダー確認するとわかります。

ストレージ グループ内のすべてのデータベースが切断され、クリーン シャットダウン状態にある場合は、データベースに影響を与えずにすべてのログ ファイルを安全に削除できます。すべてのログ ファイルを削除すると、Exchange では Enn00000001.log から開始する新しい一連のログ ファイルが生成されます。既存のログ ファイルを持つ他のサーバーまたはストレージ グループにデータベース ファイルを移動することもできます。この場合、データベースは他のログ ストリームに接続されます。

note注 :
ストレージ グループ内のすべてのデータベースがシャットダウンされた後でログ ファイルを削除することもできますが、これによりさらに古いバックアップを復元したり、ロールフォワードしたりする機能に影響があります。現在のデータベースが既存のログ ファイルを必要としなくなっても、さらに古いデータベースを復元する場合に必要になる可能性があります。

データベースがダーティ シャットダウン状態にある場合は、チェックポイント以前のすべての既存トランザクション ログが存在しないと、データベースを再マウントすることはできません。これらのログを使用できない場合は、データベースを整合状態にして起動できるようにするために、Eseutil /p コマンドを実行し、データベースを修復する必要があります。

Caution注意 :
データベースを修復する必要がある場合、一部のデータが失われます。通常データ損失は最小限で済みますが、致命的な状態になる場合もあります。データベースで Eseutil /p を実行した後、次の 2 つの操作を実行してデータベースを完全に修復する必要があります。まず、Eseutil/d を実行し、データベースを最適化します。この操作を行うと、すべてのデータベースのインデックスおよび領域ツリーが破棄されて再構築されます。次に、Information Store Integrity Checker (Isinteg.exe) ツールを –fix モードで実行します。このツールは、データベースをスキャンし、未解決のトランザクション ログを廃棄することによって生じる論理的不整合を検出します。たとえば、データベース内に互いに最新の状態でない参照が存在する場合があります。Isinteg.exe は、データ損失を最小限に留めてこうした問題を修正することを試みます。

トランザクション ログは、データベースが予期せず停止した場合に Exchange でデータベースを正常に回復するためだけでなく、オンライン バックアップを作成および復元するためにも不可欠です。オンライン バックアップを作成および復元する方法の詳細については、「データベースのバックアップと復元」を参照してください。

循環ログ

ベスト プラクティスではありませんが、循環ログを有効にしてディスク領域を節約するように Exchange を構成することができます。Exchange の循環ログでは、ログ ファイルに含まれるデータがデータベースにコミットされた後でトランザクション ログ ファイルを上書きできます。ただし、循環ログを有効にした場合は、最後の完全バックアップまでのデータしか回復できません。

Exchange 2007 で使用される標準的なトランザクション ログで、ストレージ グループの各データベース トランザクションはログ ファイルの次にデータベースに書き込まれます。ログ ファイルのサイズが 1 メガバイト (MB) に到達すると、そのログ ファイルの名前が変更され、新しいログ ファイルが作成されます。時間の経過と共に、一連のログ ファイルが作成されます。Exchange が予期せず停止した場合、これらのログ ファイル内のデータをデータベースに再生することで、トランザクションを回復できます。循環ログでは、最初のログ ファイルに含まれていたデータがデータベースに書き込まれた後は、このログ ファイルを上書きし再利用します。

Exchange 2007 の循環ログは既定で無効になっています。有効にすると、必要なドライブの記憶領域が減ります。ただし、完全なトランザクション ログ ファイルのセットがないと、最後の完全バックアップより新しいデータは回復できません。このため、通常の運用環境で循環ログを使用することはお勧めしません。

Exchange 2007 で循環ログを有効または無効にする方法については、「ストレージ グループの循環ログを有効または無効にする方法」を参照してください。

連続レプリケーションと循環ログ

循環ログを連続レプリケーションと組み合わせることができます。この構成では、連続レプリケーション循環ログ (CRCL) という新しい種類の循環ログがあります。これは、前述した ESE 循環ログとは異なるものです。ESE 循環ログが Microsoft Exchange Information Store サービスによって実行および管理されるのに対して、CRCL は Microsoft Exchange Replication Service によって実行および管理されます。

ESE 循環ログを有効にすると、追加のログ ファイルが生成されることはなく、必要に応じて現在のログ ファイルが上書きされます。ただし、連続レプリケーション環境では、ログの配布や再生用にログ ファイルが必要です。その結果、CRCL を有効にすると、現在のログ ファイルは上書きされず、ログの配布や再生処理用に閉じられたログ ファイルが生成されます。具体的には、Microsoft Exchange Replication Service ではログの連続性を維持するように CRCL が管理されるため、レプリケーションに必要なログが削除されることはありません。したがって、CRCL を有効にしても、レプリケーションに悪影響することはありません。

Exchange 2007 の RTM (Release To Manufacturing) 版では、循環ログをクラスタ連続レプリケーション (CCR) またはローカル連続レプリケーション (LCR) と組み合わせることがサポートされています。ただし、バックアップが復元された後のロールフォワード回復は許可されていないため、お勧めしません。Exchange 2007 Service Pack 1 (SP1) では、CCR、LCR、またはスタンバイ連続レプリケーション (SCR) 環境のストレージ グループで循環ログを有効にすることもできます。ただし、この方法も、上記と同じ理由でお勧めできません。これらのいずれかの環境で有効にした場合、機能は ESE 循環ログ (Joint Engine Technology (JET) 循環ログとも呼ばれます) ではなく CRCL になります。CCR、LCR、または SCR の環境で循環ログを有効または無効にするには、常に以下の手順を使用する必要があります。

  1. Suspend-StorageGroupCopy コマンドレットを使用して、連続レプリケーションを中断します。
  2. 循環ログを有効または無効にします。循環ログを有効または無効にする方法の詳細については、「ストレージ グループの循環ログを有効または無効にする方法」を参照してください。
  3. 循環ログが有効または無効になっているストレージ グループで、データベースをマウント解除してからマウントします。
  4. Resume-StorageGroupCopy コマンドレットを使用して、連続レプリケーションを再開します。

LCR 環境のストレージ グループに関しては、Enable-StorageGroupCopy コマンドレットを実行して任意のストレージ グループ用に LCR を有効にする前に、ストレージ グループ内でデータベースをマウント解除してからマウントすることにより、現在の循環ログ設定が Microsoft Exchange Information Store サービスによって確実に検出され、利用されるようにする必要があります。Microsoft Exchange Information Store サービスによって構成の変更が検出されて利用されるようにするには、データベースをマウント解除してからマウントする必要がありますが、Microsoft Exchange Replication Service では、動的かつ再起動なしで構成の変更が検出されて利用されます。したがって、上記の手順を実行しない場合、データベースに関して、Microsoft Exchange Replication Service と Microsoft Exchange Information Store サービスとで、循環ログのオフとオンの状態が逆と見なされることがあります。この結果、ログ ファイルが途中で切り捨てられる場合があります。

note注 :
LCR または SCR を無効にすると、バックアップまたは循環ログでログ ファイルがコピーされずに削除されますが、CCR には無効化オプションはありません。CRCL が有効かどうかにかかわらず、CCR では、レプリケートが済んでいないログが削除されることはありません。

管理下で作成されたトランザクション ログの量を保持するために、管理者は、大容量のメールボックスを移動する際に循環ログを有効にする場合があります。メールボックスの移動は、2 つの異なるデータベースを使用する操作であるため、メールボックスの移動時には両方のデータベースの循環ログを有効にすることができます。

note注 :
循環ログを有効にすると、障害が発生した場合にストレージ グループを最新の状態にすることができないため、循環ログは長時間にわたって使用しないようにすることをお勧めします。

CRCL は、CCR、LCR、および SCR の環境で、メールボックスの移動やその他のログ ファイルが大量に生成される場合に備えて有効にすることができます。ただし、CRCL が有効になっている間は、バックアップを実行することはできません。そのため、以下の点を確認する必要があります。

  • メールボックスの移動がバックアップ操作の妨げにならないこと。これは、CRCL を有効にした場合、バックアップを実行できないためです。
  • メールボックスの移動の完了後に、CRCL を無効にしてバックアップを再開できるようにすること。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。