アーカイブ・ギャップ アーカイブ・ギャップ アーカイブ・ギャップ
アーカイブ・ギャップは、スタンバイ・システムがプライマリ・データベースによって生成さ れた1つ以上のアーカイブREDOログ・ファイルを受信していないときに、スタンバイ・シス テムで発生する可能性があります。欠落しているアーカイブREDOログ・ファイルがギャップ です。ギャップがある場合、そのギャップはData Guardによって自動的に検出され、欠落し ているログ・ファイルの順序番号をスタンバイ宛先にコピーすることで解決されます。たとえ ば、アーカイブ・ギャップは、ネットワークが使用不可能になり、プライマリ・データベース からスタンバイ・データベースへの自動アーカイブが一時的に停止すると発生する可能性があ ります。ネットワークが再度使用可能になると、プライマリ・データベースからスタンバイ・
データベースへのREDOデータの自動転送が再開します。
Data Guardの場合、このようなギャップの検出と解決に、DBAによる手動操作は必要ありま
せん。次の各項では、ギャップの検出と解決について説明します。
5.8.1 アーカイブ・ギャップの検出時期 アーカイブ・ギャップの検出時期 アーカイブ・ギャップの検出時期 アーカイブ・ギャップの検出時期
アーカイブ・ギャップは、プライマリ・データベースがローカルにアーカイブしたログが、ス タンバイ・サイトでは受信されなかった場合に発生する可能性があります。プライマリ・デー タベースは、1分ごとにスタンバイ・データベースをポーリングして、アーカイブREDOロ グ・ファイルの順序番号にギャップがあるかどうかを確認します。
5.8.2 ギャップの解決方法 ギャップの解決方法 ギャップの解決方法 ギャップの解決方法
ギャップ・リカバリは、ポーリング・メカニズムを使用して処理されます。フィジカルおよび ロジカル・スタンバイ・データベース、Oracle Change Data CaptureおよびOracle Streamsの
場合、Data Guardはギャップ検出を実行し、欠落しているアーカイブREDOログ・ファイル
をプライマリ・データベースから自動的に取得することで解決します。スタンバイ・データ ベースのポーリング、ギャップの検出または解決のために、余分な構成設定を行う必要はあり ません。
ここで重要なことは、自動ギャップ・リカバリの実行には、プライマリ・データベースの可用 性が不可欠であることです。プライマリ・データベースが使用不可能な場合、構成に複数の フィジカル・スタンバイ・データベースが含まれていれば、REDO Applyによって別のスタン バイ・データベースからアーカイブ・ギャップを解決できるように初期化パラメータを追加設 定できます。詳細は、5.8.3項を参照してください。
ギャップを手動で解決する方法を示す使用例については、12.11項を参照してください。
関連項目 関連項目 関連項目
関連項目: 14-10ページ「DEPENDENCY」
注意 注意 注意
注意: Oracle Database 10g リリース1（10.1）までは、プライマリ・デー
タベースからのギャップを解決するためにFALクライアントおよびサー バーが使用されていました。
アーカイブ・ギャップの管理
REDO転送サービス 5-29
5.8.3 フェッチ・アーカイブ・ログ（ フェッチ・アーカイブ・ログ（ フェッチ・アーカイブ・ログ（ フェッチ・アーカイブ・ログ（ FAL ）を使用したアーカイブ・ギャップ ）を使用したアーカイブ・ギャップ ）を使用したアーカイブ・ギャップ ）を使用したアーカイブ・ギャップ の解決
の解決 の解決 の解決
フェッチ・アーカイブ・ログ（FAL）クライアントおよびサーバーは、プライマリ・データ ベースで生成されてフィジカル・スタンバイ・データベースで受信されたアーカイブREDOロ グ・ファイルの範囲内で、検出されたギャップを解決します。
■ FALクライアントは、アーカイブREDOログ・ファイルの転送を自動的に要求します。
■ FALサーバーは、FALクライアントからのFAL要求を処理します。
FALメカニズムでは、次のタイプのアーカイブ・ギャップと問題が処理されます。
■ フィジカルまたはロジカル・スタンバイ・データベースの作成時に、FALメカニズムでは、
プライマリ・データベースのホット・バックアップ中に生成されたアーカイブREDOロ グ・ファイルを自動的に取得できます。
■ すでにスタンバイ・データベースで受信されているアーカイブREDOログ・ファイルに問 題があると、FALメカニズムはアーカイブREDOログ・ファイルを自動的に取得して、次 の状況を解決できます。
– アーカイブREDOログ・ファイルが、スタンバイ・データベースに適用される前に ディスクから削除された場合。
– ディスク破損のためにアーカイブREDOログ・ファイルを適用できない場合。
– REDOデータがスタンバイ・データベースに適用される前に、アーカイブREDOロ グ・ファイルがそれ以外のファイル（テキスト・ファイルなど）によって意図せずに 置換された場合。
■ 複数のフィジカル・スタンバイ・データベースがある場合、FALメカニズムは欠落してい るアーカイブREDOログ・ファイルを別のフィジカル・スタンバイ・データベースから自 動的に取得できます。
FALクライアントおよびサーバーは、スタンバイ・データベースで設定されるFAL_CLIENTお よびFAL_SERVER初期化パラメータを使用して構成されます。初期化パラメータ・ファイルの FAL_CLIENTおよびFAL_SERVER初期化パラメータを、フィジカル・スタンバイ・データ ベースに対してのみ次の表に従って定義してください。
パラメータ パラメータ パラメータ
パラメータ 機能機能機能機能 構文構文構文構文
FAL_SERVER スタンバイ・データベースが
FALサーバーへの接続に使 用するネットワーク・サービ ス名を指定します。リストに は複数の値を指定できます。
構文 構文 構文 構文
FAL_SERVER=net_service_name 例例
例例
FAL_SERVER=standby2_db,standby3_db
FAL_CLIENT FALサーバーがスタンバイ・
データベースへの接続に使用 するネットワーク・サービス 名を指定します。
構文構文 構文構文
FAL_CLIENT=net_service_name 例
例 例 例
FAL_CLIENT=standby1_db
アーカイブ・ギャップの管理
5.8.4 手動によるアーカイブ・ギャップの判断および解決 手動によるアーカイブ・ギャップの判断および解決 手動によるアーカイブ・ギャップの判断および解決 手動によるアーカイブ・ギャップの判断および解決
自動ギャップ・リカバリを実行できず、ギャップ・リカバリを手動で実行する必要がある場合 があります。たとえば、ロジカル・スタンバイ・データベースの使用中にプライマリ・データ ベースが使用不可能になった場合は、ギャップ・リカバリを手動で実行する必要があります。
次の各項では、適切なビューを問い合せて欠落しているログ・ファイルを判断し、手動による リカバリを実行する方法を説明します。
フィジカル・スタンバイ・データベースの場合 フィジカル・スタンバイ・データベースの場合 フィジカル・スタンバイ・データベースの場合 フィジカル・スタンバイ・データベースの場合
フィジカル・スタンバイ・データベースにアーカイブ・ギャップが存在するかどうかを判断す るには、次の例に示すように、V$ARCHIVE_GAPビューを問い合せます。
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
--- --- 1 7 10
この出力例は、現在フィジカル・スタンバイ・データベースでスレッド1の順序番号7～10の ログ・ファイルが欠落していることを示しています。ギャップを識別した後、プライマリ・
データベースで次のSQL文を発行し、プライマリ・データベースのアーカイブREDOログ・
ファイルの位置を特定します（プライマリ・データベースのローカル・アーカイブ先はLOG_
ARCHIVE_DEST_1とします）。
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND 2> SEQUENCE# BETWEEN 7 AND 10;
NAME
---/primary/thread1_dest/arcr_1_7.arc
/primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc
これらのログ・ファイルをフィジカル・スタンバイ・データベースにコピーし、コピーしたロ グをALTER DATABASE REGISTER LOGFILE文を使用してフィジカル・スタンバイ・データ ベースに登録します。次に例を示します。
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_8.arc';
ログ・ファイルをフィジカル・スタンバイ・データベースに登録した後は、REDO Applyを再 開できます。
注意注意
注意注意: フィジカル・スタンバイ・データベースのV$ARCHIVE_GAP固定 ビューが戻すのは、REDO Applyの続行をブロックしている次のギャップ のみです。そのギャップを解決してREDO Applyを開始した後、
V$ARCHIVE_GAP固定ビューをフィジカル・スタンバイ・データベースで 再度問い合せて、次のギャップ・シーケンス（存在する場合）を判断しま す。この処理をギャップがなくなるまで繰り返します。
アーカイブ・ギャップの管理
REDO転送サービス 5-31 ロジカル・スタンバイ・データベースの場合
ロジカル・スタンバイ・データベースの場合 ロジカル・スタンバイ・データベースの場合 ロジカル・スタンバイ・データベースの場合
アーカイブ・ギャップが存在するかどうかを判断するには、ロジカル・スタンバイ・データ ベースでDBA_LOGSTDBY_LOGビューを問い合せます。たとえば、次の問合せでは、ロジカ ル・スタンバイ・データベースのTHREAD 1に、2つのファイルが表示されているため、アー カイブREDOログ・ファイルの順序番号にギャップがあることを示しています（ギャップがな い場合、問合せで表示されるのは、スレッドごとに1つのファイルのみです）。この出力は、登 録されたファイルの最大の順序番号は10ですが、順序番号6で示されるファイルにギャップが あることを示しています。
SQL> COLUMN FILE_NAME FORMAT a55
SQL> SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L 2> WHERE NEXT_CHANGE# NOT IN
3> (SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#) 4> ORDER BY THREAD#,SEQUENCE#;
THREAD# SEQUENCE# FILE_NAME
--- --- 1 6 /disk1/oracle/dbs/log-1292880008_6.arc
1 10 /disk1/oracle/dbs/log-1292880008_10.arc
順序番号7、8および9の欠落しているログ・ファイルをロジカル・スタンバイ・システムにコ ピーし、コピーしたログをALTER DATABASE REGISTER LOGICAL LOGFILE文を使用して ロジカル・スタンバイ・データベースに登録します。
次に例を示します。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE '/disk1/oracle/dbs/log-1292880008_10.arc';
ログ・ファイルをロジカル・スタンバイ・データベースに登録した後は、SQL Applyを再開で きます。
注意 注意 注意
注意: ロジカル・スタンバイ・データベースのDBA_LOGSTDBY_LOG ビューが戻すのは、SQL Applyの続行をブロックしている次のギャップの みです。識別したギャップを解決してSQL Applyを開始した後、DBA_
LOGSTDBY_LOGビューをロジカル・スタンバイ・データベースで再度問 い合せて、次のギャップ・シーケンス（存在する場合）を判断します。こ の処理をギャップがなくなるまで繰り返します。