Data Guard環境ならではの問題と対処法：Oracleトラブル対策の基礎知識（7）（4/4 ページ）

図4　アーカイブギャップ

アーカイブギャップの対処法

　プライマリ・データベース側が、アーカイブギャップが発生していると判断すると、スタンバイ・データベースでまだ受信できていないログ順序番号のREDOデータを、プライマリ・データベースが再度転送します。この転送の処理はOracleが自動的に行うので、管理者が何か対処をする必要はありません。

手動ギャップリカバリによる対処法

　ただし、自動ギャップ・リカバリが行われる条件として、プライマリ・データベースが使用可能であることが必須となります。つまり、プライマリ・データベースが停止しているような状態でアーカイブギャップが発生していた場合、プライマリ・データベースを起動するか、手動でギャップを解消する必要があります。

　以下にフィジカル・スタンバイ・データベースにおける手動でのギャップ・リカバリについて、実際に例を挙げて対処手順をご紹介します。

　アーカイブギャップを確認するためにはV$ARCHIVE_GAPという動的パフォーマンスビューを参照します。HIGH_SEQUENCE# とLOW_SEQUENCE#に差が発生している場合は、その間のログ順序番号が現在発生しているアーカイブギャップとなります。

　実際には以下のようなSQLを発行します。

　スレッド番号1のログ順序番号45、46がアーカイブギャップとなっていることが分かりました。

　次に、この番号に対応するアーカイブログをプライマリ・データベースから転送します。スタンバイ・データベース側が管理リカバリモードになっている場合は、以下のコマンドを実行し、管理リカバリモードを解除します。

　転送したアーカイブログをスタンバイ・データベース側に適用します。例えば転送先ディレクトリが/oracle/arch/standby/でアーカイブログの名称がarch_1_45.arcおよびarch_1_46.arcである場合なら、スタンバイ・データベース側で実行するコマンドを以下に記載します。

　適用が完了したら、スタンバイ・データベースを管理リカバリモードに戻し、アーカイブギャップへの対処は完了となります。

まとめ

　いかがでしたでしょうか。Oracle Data Guardはアーカイブギャップが発生しても自動で解消する機能を持っているため、基本的には管理者のコストをかけることなく運用が可能です。また、RAC（Real Application Clusters）環境と組み合わせることで、RACの高可用性と拡張性に加え、対障害性を向上させることが可能です。

　本記事を参照いただき、Data Guard 構成をご検討いただくきっかけになれば幸いです。