DAG構成の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側を削除…というパターンもやってみましたが挙動は変化ありませんでした。

緊急時の対応としては、単純にコミット済みのトランザクションログの退避あるいは削除が手段として使えそうです。