ログ適用サービスの管理

ログ適用に関連するデータベース・プロパティを使用して、フィジカルまたはロジカル・スタンバイ・データベース上のREDO ApplyおよびSQL Applyを管理できます。

ログ適用関連のデータベース・プロパティは次のとおりです。

• REDO ApplyおよびSQL Applyに共通のプロパティ

  • ApplyInstanceTimeout

  • DelayMins

  • PreferredApplyInstance

• REDO Applyに固有のプロパティ

  • ApplyParallel

  • ApplyInstances

現在のデータベースの状態がAPPLY-ONの場合、SQL Apply関連のプロパティを変更すると、SQL Applyの再起動が必要になる場合があります。SQL Applyの再起動が必要なプロパティを調べるには、「Oracle Data Guard Brokerのプロパティ」のSQL Apply関連のプロパティの情報を参照してください。

データベースの現在の状態がAPPLY-OFFの場合、プロパティ変更はデータベースの状態が次回にAPPLY-ONに変化したときに有効になります。

遅延適用の管理

スタンバイ・データベースへのREDOの適用を遅延させるように適用サービスを設定できます。

これにより、スタンバイ・データベースとプライマリ・データベース間にずれが生じ、この期間中にユーザー・エラー(表の削除など)が発生した場合も、スタンバイ・データベースには正しいデータが含まれているため、それをプライマリ・データベースに転送してデータを修復できます。

デフォルトでは遅延は設定されておらず、REDOデータはできるかぎり速やかにスタンバイ・データベースに適用されます。スタンバイ・データベースでREDOログが構成されると、ブローカは、リアルタイム適用を有効化します。REDO ApplyおよびSQL ApplyがリアルタイムでREDOを適用する場合、REDOデータは、書き込まれると同時に、スタンバイREDOログ・ファイルから直接リカバリされます。つまり、スタンバイ・データベースは、アーカイブREDOログ・ファイルからREDOデータを適用するのにログ・ファイルがアーカイブされるのを待つ必要はありません。これにより、プライマリとスタンバイのトランザクション・ラグが最小限に抑えられます。

データベース・プロパティDelayMinsを使用して、スタンバイ・データベースにREDOデータが適用されるまでのログ適用サービスの待機時間(分)を指定します。スタンバイ・データベースへのログ適用サービスのみが遅延されることに注意してください。プライマリ・データベースのREDO転送サービスは遅延されないため、プライマリ・データベースのデータは引き続きスタンバイ・データベースにより適切に保護されます。

注意:

ブローカではスタンバイ・データベースへのリアルタイム適用が自動的に有効化されるため、フラッシュバック・データベースを使用するようにすべてのデータベースを構成することをお薦めします。

REDO Applyでのパラレル適用の管理

REDO Applyでは、データベース・プロパティApplyParallelを使用して、プライマリ・データベースから受け取ったREDOデータの適用に複数のパラレル・プロセスを使用するかどうかを構成できます。

並列性はデフォルトで有効化されています。つまり、REDO ApplyではシステムのCPUの数に基づいて最適なパラレル・プロセス数が自動的に選択されます。(これは、ApplyParallelプロパティをAUTOに設定することと同じです。) ApplyParallelプロパティをNOに設定することで並列性を無効化できます。

ノート:

パラレルREDO ApplyはマルチインスタンスREDO Applyとは異なります。パラレルREDO Applyとは、各インスタンスに複数のREDO Applyスレーブがあることを意味し、この値は、ブローカのApplyParallelプロパティで設定します。マルチインスタンスREDO Applyとは、複数のインスタンスがREDO Applyを実行していることを意味し、この値は、ブローカのApplyInstancesプロパティで設定します。これら2つのプロパティを同時に使用すると、適用がマルチインスタンス適用で実行されている各インスタンス上で、REDO Applyアプライヤを制御できます。ApplyParallelプロパティで指定するパラレル・アプライヤの数は、マルチインスタンス適用構成内の各インスタンスで同一になります。

関連項目:

ApplyParallel

ApplyInstances

マルチインスタンスREDO Applyの管理

Oracle RACデータベースのREDO Applyについては、ApplyInstancesプロパティの値を使用して、リカバリに使用できるインスタンスの数を構成できます。

デフォルトでは、1つのインスタンスのみがリカバリ・アクティビティに関係します。ただし、ApplyInstancesプロパティを設定して、特定のインスタンス数を指定したり、値ALLですべてのインスタンスを指定することができます。リカバリが開始すると、設定された数のインスタンスがリカバリを開始できるかどうかがチェックされます。できない場合、ブローカはリカバリの開始を1分間遅らせて、他のインスタンスを起動してからリカバリを開始します。

定期的な健全性チェック時に、ブローカはリカバリに使用できる可能性のあるインスタンスが他に開始されていないかどうかをチェックします。該当する場合、ブローカはリカバリを停止して再開し、追加のインスタンスを使用します。

ApplyInstancesプロパティの値を変更すると、その新しい値を使用してリカバリが再開されます。

そのインスタンスをリカバリで使用するには、すべてのインスタンスを同じ状態(オープンまたはマウント済)にする必要があります。

Oracle RACデータベース環境での適用サービス

スタンバイ・データベースがOracle RACデータベースの場合、SQL ApplyおよびREDO Applyは適用インスタンスを利用します。

SQL Applyは、任意の時点でのOracle RACデータベースの1つのインスタンスのみで実行できます。このインスタンスを適用インスタンスと呼びます。

REDO Applyは一度にOracle RACデータベースのすべてのインスタンスで実行できますが、そのうちの1つのインスタンスのみが適用コーディネータであり、これはブローカが適用インスタンスとみなしたインスタンスです。この機能では、構成可能なデータベース・プロパティApplyInstances (フィジカル・スタンバイ・データベースでのみ有効)が0以外の値に設定する必要があります。ApplyInstancesを参照してください。

適用インスタンスに障害が発生すると、ブローカは必要に応じて異なるインスタンスでSQL ApplyまたはREDO Applyコーディネータを自動的に再起動します。これは、適用インスタンスのフェイルオーバーと呼ばれます(「適用インスタンスのフェイルオーバー」を参照)。

適用インスタンスの選択

Oracle RACスタンバイ・データベースでどのインスタンスを適用インスタンスにしてもよい場合、ブローカが適用インスタンスを任意に選択します。特定のインスタンスを適用インスタンスとして選択するには、次の2つの方法があります。

ノート:

この項の情報は、スナップショット・スタンバイ・データベースまたは遠隔同期インスタンスには適用されません。

• 最初の方法は、PreferredApplyInstanceデータベース・プロパティの値を、適用インスタンスとして指定するインスタンスの名前(InstanceNameプロパティを参照)に設定することです。ブローカは、Oracle RACスタンバイ・データベースで適用インスタンスが選択されていない場合に、そのインスタンス上でログ適用サービスを起動します。この方法を使用するのは、スタンバイ・データベースをまだ1度も有効化していない場合、適用インスタンスに障害が発生したばかりで、ブローカが適用インスタンスをフェイルオーバーしようとしている場合、またはOracle RACデータベースが現在プライマリ・データベースとして稼働中で、スイッチオーバーの準備として適用インスタンスを指定する必要がある場合などです。適用インスタンスが選択されており、かつ、その適用インスタンスが実行中の場合は、PreferredApplyInstanceプロパティを変更しても、ブローカでは変更後の値が無視されます。

• 第2の方法では、選択され実行されている適用インスタンスを変更します。適用インスタンスを変更するには、特定の適用インスタンス引数を指定してDGMGRLのSET STATEコマンドを発行し、スタンバイ・データベースの状態をAPPLY-ONに設定します。SET STATEコマンドを実行すると、PreferredApplyInstanceプロパティが新しい適用インスタンスの値に更新されてから、ログ適用サービスが新規インスタンスに移動します。たとえば、DGMGRLのSHOWコマンドを使用してスタンバイ・データベースで使用可能なインスタンスを表示し、EDIT DATABASEコマンドを発行してログ適用サービスを新規インスタンスに移動します。

  DGMGRL> SHOW DATABASE 'South_Sales'
   
  Database - South_Sales
   
    Role:            PHYSICAL STANDBY
    Intended State:  APPLY-ON
    Transport Lag:   0 seconds (computed 1 second ago)
    Apply Lag:       0 seconds (computed 1 second ago)
    Apply Rate:      1017.00 KByte/s
    Real Time Query: OFF
    Instance(s):
      south_sales1   (apply instance)
      south_sales2
   
  Database Status:
  SUCCESS
  

  DGMGRL> EDIT DATABASE 'South_Sales' SET STATE='APPLY-ON' WITH APPLY INSTANCE='south_sales2';
  Succeeded.
  
  DGMGRL> SHOW DATABASE 'South_Sales' 'PreferredApplyInstance';
    PreferredApplyInstance = 'south_sales2'
  

  DGMGRL> SHOW DATABASE 'South_Sales'
   
  Database - South_Sales
   
    Role:            PHYSICAL STANDBY
    Intended State:  APPLY-ON
    Transport Lag:   0 seconds (computed 1 second ago)
    Apply Lag:       0 seconds (computed 1 second ago)
    Apply Rate:      1017.00 KByte/s
    Real Time Query: OFF
    Instance(s):
      south_sales1
      south_sales2   (apply instance)
   
  Database Status:
  SUCCESS
  

コマンドの発行時には、新規適用インスタンスが実行中であることを確認してください。それ以外の場合は、適用インスタンスが変更されません。

適用インスタンスの選択後、ブローカは適用インスタンス情報をブローカ構成ファイルに保存します。これにより、スタンバイ・データベースが停止されて再起動されても、ブローカは停止前と同じインスタンスを選択してログ適用サービスを起動できます。適用インスタンスは、ユーザーが変更するか、なんらかの原因で障害が発生してブローカが適用インスタンスのフェイルオーバーを実行すると決定するまで変更されません。

適用インスタンスのフェイルオーバー

適用インスタンスの障害に対するフォルト・トレラントを持たせるために、ブローカはログ適用サービスを異なるスタンバイ・インスタンスに自動的にフェイルオーバーすることで、Oracle RACスタンバイ・データベースの可用性を利用します。

ブローカが提供する適用インスタンスのフェイルオーバー機能により、データ保護が強化されます。

適用インスタンスのフェイルオーバーを設定するには、データベース・プロパティApplyInstanceTimeoutを設定してブローカの待機時間を指定します。この待機時間は、適用インスタンス障害を検出してから適用インスタンスのフェイルオーバーを開始するまでの期間です。適切なタイムアウト値を選択するには、次のことを考慮する必要があります。

• クラスタに、障害が発生した適用インスタンスのリカバリを試みる他のメカニズムがあるかどうか(Oracle Clusterwareなど)。

• ビジネスで、REDOデータがスタンバイ・データベースに適用されないことを容認できる時間。

• ログ適用サービスを他のインスタンスに移動する操作に関連するオーバーヘッド。

ブローカのApplyInstanceTimeoutプロパティのデフォルト値は0秒です。これは、現在の適用インスタンスの障害検出後ただちに、適用インスタンスのフェイルオーバーが開始されることを示しています。

ブローカでは、適用インスタンスのフェイルオーバー開始後に、次のルールに従って新規の適用インスタンスが選択されます。PreferredApplyInstanceプロパティが現在実行中のインスタンスを示している場合は、それが新規の適用インスタンスとして選択されます。それ以外の場合は、現在実行中の任意のインスタンスが新規の適用インスタンスとして選択されます。

また、適用インスタンスの障害発生時にフィジカル・スタンバイ・データベースがリアルタイム問合せモードで動作していた場合、Oracleリカバリ・クリーンアップの完了後、自動的にクローズされたインスタンスはすべてブローカによってオープンされます。障害の発生した適用インスタンスが唯一のオープン・インスタンスであった場合、リアルタイム問合せを再度有効にするため、適用サービスを開始する前に、新しい適用インスタンスとして選択されたインスタンスがオープンされます。

関連項目:

• リアルタイム問合せモードの詳細は、『Oracle Data Guard概要および管理』を参照してください。

• Oracle Active Data GuardのOracle RACスタンバイにおける適用インスタンス障害の詳細は、https://support.oracle.comにあるMy Oracle Supportノート1357597.1を参照してください。

適用ラグ

適用ラグは、REDOの伝播および適用の遅延により、スタンバイ・データベースのデータがプライマリ・データベースのデータからどの程度遅れているかを測定する尺度です。

Cloud ControlとDGMGRLクライアントのいずれでも、管理対象スタンバイ・データベースごとに適用ラグが表示されます。Cloud Controlでは、Oracle Data Guardホームページに適用ラグが表示されます。DGMGRLクライアントでは、SHOW DATABASE出力に適用ラグが表示されます。プライマリ・データベースまたは遠隔同期インスタンスに対する適用ラグは表示されません。たとえば:

DGMGRL> SHOW DATABASE 'South_Sales';

Database - South_Sales

  Role:                PHYSICAL STANDBY
  Intended State:      APPLY-ON
  Transport Lag:       0 seconds (computed 1 second ago)
  Apply Lag:           0 seconds (computed 1 second ago)
  Average Apply Rate:  13.00 KByte/s
  Real Time Query:     OFF
  Instance(s):
    SouthSales

Database Status:
SUCCESS

Oracle Databaseリリース19c以上では、SHOW CONFIGURATION LAGコマンドによって、ブローカ構成のサマリーおよびすべてのスタンバイ・データベースの適用ラグが表示されます。

適用ラグでは、REDO転送サービスとログ適用サービスで発生する可能性のある問題を識別することができます。

構成可能なデータベース・プロパティApplyLagThresholdを設定すると、スタンバイ・データベースまたは遠隔同期インスタンスがプライマリ・データベースのデータに遅れを取る場合に健全性チェック警告を生成できます。

次のコマンドは、ApplyLagThresholdプロパティを15秒に設定します。

DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'ApplyLagThreshold'=15;
Property ApplyLagThreshold updated