Data Guardでは、プライマリ・データベースからREDOデータを転送して、スタンバイ・データベースに適用していきますが、この REDOデータはネットワーク間を経由して転送されます。ネットワーク間の通信ができなくなってしまったり、転送中にREDOデータの中身が壊れてしまった場合、スタンバイ・データベースではREDOデータを受信して適用ができないので、データの同期が取れていない状態が発生します。このことをアーカイブギャップと呼びます。
プライマリ・データベースは、スタンバイ・データベース側で起動しているRFSプロセスと定期的に通信を行っており、アーカイブギャップが発生していないかを確認しています。
プライマリ・データベースから転送しようとしているREDOデータのログ順序番号と、スタンバイ・データベースが最後に受信したREDOデータのログ順序番号を比較します。ここではアーカイブギャップ発生時のプライマリ・データベースとスタンバイ・データベースの挙動について紹介します。
プライマリ・データベース側が、アーカイブギャップが発生していると判断すると、スタンバイ・データベースでまだ受信できていないログ順序番号のREDOデータを、プライマリ・データベースが再度転送します。この転送の処理はOracleが自動的に行うので、管理者が何か対処をする必要はありません。
注意!
8i以前のバージョンでは自動でギャップは解消されず、手動での対処が必要でした。また、9iR1から10gR1までのバージョンのフィジカル・スタンバイ・データベースでは、フェッチ・アーカイブ・ログ(FAL)という機構により、ギャップの検出および解消を行っているため、初期化パラメータFAL_SERVER、FAL_CLIENTの設定が必要になります。なお、FAL_SERVER、FAL_CLIENTの設定方法につきましてはマニュアル「Oracle Data Guard 概要および管理」に詳細が記載されていますのでご参照ください。
ただし、自動ギャップ・リカバリが行われる条件として、プライマリ・データベースが使用可能であることが必須となります。つまり、プライマリ・データベースが停止しているような状態でアーカイブギャップが発生していた場合、プライマリ・データベースを起動するか、手動でギャップを解消する必要があります。
以下にフィジカル・スタンバイ・データベースにおける手動でのギャップ・リカバリについて、実際に例を挙げて対処手順をご紹介します。
アーカイブギャップを確認するためにはV$ARCHIVE_GAPという動的パフォーマンスビューを参照します。HIGH_SEQUENCE# とLOW_SEQUENCE#に差が発生している場合は、その間のログ順序番号が現在発生しているアーカイブギャップとなります。
実際には以下のようなSQLを発行します。
SQL> SELECT * FROM V$ARCHIVE_GAP; THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# ----------- ------------- -------------- 1 44 47 45、46でギャップが発生
スレッド番号1のログ順序番号45、46がアーカイブギャップとなっていることが分かりました。
次に、この番号に対応するアーカイブログをプライマリ・データベースから転送します。スタンバイ・データベース側が管理リカバリモードになっている場合は、以下のコマンドを実行し、管理リカバリモードを解除します。
SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;
転送したアーカイブログをスタンバイ・データベース側に適用します。例えば転送先ディレクトリが/oracle/arch/standby/でアーカイブログの名称がarch_1_45.arcおよびarch_1_46.arcである場合なら、スタンバイ・データベース側で実行するコマンドを以下に記載します。
SQL> ALTER DATABASE REGISTER LOGFILE '/oracle/arch/standby/arch_1_45.arc'; SQL> ALTER DATABASE REGISTER LOGFILE '/oracle/arch/standby/arch_1_46.arc';
適用が完了したら、スタンバイ・データベースを管理リカバリモードに戻し、アーカイブギャップへの対処は完了となります。
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT;
いかがでしたでしょうか。Oracle Data Guardはアーカイブギャップが発生しても自動で解消する機能を持っているため、基本的には管理者のコストをかけることなく運用が可能です。また、RAC(Real Application Clusters)環境と組み合わせることで、RACの高可用性と拡張性に加え、対障害性を向上させることが可能です。
本記事を参照いただき、Data Guard 構成をご検討いただくきっかけになれば幸いです。
Copyright © ITmedia, Inc. All Rights Reserved.