Transaction Log

Exchange Server 2010のDAGのトランザクションログがDPM 2012でバックアップを実施しても消えない…という話を受けて、調査してみました。 調べた所以下のブログに非常に良い情報がありました。 - [Exchange 2010: Log Truncation and Checkpoint At Log Creation in a Database Availability Group - Tim McMichael - Site Home - TechNet Blogs](http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx) Exchange Server 2010 SP1以降挙動が変わっており、要点は以下とのことです。 - ログファイルを消しているのはバックアップソフトウェアではなくて、ExchangeのReplicationサービス - トランザクションログが作成されたタイミングのチェックポイントがログファイルに埋め込まれている - DAGのコピーノード毎にどこまでログの切り詰めをしていいか報告される - 一番わかい番号までログのきりつめを行えると判断されるが、実際には”checkpoint depth”の分だけは消さずに残しておく - 切り詰めされるのはきちんと増分バックアップされているファイルのみ - “Checkpoint at log creation time”はeseutil /ml <ログファイル名>”で確認できる 要は、きちんとバックアップが成功していても、チェックポイントとして100程度、実際のファイル数としてはそれ以上のログファイルが残っているのが正常だ、ということです。 今回の検証環境では200ファイル程度ログファイルが残っており、確かに最新のログと最古のログとでチェックポイントとして100の違いがありました。

今回はメールボックス移行(移動)時のトランザクションログの生成量に関してです。 特に、Exchange Serverのバージョンアップ時には、大量のメールボックス移動が発生します。この中で移行先のメールボックスに関しては大量にメールボックス、メールアイテム等を書き込むことになりますのでメールボックスサイズ以上の量のトランザクションログが発生します。一方、移行元のメールボックス側にはトランザクションログは大量に発生するのでしょうか?しないのでしょうか? この問題は移行案件があるたびに、案件メンバーから質問もでますし、実はネット上の情報も混乱しています。さらに、実際の挙動も不思議な感じです。 確認できるネット上の情報 メールボックス データベースおよびログの容量の要因について: Exchange 2010 のヘルプ http://technet.microsoft.com/ja-jp/library/ee832796(v=exchg.141).aspx 移動元サーバーでログに記録されるのはレコードの削除で、ログの量は多くありませんが、移動先サーバーでは転送されたすべてのデータを最初にトランザクション ログに書き込む必要があります。 Exchange Server 2003 でのメールボックスの移動 http://support.microsoft.com/kb/821829/ja データを 1 GB 移動するたびに、移動元および移動先のサーバーに 1 GB のトランザクション ログが生成されます。トランザクション ログ ドライブに十分な空き容量があることを確認してください。 バージョンの違いはありますが、真逆のことが書かれています。 Exchange Server 2007から2010への移行テストでの実績 以下は特定の環境で簡単にテストしてみた結果です。 - 移行先発生量 100MB移行時 –> 約200MB程度 - 1GB移行時 –> 約1.5GB程度 - 移行元発生量 100MB移行時 –> 約2MB程度 - 1GB移行時 –> 約200MB程度 移行元にもそれなりの量のトランザクションログが生成されています。しかも、元々のメールボックス容量と比較して正比例の関係にもなっていません。 また、移行をトリガーとせずにトランザクションログが異常に大量生成されるようなバグも過去存在しています。 - An Exchange Server 2007 mailbox server randomly generates many transaction logs in an Exchange Server 2007 Service Pack 1 environment http://support.microsoft.com/kb/947014/en-us ...

Exchange Serverにてどのトランザクションログまでコミット済みかということはeseutilでチェックポイントファイルを確認することで可能ですが、「DAGでどこまでトランザクションログをコピーしたのか?」ということを確認する方法は調べても情報が見つかりません。適当に探してみたらそれらしいものがあったので記録しておきます。(情報の正確性は保証しません) いきなり答えですが、おそらくDAGのアクティブ側DBを保持しているサーバーの以下のパフォーマンスカウンタがそれを示していると思います。 - MSExchange Replication\CopyNotificationGenerationNumber - MSExchange Replication\CopyGenerationNumber - MSExchange Replication\InspectorGenerationNumber - MSExchange Replication\ReplayGenerationNumber - MSExchange Replication\ReplayNotificationGenerationNumber 検証環境で確認してみたところ、上記のカウンタがすべて24になっていました。すべて同じ数字でそろっているのは、検証環境で新しいトランザクションログが発生していないからだと思われます。 最後に複製されているトランザクションログのファイル名は「E0200000018」となっており、16進数の0x18は10進数の24なのでビンゴだと思われます。 さらに、このカウンタはアクティブなDatabaseを持っているサーバーでのみ値が確認できました。アクティブ側のみで数字を把握しているようです。 そもそも論としては「こんなこと知ってどうするの?普通にトランザクションログ自体を確認すればわかるじゃない」という感じではあるのですが、手動でDB自体やトランザクションログをごねごねしたり、シード処理を自動で行わせずに無理やりやりたいようなケースで確認したいという話があったので調べてみました。本当はそういう変なことはせずに、きちんと普通のオペレーションでできるように環境をつくったり、スケジュールを立てたりするのがいいんですけどね…。

Exchange ServerのDatabaseに対しては、バックアップが正常に動作していなかった時にトランザクションログが貯まりすぎてしまったような場合にコミット済みのログを調べ、それを手動で退避あるいは削除するというオペレーションをよく行っていました。 [XADM] Eseutil を使用してコミット済みのログを特定する Exchange Server 2010のDAGでDatabase Copyが構成されているDatabaseの場合、このあたりの操作はどのように行えるのか、行えないのか、情報を調べてもほとんどみつからないので実際の動作を確認してみることにしました。(正確性は保証しません。「私の環境ではこのように動いた」以上でも以下でもありません。) ちなみにテストしている環境はExchange Server 2010 SP2の環境です。 同期している状態 上記はコピーを開始した直後で、両者の保持しているログに差異が無い状態です。 この状態から、大きめの添付ファイルをDatabaseに存在しているユーザーに送信し、トランザクションログを発生させます。 この操作の結果、以下のようにE0200000006～E020000000Eまでのファイルが生成され、同時に、アクティブからパッシブにコピーされました。 ここでActive側のDatabaseにて、コミット済みのトランザクションログを調べ、コミット済みのログファイルを削除してみます。 「eseutil /mk」にて0x5のファイルまでコミット済みであることがわかりました。 すでにコミット済みであるファイルをActive側で手動で削除してみます。 結果、特に何の問題もなくファイルは消え、その後特にエラーも何も表示されることなく通常通り使えています。Aassive側のDatabase側にトランザクションログが削除されたという情報が伝わっている様子もありません。20分ほど時間をおいてみましたが、そのままでした。 次に、Passive側でもコミット済みであることを確認したうえで、Active側で削除したトランザクションログファイルを手動削除してみます。 この操作後も、特段何の反応もなく、正常稼働を続けています。DAGでコピーを構成したとしてもすでに処理の終わったトランザクションログに関しては取り立てて何も監視、処理はしていないという事になると思います。トランザクションログファイル自体は環境によっては大量に生成されるでしょうし、それをすべて監視するようなことはリソースの無駄になると思われますので妥当な動きだと思います。 確認のために先にPassive側を削除し、その後Active側を削除…というパターンもやってみましたが挙動は変化ありませんでした。 緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange Serverにてどのトランザクションログまでコミット済みかということはeseutilでチェックポイントファイルを確認することで可能ですが、「DAGでどこまでトランザクションログをコピーしたのか?」ということを確認する方法は調べても情報が見つかりません。適当に探してみたらそれらしいものがあったので記録しておきます。(情報の正確性は保証しません) いきなり答えですが、おそらくDAGのアクティブ側DBを保持しているサーバーの以下のパフォーマンスカウンタがそれを示していると思います。 - MSExchange Replication\CopyNotificationGenerationNumber - MSExchange Replication\CopyGenerationNumber - MSExchange Replication\InspectorGenerationNumber - MSExchange Replication\ReplayGenerationNumber - MSExchange Replication\ReplayNotificationGenerationNumber 検証環境で確認してみたところ、上記のカウンタがすべて24になっていました。すべて同じ数字でそろっているのは、検証環境で新しいトランザクションログが発生していないからだと思われます。 最後に複製されているトランザクションログのファイル名は「E0200000018」となっており、16進数の0x18は10進数の24なのでビンゴだと思われます。 さらに、このカウンタはアクティブなDatabaseを持っているサーバーでのみ値が確認できました。アクティブ側のみで数字を把握しているようです。 そもそも論としては「こんなこと知ってどうするの?普通にトランザクションログ自体を確認すればわかるじゃない」という感じではあるのですが、手動でDB自体やトランザクションログをごねごねしたり、シード処理を自動で行わせずに無理やりやりたいようなケースで確認したいという話があったので調べてみました。本当はそういう変なことはせずに、きちんと普通のオペレーションでできるように環境をつくったり、スケジュールを立てたりするのがいいんですけどね…。

Exchange Server 関連の記事はExchange Server Blogにまとめて書くことにしました。よろしければあわせて御覧ください。 Exchange ServerのDatabaseに対しては、バックアップが正常に動作していなかった時にトランザクションログが貯まりすぎてしまったような場合にコミット済みのログを調べ、それを手動で退避あるいは削除するというオペレーションをよく行っていました。 [XADM] Eseutil を使用してコミット済みのログを特定する Exchange Server 2010のDAGでDatabase Copyが構成されているDatabaseの場合、このあたりの操作はどのように行えるのか、行えないのか、情報を調べてもほとんどみつからないので実際の動作を確認してみることにしました。(正確性は保証しません。「私の環境ではこのように動いた」以上でも以下でもありません。) ちなみにテストしている環境はExchange Server 2010 SP2の環境です。 同期している状態 上記はコピーを開始した直後で、両者の保持しているログに差異が無い状態です。 この状態から、大きめの添付ファイルをDatabaseに存在しているユーザーに送信し、トランザクションログを発生させます。 この操作の結果、以下のようにE0200000006～E020000000Eまでのファイルが生成され、同時に、アクティブからパッシブにコピーされました。 ここでActive側のDatabaseにて、コミット済みのトランザクションログを調べ、コミット済みのログファイルを削除してみます。 「eseutil /mk」にて0x5のファイルまでコミット済みであることがわかりました。 すでにコミット済みであるファイルをActive側で手動で削除してみます。 結果、特に何の問題もなくファイルは消え、その後特にエラーも何も表示されることなく通常通り使えています。Aassive側のDatabase側にトランザクションログが削除されたという情報が伝わっている様子もありません。20分ほど時間をおいてみましたが、そのままでした。 次に、Passive側でもコミット済みであることを確認したうえで、Active側で削除したトランザクションログファイルを手動削除してみます。 この操作後も、特段何の反応もなく、正常稼働を続けています。DAGでコピーを構成したとしてもすでに処理の終わったトランザクションログに関しては取り立てて何も監視、処理はしていないという事になると思います。トランザクションログファイル自体は環境によっては大量に生成されるでしょうし、それをすべて監視するようなことはリソースの無駄になると思われますので妥当な動きだと思います。 確認のために先にPassive側を削除し、その後Active側を削除…というパターンもやってみましたが挙動は変化ありませんでした。 緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。