1. 高可用性概要およびベスト・プラクティス
  2. Oracle Data Guardのベスト・プラクティス
  3. Oracle Data Guardの構成およびデプロイ

14 Oracle Data Guardの構成およびデプロイ

Oracle Data Guardを構成およびデプロイするには、次のOracle MAAベスト・プラクティスの推奨事項を使用します。

Oracle Data Guardの構成ベスト・プラクティス

次のトピックでは、Oracle Data Guard構成を構成するためのOracle MAAベスト・プラクティスについて説明します。

最初にOracle Database構成のベスト・プラクティスを適用

後続のOracle Data Guardのベスト・プラクティスを実装する前に、Oracle Database構成のベスト・プラクティスを適用します。

Oracle Data Guard構成ベスト・プラクティスは、一般的なOracle Database構成のベスト・プラクティスを補足するものであり、MAA Goldリファレンス・アーキテクチャで想定されるサービス・レベルを実現するのに役立ちます。つまり、Data Guard構成ではデータベース構成のすべてのベスト・プラクティスに従い、矛盾がある場合には一般的なデータベースの推奨事項よりもここで説明するData Guardの推奨事項を優先するということです。

詳細は、Oracle Database構成のベスト・プラクティスを参照してください。

Recovery Managerを使用したスタンバイ・データベースの作成

Oracle Data Guardスタンバイ・データベースはいくつかの方法で作成できますが、Oracle MAAでは、その簡易性から、RMAN RESTORE ... FROM SERVICE句を使用してフィジカル・スタンバイ・データベースを作成するアプローチが推奨されます。

このアプローチの詳細は、Creating a Physical Standby database using RMAN restore from service (Doc ID 2283978.1)を参照してください。

Oracle Data GuardによるOracle Data Guardブローカの使用

Oracle Data Guard Brokerを使用して、Oracle Data Guard構成を作成、管理および監視します。

このブローカのインタフェースである、Oracle Enterprise ManagerのData Guard管理ページ(ブローカのGUI)およびDGMGRLと呼ばれるData Guardコマンドライン・インタフェースを使用すると、すべてのData Guard管理操作をローカルまたはリモートで実行できます。

ブローカのインタフェースによって利便性が向上し、Data Guard構成の管理と監視が集中管理されます。ブローカは、Oracle Database Enterprise EditionおよびPersonal Editionの機能として使用可能できるだけでなく、Oracle Database、Oracle Enterprise ManagerおよびOracle Cloud Control Planeとも統合されます。

ブローカのインストールおよび構成の例

ブローカのインストールおよび構成の例を次に示します。ブローカ構成ベスト・プラクティスのすべての例で使用されています。

前提条件:

  • プライマリ・データベース、スタンバイ・データベースおよびオブザーバは、障害分離を実現するために別々のサーバーおよびハードウェア上に存在すること。

  • プライマリ・データベースとスタンバイ・データベースの両方でSPFILEを使用していること。

  • DG_BROKER_START初期化パラメータをTRUEに設定していること。

  • 構成にOracle RACデータベースが含まれる場合は、そのデータベースのDG_BROKER_CONFIG_FILEn初期化パラメータを、そのデータベースの全インスタンスについて同じ共有ファイルを指すように設定する必要があります。共有ファイルには、クラスタ・ファイル・システム上のファイル(該当する場合)、RAWデバイス上のファイルまたは自動ストレージ管理を使用して格納されたファイルを使用できます。

  1. まだ存在しない場合は、プライマリ・データベースおよびスタンバイ・データベースに接続するOracle Net Services別名を作成します。これらの別名は、Data Guard構成の各ホストまたはメンバーのデータベース・ホームに存在する必要があります。Oracle RAC構成の場合、別名はSCAN名を使用して接続する必要があります。

    chicago =
 (DESCRIPTION =
  (ADDRESS_LIST =
    (ADDRESS=(PROTOCOL= TCP)
     (HOST=prmy-scan)(PORT=1521)))
 (CONNECT_DATA =
   (SERVER = DEDICATED)
    (SERVICE_NAME = chicago)))

boston =
 (DESCRIPTION =
  (ADDRESS_LIST =
    (ADDRESS=(PROTOCOL= TCP)
     (HOST=stby-scan)(PORT=1521)))
 (CONNECT_DATA =
   (SERVER = DEDICATED)
    (SERVICE_NAME = boston)))

  2. プライマリ・ホストで、DGMGRLに接続し、構成を作成します。

    $ dgmgrl sys
Enter password: password
DGMGRL> create configuration 'dg_config' as  primary database is 'chicago' connect identifier is chicago;
 
 Configuration "dg_config" created with primary database "chicago"
 
DGMGRL> add database 'boston' as connect identifier is boston;
 
 Database "boston" added
 
DGMGRL> enable configuration;
 Enabled.

  3. デフォルトでは、ブローカは最大パフォーマンス・データベース保護モードのためにLOG_ARCHIVE_DEST_nを設定します。

    ブローカは、次に示すように、非同期トランスポートのデフォルト値を使用してリモート・アーカイブ先を構成します。

    log_archive_dest_3=service="boston", ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 reopen=300 db_unique_name="boston" net_timeout=30, valid_for=(online_logfile,all_roles)
REDO転送モードの構成

LogXptModeプロパティを次のいずれかのモードに設定して、各構成メンバーでREDO転送サービスを構成します。

  • ASYNCは、このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのASYNC属性およびNOAFFIRM属性を使用して構成します。このモードをスタンバイREDOログ・ファイルとともに使用すると、パフォーマンスへの影響なしで数秒もかからない最小データ損失データ保護を実現します。
  • FASTSYNCは、このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNC属性およびNOAFFIRM属性を使用して構成します。最大可用性モード保護モードを使用している場合は、NOAFFIRM属性(デフォルト=AFFIRM)を指定した同期REDO転送モードを構成します。これは、スタンバイ・メモリー内でREDOが正常に受信および確認されたら、REDOがスタンバイREDOログに書き込まれる前にREDO受信を確認応答することで、同期REDO転送のパフォーマンスへの影響を最小限に抑えることができます。プライマリ・データベースのみで障害が発生した場合でも、データ損失ゼロの保護は保持されます。
  • SYNCは、このスタンバイ・データベースに対するREDO転送サービスを、LOG_ARCHIVE_DEST_n初期化パラメータのSYNC属性およびAFFIRM属性を使用して構成します。このモードとスタンバイREDOログ・ファイルは、最大保護モードまたは最大可用性モードのいずれかで動作している構成に必要です。このREDO転送サービスを使用すると、プライマリ・データベースへのデータ損失ゼロのデータ保護が可能になりますが、プライマリとスタンバイの間のラウンド・トリップ待機時間が長い場合には(2ミリ秒を超える場合など)、パフォーマンスへの影響も大きくなる可能性があります。このオプションは、最大保護モードでは必須です。

次の例に示すように、EDIT DATABASE SET PROPERTYコマンドを使用して、ブローカ構成の転送モードを設定します。

DGMGRL> EDIT DATABASE 'boston' SET PROPERTY LogXptMode=ASYNC;

DGMGRL> EDIT DATABASE 'chicago' SET PROPERTY LogXptMode=FASTSYNC;

DGMGRL> EDIT DATABASE 'SanFran' SET PROPERTY LogXptMode=SYNC;

ブローカ構成の検証

構成全体の問題を識別するには、次のステップを使用して検証します。

  1. SHOW CONFIGURATIONコマンドを使用して、ブローカ構成のステータスを表示します。 

    DGMGRL> show configuration;

 Configuration – dg

   Protection Mode: MaxPerformance
   Members:
   chicago - Primary database
   boston - Physical standby database 

 Fast-Start Failover: DISABLED

 Configuration Status:
 SUCCESS   (status updated 18 seconds ago)

    構成ステータスがSUCCESSの場合は、ブローカ構成全体が正常に動作しています。ただし、構成ステータスがWARNINGまたはERRORである場合は、構成の一部に問題があることを意味します。WARNINGステータスまたはERRORステータスに付随する追加のエラー・メッセージを使用して、問題を識別できます。次のステップでは、構成内の各データベースを調べて、特定のエラーに関連する内容を絞り込みます。

  2. プライマリ・データベースおよびスタンバイ・データベースに対する警告を識別するには、SHOW DATABASEコマンドを使用してステータスを表示します。 

    DGMGRL> show database chicago
 
 Database – chicago
 
   Role:               PRIMARY
   Intended State:     TRANSPORT-ON
   Instance(s):
     tin1
     tin2
 
 Database Status:
 SUCCESS

    データベース・ステータスがSUCCESSの場合、データベースは正常に動作しています。ただし、データベース・ステータスがWARNINGまたはERRORである場合は、データベースの一部に問題があることを意味します。WARNINGステータスまたはERRORステータスに付随する追加のエラー・メッセージを使用して、現在の問題を識別できます。

    スタンバイ・データベースでSHOW DATABASEコマンドを繰り返し、エラー・メッセージを評価します。

  3. Oracle Database 12.1以降でデータベースを検証します。

    Oracle Database 12.1以降の場合、Data Guard Brokerには前述のコマンドに加えてVALIDATE DATABASEコマンドもあります。 

    DGMGRL> validate database chicago

  Database Role:    Primary database
   Ready for Switchover:  Yes

DGMGRL> validate database boston;
 
   Database Role:     Physical standby database
   Primary Database:  tin
 
   Ready for Switchover:  No
   Ready for Failover:    Yes (Primary Running)
 
   Capacity Information:
     Database  Instances        Threads        
     tin       2                2              
     can       1                2              
     Warning: the target standby has fewer instances than the
     primary database, this may impact application performance
 
   Standby Apply-Related Information:
     Apply State:      Not Running
     Apply Lag:        Unknown
     Apply Delay:      0 minutes

    VALIDATE DATABASEコマンドは、SUCCESSステータスまたはWARNINGステータスを提供しないため、アクションを実行する必要があるかどうかを判断するための調査が必要になります。

ファスト・スタート・フェイルオーバーの構成

ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合、ブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。プライマリ・データベース、クラスタまたはサイトに障害が発生した場合に厳しいRTO要件を満たすためには、ファスト・スタート・フェイルオーバーを有効にする必要があります。

ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースがプライマリ・データベース・ロールに迅速かつ確実にフェイルオーバーされます。このとき、手動ステップを実行してフェイルオーバーを起動する必要はありません。ファスト・スタート・フェイルオーバーは、ブローカ構成でのみ使用できます。

プライマリ・データベースに複数のスタンバイ・データベースがある場合、FastStartFailoverTargetプロパティを使用して複数のファスト・スタート・フェイルオーバー・ターゲットを指定できます。このようなターゲットはターゲット候補と呼びます。ブローカは、FastStartFailoverTargetプロパティでの指定順に基づいて、ターゲットを選択します。指定されたファスト・スタート・フェイルオーバー・ターゲットに問題が発生し、フェイルオーバーのターゲットにできない場合、ブローカはファスト・スタート・フェイルオーバー・ターゲットを別のターゲット候補のいずれかに自動的に変更します。

ファスト・スタート・フェイルオーバーでは、任意の保護モードを使用できます。最大保護モードおよび最大可用性モードは、データが消失しないことを保証する自動フェイルオーバー環境を提供します。最大パフォーマンス・モードによる自動フェイルオーバー環境では、消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)以下であることが保証されます。このプロパティは、自動フェイルオーバーの実行に許容される最大消失データ量を示します。このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作している場合にのみ使用されます。

  1. 次の例に示すように、FastStartFailoverThresholdプロパティを設定することで、プライマリ・データベースを使用できないことが検出されてからフェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースが何秒待機するかを指定します。 

    DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = seconds;

    ファスト・スタート・フェイルオーバーが発生するのは、オブザーバとスタンバイ・データベースの両方が本番データベースとの接続を失ってからFastStartFailoverThresholdに設定されている値を超える期間が経過したときと、構成の状態が同期されていること(最大可用性)またはラグが構成済のFastStartFailoverLagLimitを超えないこと(最大パフォーマンス)に両者が同意したときです。

    FastStartFailoverThresholdの最適な値は、可能なかぎり迅速にフェイルオーバー(停止時間を最小化)することと、一時ネットワークの不規則性や可用性に影響しないその他の短期間のイベントが原因でフェイルオーバーが不必要にトリガーされることとのトレードオフを考慮して判断します。

    FastStartFailoverThresholdのデフォルト値は30秒です。

    次の表は、様々なユースケースにおけるFastStartFailoverThresholdの推奨設定を示しています。

    表14-1 FastStartFailoverThresholdの最小値の推奨設定

    構成 最小値の推奨設定

    単一インスタンスのプライマリ、短い待機時間、信頼性の高いネットワーク

    		 15秒

    単一インスタンスのプライマリ、WANを介した待機時間の長いネットワーク

    		 30秒

    Oracle RACのプライマリ

    Oracle RACミスカウント + 再構成時間 + 30秒

  2. トポロジ内でオブザーバを配置する場所を決定します。

    独自の可用性ドメイン(AD)またはデータ・センター内にあるプライマリ、スタンバイおよびオブザーバとともにファスト・スタート・フェイルオーバーをデプロイするのが理想的な状態ですが、2つの可用性ドメインまたは単一の可用性ドメインのみを使用する構成をサポートする必要があります。次に、オブザーバを配置する場合の推奨事項を2つのユースケースで示します。

    デプロイメント構成1: リージョンが2つで、それぞれのリージョンにADが2つあります。

    • 初期プライマリ・リージョンでは、プライマリ・データベースがAD1にあり、高可用性オブザーバが2つあります(1つ目のオブザーバはAD2に、2つ目のHAオブザーバはAD1にあります)
    • 初期スタンバイ・リージョンでは、スタンバイ・データベースがAD1にあり、ロール変更後に使用される高可用性オブザーバが2つあります(1つ目のオブザーバはAD2に、2つ目のHAオブザーバはAD1にあります)
    • オブザーバの場合、MAAでは少なくとも2つのオブザーバ・ターゲットを同じプライマリ・リージョンの異なるADに存在させることをお薦めします

    デプロイメント構成2: リージョンが2つで、それぞれのリージョンにADが1つのみあります

    • 初期プライマリ・リージョンには、プライマリ・データベースと、オブザーバをホストする2つの軽量サーバーがあります
    • 初期スタンバイ・リージョンには、スタンバイ・データベースと、オブザーバをホストする2つの軽量サーバーがあります(ロール変更がある場合)

  3. オブザーバ高可用性を構成します。

    1つのData Guard Broker構成を監視するには、最大で3つのオブザーバを登録できます。各オブザーバは、START OBSERVERコマンドの発行時に指定する名前で識別されます。オブザーバをバックグラウンド・プロセスとして起動することもできます。 

    DGMGRL> sys@boston
Enter password: password
DGMGRL> start observer number_one in background;

    高可用性のために追加のオブザーバを同じホストまたは別のホストで起動できます。

    DGMGRL> sys@boston
Enter password: password
DGMGRL> start observer number_two in background;

    Data Guard Brokerでファスト・スタート・フェイルオーバーを調整できるのはプライマリ・オブザーバのみです。他の登録済オブザーバはすべてバックアップ・オブザーバとみなされます。

    オブザーバをバックグラウンドに配置していない場合、オブザーバはSTART OBSERVERコマンドを発行したときに作成される継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVERコマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。

ファスト・スタート・フェイルオーバーを正しく構成したので、次の条件でフェイルオーバーをトリガーできます。

  • データベースに障害が発生してすべてのデータベース・インスタンスが停止している

  • I/Oエラーのためにデータ・ファイルがオフラインになっている

  • オブザーバとスタンバイ・データベースのどちらも本番データベースへのネットワーク接続を失っており、スタンバイ・データベースが同期状態にあることが確認される

  • ユーザー構成可能な条件

必要に応じて、ファスト・スタート・フェイルオーバーを起動できる次の条件を指定できます。これらのユーザー構成可能な条件はデフォルト値のままにし、自動フェイルオーバーを起動しないようにすることをお薦めします。

  • データ・ファイルがオフライン(書込みエラー)

  • ディクショナリが破損

  • 制御ファイルが破損

  • ログ・ファイルにアクセスできない

  • スタック・アーカイバ

  • ORA-240 (制御ファイル・エンキューのタイムアウト)

これらの条件のいずれかが検出されると、FastStartFailoverPmyShutdownの設定に関係なく、オブザーバがスタンバイにフェイルオーバーし、プライマリが停止します。ユーザー構成可能な条件の場合、ファスト・スタート・フェイルオーバーのしきい値は無視され、フェイルオーバーがすぐに続行されます。

複数のスタンバイ・データベースを使用するファスト・スタート・フェイルオーバー

FastStartFailoverTarget構成プロパティは、プロパティが設定されているデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバー状態にあるときにターゲット・データベースとして動作できる1つ以上のスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。このような指定可能なターゲット・データベースは、ファスト・スタート・フェイルオーバー・ターゲット候補と呼びます。

FastStartFailoverTarget構成プロパティには、フィジカル・スタンバイの名前のみを設定できます。スナップショット・スタンバイ・データベース、遠隔同期インスタンスまたはZero Data Loss Recovery Applianceの名前は設定できません。

フィジカル・スタンバイ・データベースが1つのみ存在している場合、ブローカはそのデータベースを、ファスト・スタート・フェイルオーバーが有効化されたときに、プライマリ・データベースのこのプロパティのデフォルト値として選択します。複数のフィジカル・スタンバイ・データベースが存在する場合、ブローカはプロパティ定義内の指定順に基づいて1つを選択します。ファスト・スタート・フェイルオーバーが有効化されると、ターゲットが検証されます

ログ・バッファの最適な設定

非同期REDO転送でOracle Data Guardを使用する場合、LOG_BUFFERを256MB以上に設定します。

そうすることで、非同期REDO転送では、ログ・バッファからREDOを読み取り、オンラインREDOログへのディスクI/Oを避けることができます。REDO生成率が非常に高いワークロード(たとえば、データベース・インスタンス当たり50MB/秒を超える)の場合、LOG_BUFFERは、使用されているプラットフォームに許可されている最大値まで増やすことができます。

ノート:

Linuxプラットフォームの最大LOG_BUFFER設定は2GBで、Windowsの最大設定は1GBです。

送信および受信バッファ・サイズの設定

REDO転送プロセス(特に受信/スタンバイ側)では、通常、待機時間が長いネットワーク・パスでTCPソケット・バッファを増やすことでメリットが得られます。TCPソケット・バッファは、TCPスタックによって動的に管理できます。

tcp_rmemおよびtcp_wmemの最大値を設定すると、カーネルは必要に応じてソケットに割り当てられたバッファを動的に変更できます。

帯域幅遅延積(BDP)は、チャネルのネットワーク・リンク容量とラウンド・タイム(待機時間)の積です。ソケット・バッファ・サイズの最小推奨値は、特に待機時間の長い高帯域幅ネットワークの場合、3*BDPです。oratcptestを使用してソケット・バッファ・サイズをチューニングします。

rootとして、tcp_rmemおよびtcp_wmemの最大値を3*<帯域幅遅延積>に設定します。この例では、BDPは16MBです。これらのパラメータの他の2つの値は、システムに現在設定されているままにする必要があります。

# sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216';

# sysctl -w net.ipv4.tcp_wmem='4096 16384 16777216';

sysctlを使用してこれらの値を変更すると、メモリー内でのみ動的に変更され、システムの再起動時に失われます。さらに、Linuxシステムではこれらの値を/etc/sysctl.confに設定します。ファイルに値がない場合は、これらのエントリを追加します。

net.ipv4.tcp_rmem='4096 87380 16777216'

net.ipv4.tcp_wmem='4096 16384 16777216'

同期トランスポートの場合にのみSDUサイズを65535に設定

Oracle Net Servicesでは、セッション・データ・ユニット(SDU)のサイズを調整してデータ転送を制御できます。オラクル社でのテストでは、SDUパラメータを最大値の65535に設定すると、同期トランスポートのパフォーマンスが向上しました。

SDUは、ローカル・ネーミング構成ファイル(tnsnames.ora)およびリスナー構成ファイル(listener.ora)のSDUパラメータを使用して接続単位ごとに設定するか、sqlnet.oraファイルのDEFAULT_SDU_SIZEプロファイル・パラメータですべてのOracle Net Services接続を対象に設定します。

オンラインREDOログの適切な構成

REDOログ・スイッチは、REDOの転送と適用のパフォーマンスに大きく影響します。プライマリ・データベースおよびスタンバイ・データベースのオンラインREDOログのサイズを設定するには、次のベスト・プラクティスに従います。

オンラインREDOログについては、次のガイドラインに従います。

  • すべてのオンラインREDOログ・グループは、同じサイズのログ(バイト)を持つ必要があります。

  • オンラインREDOログは、高パフォーマンスのディスク(DATAディスク・グループ)に存在する必要があります。

  • Oracle RACインスタンスでREDOのスレッドごとに3つ以上のオンラインREDOログ・グループを作成します。

  • Oracle RAC環境の共有ディスクにオンラインREDOログ・グループを作成します。

  • 高冗長性ディスク・グループに配置されていないかぎり、オンラインREDOログを多重化します(ログ・グループごとに複数のメンバー)。

  • ログ・スイッチが1時間に12回(5分ごと)以下になるようにオンラインREDOログのサイズを設定します。ほとんどの場合、ピーク時のワークロードであっても、15分から20分ごとのログ・スイッチが最適です。
REDOログ・サイズの設定

プライマリ・データベースのピークREDO生成率に基づいてREDOログ・サイズを設定します。

最大速度を確認するには、最大ワークロードを含む期間に次の問合せを実行します。最大速度は、月末、四半期末または年次で確認できます。REDO適用をこれらのワークロード中に一貫して実行するためには、最大速度を処理するようにREDOログ・サイズを設定します。

SQL> SELECT thread#,sequence#,blocks*block_size/1024/1024 MB,(next_time-first_time)*86400 sec,
 blocks*block_size/1024/1024)/((next_time-first_time)*86400) "MB/s"
 FROM v$archived_log WHERE ((next_time-first_time)*86400<>0) and first_time
 between to_date('2015/01/15 08:00:00','YYYY/MM/DD HH24:MI:SS')
 and to_date('2015/01/15 11:00:00','YYYY/MM/DD HH24:MI:SS') and dest_id=1 order by first_time;

   THREAD#  SEQUENCE#         MB        SEC       MB/s 
---------- ---------- ---------- ---------- ---------- 
         2       2291 29366.1963        831  35.338383 
         1       2565 29365.6553        781 37.6000708 
         2       2292 29359.3403        537  54.672887 
         1       2566 29407.8296        813 36.1719921 
         2       2293 29389.7012        678 43.3476418 
         2       2294 29325.2217       1236 23.7259075 
         1       2567 11407.3379       2658 4.29169973 
         2       2295 29452.4648        477 61.7452093 
         2       2296 29359.4458        954 30.7751004 
         2       2297 29311.3638        586 50.0193921 
         1       2568 3867.44092       5510 .701894903

次のチャートを使用して、ピーク生成率に基づいてREDOログ・サイズを選択します。

表14-2 推奨REDOログ・サイズ

ピークREDO率 推奨REDOログ・サイズ
<= 1 MB/s 1 GB
<= 5 MB/s 4 GB
<= 25 MB/s 16 GB
<= 50 MB/s 32 GB
> 50 MB/s 64 GB

スタンバイREDOログ・グループの使用

可用性およびパフォーマンスを向上させるために、すべてのプライマリ・データベースおよびスタンバイ・データベースでスタンバイREDOログ・グループを構成します。

REDOログ・スレッドごとに、スレッドがOracle RACデータベース・インスタンスに関連付けられます。スタンバイREDOログ・グループの数は、オンラインREDOログ・グループの数以上(>=)である必要があります。

スタンバイREDOログ・グループを作成する際には、次の追加のガイドラインを考慮してください。

  • すべてのオンラインREDOログとスタンバイREDOログ・グループは、同じサイズのログ(バイト)を持つ必要があります。スタンバイREDOログは、オンラインREDOログと同じサイズでない場合には使用されません。

  • すべてのスタンバイREDOログ・グループは、プライマリ・データベースとスタンバイ・データベースの両方で同じサイズのログ(バイト)を持つ必要があります。

  • スタンバイREDOログは、高パフォーマンスのディスク(DATAディスク・グループ)に存在する必要があります。

  • スタンバイREDOログは、高冗長性ディスク・グループに配置されていないかぎり、多重化する必要があります(ログ・グループごとに複数のメンバー)。Data Guardは欠落しているREDOをフェッチできるため、いずれの場合もスタンバイREDOログの多重化はオプションです。

  • Oracle RAC環境では、スタンバイREDOログは共有ディスクに作成します。

  • Oracle RAC環境では、各スタンバイREDOログ・グループにスレッドを割り当てます。

次の例では、REDOスレッドごとに3つのログ・グループを作成します。 

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 7 ('+DATA') SIZE 4194304000, GROUP 8 ('+DATA') SIZE 4194304000, GROUP 9 ('+DATA') SIZE 4194304000; 

SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 10 ('+DATA') SIZE 4194304000, GROUP 11 ('+DATA') SIZE 4194304000, GROUP 12 ('+DATA') SIZE 419430400

オンラインREDOログのスレッド数およびグループ番号を確認するには、次のようにV$LOGビューを問い合せます。 

SQL> SELECT * FROM V$LOG;

ALTER DATABASE ADD STANDBY LOGFILE THREAD文の結果を確認するには、次のようにV$STANDBY_LOGビューを問い合せます。 

SQL> SELECT * FROM V$STANDBY_LOG;

データ破損の防止

Oracle Databaseの破損の防止、検出および修復の機能は、保護対象のデータおよびトランザクションの内部知識と、包括的な高可用性ソリューションのインテリジェント統合を基に構築されています。

データ破損が検出されると、Oracle Data Guard、ブロック・メディア・リカバリおよびデータ・ファイル・メディア・リカバリでデータをリカバリできます。人為的エラーまたはアプリケーション・エラーで引き起こされたデータベース全体の論理破損は、Oracle Flashbackテクノロジによって元に戻すことができます。

ツールは論理データ構造の予防的検証にも使用できます。たとえば、SQL*Plus ANALYZE TABLE文はブロック間の破損を検出します。

これらのベスト・プラクティスを使用して、最も包括的なデータ破損防止および検出を実現します。

  • ブロック破損の拡大を防止するには、フィジカル・スタンバイ・データベースでOracle Data Guardを使用します。Oracle Data GuardはOracleデータをデータ損失および破損、書込みの欠落から保護する最適なソリューションです。

  • 次の表に示すように、Data Guardプライマリ・データベースおよびスタンバイ・データベースでOracle Databaseブロック破損初期化パラメータを設定します。

    表14-3 ブロック破損初期化パラメータの設定

    プライマリ・データベース上の設定... スタンバイ・データベース上の設定...

    DB_BLOCK_CHECKSUM=MEDIUMまたはFULL

    DB_LOST_WRITE_PROTECT=TYPICAL

    DB_BLOCK_CHECKING=FALSE*

    DB_BLOCK_CHECKSUM=MEDIUMまたはFULL

    DB_LOST_WRITE_PROTECT=TYPICAL

    DB_BLOCK_CHECKING=MEDIUMまたはFULL

    * PRIMARYでDB_BLOCK_CHECKINGをMEDIUMまたはFULLに設定することをお薦めしますが、アプリケーションでパフォーマンスを完全に評価した後にのみ設定してください。

  • パフォーマンス・オーバーヘッドはブロック変更ごとに発生するため、パフォーマンス・テストはDB_BLOCK_CHECKINGパラメータの設定時に特に重要です。プライマリ・データベースまたはスタンバイ・データベースのいずれかで、DB_BLOCK_CHECKING=MEDIUMを最小の設定(索引ブロックではなくデータ・ブロック上のブロック・チェック)にすることを強くお薦めします。DB_BLOCK_CHECKINGをMEDIUMまたはFULLにすることを有効化するパフォーマンス・オーバーヘッドがプライマリ・データベースで許容されない場合、スタンバイ・データベースでDB_BLOCK_CHECKINGをMEDIUMまたはFULLに設定します。

次の推奨事項も、データ破損からの保護に役立ちます。

  • ディスク障害からの保護にディスクのミラー化を提供する場合は、Oracle Automatic Storage Management (Oracle ASM)を使用します。

  • 最適な破損の修復にはOracle ASM HIGH REDUNDANCYを使用します。ディスク・グループでOracle ASM冗長性を使用すると、I/Oエラーまたは破損の発生時にミラー・エクステントをデータベースで使用できます。継続的な保護を目的として、Oracle ASMの冗長性により、I/Oエラーの発生時にエクステントをディスク上の別の領域に移動する機能が提供されます。Oracle ASMによる冗長性メカニズムは、メディア・エラーを戻す不良セクターがある場合に役立ちます。

  • (ほとんどの場合、人為的エラーによって引き起こされた)論理破損からの高速ポイント・イン・タイム・リカバリと、フェイルオーバー後のプライマリ・データベースの高速復元には、Oracle Flashbackテクノロジを有効化します。

  • バックアップおよびリストア操作中の追加的なブロック・チェックには、RMANを使用します。Recovery Manager (RMAN)によるバックアップおよびリカバリ計画を実装し、RMANのBACKUP VALIDATE CHECK LOGICALスキャンを定期的に使用して破損を検出します。

  • 破損のチェックと修復、中央バックアップ検証、本番データベースへの影響の縮小、Enterprise Cloudバックアップおよびリカバリ・ソリューションを含め、バックアップおよびリカバリの検証にはZero Data Loss Recovery Applianceを使用します。

フェイルオーバー後の復元のためのフラッシュバック・データベースの使用

プライマリ・データベースとスタンバイ・データベースの両方でフラッシュバック・データベースを有効化すると、元のプライマリ・データベースが損害を受けていなかった場合に、フェイルオーバー後に元のプライマリ・データベースを新しいスタンバイ・データベースとして復元できます。

フラッシュバック・データベースが有効であれば、スイッチオーバー・プロセスで障害が発生した場合でも、そのプロセスを簡単に元に戻すことができます。

スタンバイ・データベースでは、DB_FLASHBACK_RETENTION_TARGETをプライマリと同じ値に設定します。DB_FLASHBACK_RETENTION_TARGET初期化パラメータを、次のいずれかの適用される条件で指定されている最大値に設定します。

  • Data Guardフェイルオーバー後にフラッシュバック・データベースを利用して障害が発生したプライマリ・データベースを復元するには、ほとんどの場合、DB_FLASHBACK_RETENTION_TARGETを120 (分)以上に設定して、障害が発生したプライマリの復元を有効化します。
  • ユーザー・エラーまたは論理破損からの高速ポイント・イン・タイム・リカバリにフラッシュバック・データベースを使用中の場合、DB_FLASHBACK_RETENTION_TARGETを、データベースのリカバリを行う先の過去の最も遠い時間と等しい値に設定します。論理破損を24時間以内に検出して修復できる場合は、DB_FLASHBACK_RETENTION_TARGETを1440 (分)以上に設定します。

強制ロギング・モードの使用

プライマリ・データベースをFORCE LOGGINGモードで運用すると、データベースのすべてのデータ変更がログに記録されます。FORCE LOGGINGモードにより、スタンバイ・データベースとプライマリ・データベースとの一貫性が維持されます。

NOLOGGING操作でロード・パフォーマンスが必要なためにこのモードを使用できない場合は、適切なロギング・モードの有効化でその他のオプションを参照してください。

ALTER DATABASE FORCE LOGGING文を発行すると、強制ロギングを即座に有効化できます。FORCE LOGGINGを指定した場合、Oracleはログに記録されていない進行中のすべての操作が終了するまで待機します。

バインドされたRTOおよびRPOへのファスト・スタート・フェイルオーバーの構成(MAA Gold要件)

プライマリ・データベース、クラスタまたはサイトに障害が発生した場合に厳しいRTO要件を満たすためには、ファスト・スタート・フェイルオーバーを有効にする必要があります。Data Guardのファスト・スタート・フェイルオーバーでは、Data Guardオブザーバが2つのクォーラムを提供し、データベースの一貫性を維持し、データベースのスプリット・ブレインを防止します。

ファスト・スタート・フェイルオーバーでは、プライマリ・データベースが消失した場合にData Guardブローカにより、事前に選択されたスタンバイ・データベースに自動的にフェイルオーバーできます。ファスト・スタート・フェイルオーバーでは、ターゲット・スタンバイ・データベースが迅速かつ確実に、プライマリ・データベース・ロールに切り替えられます。このとき、手動ステップを実行してフェイルオーバーを起動する必要はありません。ファスト・スタート・フェイルオーバーは、Data Guardブローカ構成でのみ使用できます。

プライマリ・データベースに複数のスタンバイ・データベースがある場合、FastStartFailoverTargetプロパティを使用して複数のファスト・スタート・フェイルオーバー・ターゲットを指定できます。このようなターゲットはターゲット候補と呼びます。ブローカは、FastStartFailoverTargetプロパティでの指定順に基づいて、ターゲットを選択します。指定されたファスト・スタート・フェイルオーバー・ターゲットに問題が発生し、フェイルオーバーのターゲットにできない場合、ブローカはファスト・スタート・フェイルオーバー・ターゲットを別のターゲット候補のいずれかに自動的に変更します。

ファスト・スタート・フェイルオーバーでは、任意のData Guard保護モードを使用できます。最大保護モードおよび最大可用性モードは、データが消失しないことを保証する自動フェイルオーバー環境を提供します。最大パフォーマンス・モードによる自動フェイルオーバー環境では、消失データがFastStartFailoverLagLimit構成プロパティで指定したデータ量(秒単位)以下であることが保証されます。このプロパティは、自動フェイルオーバーの実行に許容される最大消失データ量を示します。このプロパティは、ファスト・スタート・フェイルオーバーが有効化され、構成が最大パフォーマンス・モードで動作している場合にのみ使用されます。

  1. 次の例に示すように、FastStartFailoverThresholdプロパティを設定することで、プライマリ・データベースを使用できないことが検出されてからフェイルオーバーを開始するまでにオブザーバおよびターゲット・スタンバイ・データベースが何秒待機するかを指定します。
    DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = seconds;

    ファスト・スタート・フェイルオーバーが発生するのは、オブザーバとスタンバイ・データベースの両方が本番データベースとの接続を失ってからFastStartFailoverThresholdに設定されている値を超える期間が経過したときと、構成の状態が同期されていること(最大可用性モード)またはラグが構成済のFastStartFailoverLagLimitを超えないこと(最大パフォーマンス・モード)に両者が同意したときです。

    FastStartFailoverThresholdの最適な値は、可能なかぎり迅速にフェイルオーバー(停止時間を最小化)することと、一時ネットワークの不規則性や可用性に影響しないその他の短期間のイベントが原因でフェイルオーバーが不必要にトリガーされることとのトレードオフを考慮して判断します。

    FastStartFailoverThresholdのデフォルト値は30秒です。

    次の表は、様々なユースケースにおけるFastStartFailoverThresholdの推奨設定を示しています。

    構成 最小値の推奨設定

    単一インスタンスのプライマリ、短い待機時間、信頼性の高いネットワーク

    15秒

    単一インスタンスのプライマリ、WANを介した待機時間の長いネットワーク

    30秒

    Oracle RACのプライマリ

    Oracle RACミスカウント + 再構成時間 + 30秒

    Exadataシステムの場合、最小設定は30秒
  2. トポロジ内でオブザーバを配置する場所を決定します。

    Data Guard Brokerオブザーバは2つのクォーラムを提供し、データベースの一貫性を維持し、スプリット・ブレインを防止します。Data Guardファスト・スタート・フェイルオーバーでは、常に1つのプライマリ・データベースのみが存在することが保証され、トランザクションをプライマリ・データベースにルーティングすることで外部の一貫性が保証されます。独自の可用性ドメイン(AD)またはデータ・センター内にあるプライマリ、スタンバイおよびオブザーバとともにファスト・スタート・フェイルオーバーをデプロイするのが理想的な状態ですが、2つの可用性ドメインまたは単一の可用性ドメインのみを使用する構成をサポートする必要があります。次に、オブザーバを配置する場合の推奨事項を2つのユースケースで示します。

    • デプロイメント構成1: リージョンが2つで、それぞれのリージョンにADが2つあります。

      • 初期プライマリ・リージョンでは、プライマリ・データベースがAD1にあり、高可用性オブザーバが2つあります(1つ目のオブザーバはAD2に、2つ目のHAオブザーバはAD1にあります)
      • 初期スタンバイ・リージョンでは、スタンバイ・データベースがAD1にあり、ロール変更後に使用される高可用性オブザーバが2つあります(1つ目のオブザーバはAD2に、2つ目のHAオブザーバはAD1にあります)
      • オブザーバの場合、MAAでは少なくとも2つのオブザーバ・ターゲットを同じプライマリ・リージョンの異なるADに存在させることをお薦めします

    • デプロイメント構成2: リージョンが2つで、それぞれのリージョンにADが1つのみあります

      • 初期プライマリ・リージョンには、プライマリ・データベースと、オブザーバをホストする2つの軽量サーバーがあります
      • 初期スタンバイ・リージョンには、スタンバイ・データベースと、オブザーバをホストする2つの軽量サーバーがあります(ロール変更がある場合)
  3. オブザーバ高可用性を構成します。

    1つのData Guard Broker構成を監視するには、最大で3つのオブザーバを登録できます。各オブザーバは、START OBSERVERコマンドの発行時に指定する名前で識別されます。オブザーバをバックグラウンド・プロセスとして起動することもできます。 

    DGMGRL> sys@boston
Enter password: 
DGMGRL> start observer number_one in background;

    高可用性のために追加のオブザーバを同じホストまたは別のホストで起動できます。

    DGMGRL> sys@boston
Enter password: 
DGMGRL> start observer number_two in background;

    Data Guard Brokerでファスト・スタート・フェイルオーバーを調整できるのはプライマリ・オブザーバのみです。他の登録済オブザーバはすべてバックアップ・オブザーバとみなされます。

    オブザーバをバックグラウンドに配置していない場合、オブザーバはSTART OBSERVERコマンドを発行したときに作成されて継続的に実行されるプロセスです。そのため、別のDGMGRLセッションからSTOP OBSERVERコマンドを発行するまで、オブザーバ・コンピュータ上のコマンドライン・プロンプトは戻されません。コマンドを発行し、ブローカ構成と対話するには、別のDGMGRLクライアント・セッションにより接続する必要があります。

ファスト・スタート・フェイルオーバーのトリガー

ファスト・スタート・フェイルオーバーを正しく構成したので、次の条件でフェイルオーバーをトリガーできます。

  • データベースに障害が発生してすべてのデータベース・インスタンスが停止している
  • I/Oエラーのためデータ・ファイルがオフラインになっている
  • オブザーバとスタンバイ・データベースのどちらも本番データベースへのネットワーク接続を失っており、スタンバイ・データベースが同期状態にあることが確認される
  • ユーザー構成可能な条件

必要に応じて、ファスト・スタート・フェイルオーバーを起動できる次の条件を指定できます。これらのユーザー構成可能な条件はデフォルト値のままにし、自動フェイルオーバーを起動しないようにすることをお薦めします。

  • データファイルがオフライン(書込みエラー)
  • ディクショナリが破損
  • 破損した制御ファイル
  • アクセス不可能なログ・ファイル
  • スタック・アーカイバ
  • ORA-240 (制御ファイル・エンキューのタイムアウト)

これらの条件のいずれかが検出されると、FastStartFailoverPmyShutdownの設定に関係なく、オブザーバがスタンバイにフェイルオーバーし、プライマリが停止します。ユーザー構成可能な条件の場合、ファスト・スタート・フェイルオーバーのしきい値は無視され、フェイルオーバーがすぐに続行されます。

複数のスタンバイ・データベースを使用するファスト・スタート・フェイルオーバー

FastStartFailoverTarget構成プロパティは、プロパティが設定されているデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバー状態にあるときにターゲット・データベースとして動作できる1つ以上のスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。このような指定可能なターゲット・データベースは、ファスト・スタート・フェイルオーバー・ターゲット候補と呼びます。

FastStartFailoverTarget構成プロパティには、フィジカル・スタンバイの名前のみを設定できます。スナップショット・スタンバイ・データベース、遠隔同期インスタンスまたはZero Data Loss Recovery Applianceの名前は設定できません。

フィジカル・スタンバイ・データベースが1つのみ存在している場合、ブローカはそのデータベースを、ファスト・スタート・フェイルオーバーが有効化されたときに、プライマリ・データベースのこのプロパティのデフォルト値として選択します。複数のフィジカル・スタンバイ・データベースが存在する場合、ブローカはプロパティ定義内の指定順に基づいて1つを選択します。ファスト・スタート・フェイルオーバーが有効化されると、ターゲットが検証されます

スタンバイAWRの構成

Oracle Database 12c (12.2)以降、自動ワークロード・リポジトリ(AWR)のスナップショットはスタンバイ・データベースから取得できます。

スタンバイAWRは、Active Data Guardスタンバイ・データベースのリカバリおよびレポートのワークロードに関するパフォーマンスの問題を特定するための最適なツールです。

スタンバイAWRの構成と管理の詳細は、Active Data Guardスタンバイ・データベースでの自動ワークロード・リポジトリの管理を参照してください。

ノート:

Oracle Exadata Cloud Data Guardデプロイメントの場合、スタンバイAWRは、インスタンス化の一環として構成されます。

スタンバイAWRレポートを作成するには

  1. スタンバイ・データベースのAWR ID (NODE_ID)を特定します。 

    SQL> select NODE_ID,NODE_NAME from DBA_UMF_REGISTRATION;

  2. ターゲット・データベースのNODE_IDをDBIDとして使用してプライマリ・データベースからレポートを実行します。

    • インスタンス・レベルのレポート(たとえば、REDO適用のパフォーマンス・ボトルネックの評価)の場合は、awrrptiスクリプトを使用します。 

      SQL> ?/rdbms/admin/awrrpti

    • スタンバイに関するグローバルAWRレポート(たとえば、問合せパフォーマンスの評価)の場合は、awrgrptiスクリプトを使用します。 

      SQL> ?/rdbms/admin/awrgrpti

複数のスタンバイ・データベースの構成

複数のスタンバイ・データベースが含まれるOracle Data Guard構成には、ローカル・スタンバイ・データベースとリモート・スタンバイ・データベースの両方の利点があります。

ローカル・スタンバイ・データベースでは、データ損失ゼロのフェイルオーバーを実現し、アプリケーションの停止時間を数秒に短縮できます。リージョン障害が発生し、プライマリ・スタンバイ・システムとローカル・スタンバイ・システムにアクセスできなくなった場合、アプリケーションとデータベースはリモート・スタンバイにフェイルオーバーできます。複数スタンバイ構成の特徴および利点の詳細は、Gold: 複数のスタンバイ・データベースを参照してください。

複数のスタンバイ・データベースが含まれるOracle Data Guard構成の管理

Oracle Data Guard Brokerにより、Oracle Data Guard構成内の複数のデータベースにまたがる管理タスクおよび運用タスクが自動化されます。また、ブローカにより、単一のOracle Data Guard構成内のすべてのシステムが監視されます。

マルチメンバーData Guard構成では、次のREDO転送先がサポートされています。

  • Oracle Data Guardスタンバイ・データベース
  • 遠隔同期インスタンス(詳細は、遠隔同期インスタンスの使用を参照)
  • Oracle Streamsダウンストリーム取得データベース
  • Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)

複数のスタンバイ・データベースとREDOルート

Oracle Data Guard BrokerのRedoRoutesプロパティを使用すると、デフォルトの動作(プライマリ・データベースが生成したREDOを構成内にある他のすべてのREDO転送先に送信する)をオーバーライドできます。

デフォルト以外のREDO転送トポロジの例として、フィジカル・スタンバイまたは遠隔同期インスタンスが、プライマリ・データベースから受け取ったREDOを1つ以上の宛先に転送するものや、指定された宛先に対して使用されるREDO転送モードが、どのデータベースがプライマリ・ロールであるかによって異なるものがあります。

プライマリ・データベース(North_Sales)と2つのフィジカル・スタンバイ・データベース(Local_SalesとRemote_Sales)がある構成を考えます。Local_Salesデータベースは、高可用性とより単純なアプリケーションおよびデータベースのフェイルオーバーのために、プライマリと同じデータ・センターに置かれています。Remote_Salesデータベースは、障害回復目的で、リモート・データセンターに置かれています。

North_Salesから両方のデータベースにREDOを送信するのではなく、RedoRoutesブローカ・プロパティを使用して、ローカルのフィジカル・スタンバイ・データベースが、North_Salesから受け取ったREDOをRemote_Salesに転送するように、リアルタイム・カスケーディングを構成することができます。そのためには、North_SalesおよびLocal_SalesでRedoRoutesプロパティを次のように設定します。

  • North_Salesデータベースでは、North_Salesがプライマリ・ロールである場合、同期転送モードを使用してLocal_SalesデータベースにREDOを送信するように、RedoRoutesプロパティを指定します。このルールにより、プライマリがRemote_Salesデータベースに直接REDOデータを送信することがなくなります。
  • Local_Salesデータベースでは、North_Salesがプライマリ・ロールの場合、Local_Salesが、North_Salesから受け取ったREDOをRemote_Salesに転送するように、RedoRoutesプロパティを指定する必要があります。

実行時のRedoRoutes構成を表示するには、SHOW CONFIGURATIONコマンドを使用します。たとえば: 

DGMGRL> SHOW CONFIGURATION;

Configuration - Sales_Configuration

  Protection Mode: MaxAvailability
  Members:
 North_Sales  - Primary database
    Local_Sales  - Physical standby database
      Remote_Sales  - Physical standby database (receiving current redo)

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

Remote_Sales宛先のREDOルート・ルールで、非同期REDO転送属性が明示的に指定されることで、その宛先へのREDOのリアルタイム・カスケーディングが有効にされたことに注意してください。(リアルタイム・カスケードにはOracle Active Data Guardオプションのライセンスが必要です。)

REDOのリアルタイム・カスケーディングを無効にするには、非同期REDO転送属性を指定しないでください。たとえば:
DGMGRL> EDIT DATABASE 'Local_Sales' SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales)';

詳細は、RedoRoutesを参照してください。

リモート代替宛先に対するRedoRoutesプロパティの使用

RedoRoutesプロパティを使用すると、REDOデータの受信元のメンバーに障害が発生しても端末メンバーがREDOデータを受信できるように、リモート代替宛先を設定することができます。

前述の例を使用すると、プライマリ・データベースとしてNorth_Salesを使用し、スタンバイ・データベースLocal_Salesに障害が発生した場合にREDOデータを直接Remote_Salesに送信できます。PRIORITY属性を使用して、Local_Salesの障害が解決された時点でRemote_SalesへのREDOの送信を再開できるように指定することもできます。 

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY
 'RedoRoutes' = '(LOCAL : ( Local_Sales ASYNC PRIORITY=1, Remote_Sales ASYNC PRIORITY=2 ))';
Property "RedoRoutes" updated

DGMGRL> EDIT DATABASE 'Local_Sales'
 SET PROPERTY 'RedoRoutes' = '(North_Sales : Remote_Sales ASYNC)';
Property "RedoRoutes" updated

DGMGRL> SHOW CONFIGURATION;

Configuration - Sales_Configuration

  Protection Mode: MaxPerformance
  Members:
  North_Sales    - Primary database
    Local_Sales  - Physical standby database
      Remote_Sales - Physical standby database
Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

RedoRoutes構成全部を表示するには、SHOW CONFIGURATION VERBOSEコマンドを使用します。たとえば: 

DGMGRL> SHOW CONFIGURATION VERBOSE;

Configuration - Sales_Configuration

  Protection Mode: MaxPerformance
  Members:
    North_Sales - Primary database
      Local_Sales - Physical standby database
        Remote_Sales - Physical standby database
      Remote_Sales - Physical standby database (alternate of Local_Sales)

  Properties:
    FastStartFailoverThreshold      = '180'
    OperationTimeout                = '30'
    TraceLevel                      = 'USER'
    FastStartFailoverLagLimit       = '300'
    CommunicationTimeout            = '180'
    ObserverReconnect               = '0'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
    ObserverOverride                = 'FALSE'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    ConfigurationWideServiceName    = 'c0_CFG'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

複数のスタンバイ・データベースを使用するファスト・スタート・フェイルオーバー

Oracle Data GuardのFastStartFailoverTargetブローカ構成プロパティは、プロパティが設定されているデータベースがプライマリ・データベースの場合、ファスト・スタート・フェイルオーバーのシナリオにおいてターゲット・データベースとして動作できる1つ以上のスタンバイ・データベースのDB_UNIQUE_NAMEを指定します。

このような指定可能なターゲット・データベースは、ファスト・スタート・フェイルオーバー・ターゲット候補と呼びます。FastStartFailoverTargetプロパティには、フィジカル・スタンバイの名前のみを設定できます。スナップショット・スタンバイ・データベース、遠隔同期インスタンスまたはZero Data Loss Recovery Applianceの名前は設定できません。

フィジカル・スタンバイ・データベースが1つのみ存在している場合、ファスト・スタート・フェイルオーバーが有効になっていると、ブローカはそのデータベースをプライマリ・データベースのFastStartFailoverTargetのデフォルト値として選択します。複数のフィジカル・スタンバイ・データベースが存在する場合、ブローカはプロパティ定義内の指定順に基づいてスタンバイを1つ選択します。ファスト・スタート・フェイルオーバーが有効になっていると、ターゲットは検証されます。

FastStartFailoverTargetも参照してください。

FastStartFailoverTargetの設定

2つ以上のスタンバイ・データベースがある場合、プライマリ・データベースのFastStartFailoverTarget構成プロパティを設定して目的のファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースを指定します。

ファスト・スタート・フェイルオーバーが実際に有効になると、Oracle Data Guard Brokerにより、今度は反対にターゲット・スタンバイ・データベースのこのプロパティが将来のターゲット・スタンバイ・データベースとしてプライマリ・データベースを指すように設定されます。このプロパティは自動的に設定されるため、ターゲット・スタンバイ・データベースでこのプロパティを設定する必要はありません。たとえば:

DGMGRL> edit database moe set property ='curly,larry';
Property "faststartfailovertarget" updated

FastStartFailoverTargetの構成後、ファスト・スタート・フェイルオーバーの有効化に進みます。ファスト・スタート・フェイルオーバーが有効になっていると、プライマリ・データベースまたはターゲット・スタンバイ・データベースのFastStartFailoverTarget構成プロパティは変更できません。

FastStartFailoverTargetプロパティを変更して別のスタンバイ・データベースを指すようにするには、ファスト・スタート・フェイルオーバーを無効化し、FastStartFailoverTargetプロパティを設定し、さらにファスト・スタート・フェイルオーバーを再有効化してください。このアクションは、プライマリ・データベースまたはスタンバイ・データベースの可用性や稼働時間には影響しません。

FastStartFailoverTargetを設定したスイッチオーバー

FastStartFailoverTargetを設定してファスト・スタート・フェイルオーバーが有効になっている場合でも、プライマリ・データベースのFastStartFailoverTargetデータベース・プロパティに指定されたのと同じスタンバイ・データベースがロール変更の対象となるかぎり、スイッチオーバーまたは手動フェイルオーバーを実行できます。

ファスト・スタート・フェイルオーバー・ターゲットではないスタンバイにスイッチオーバーしようとすると、ORA-16655が発生します。

DGMGRL> switchover to curly
Performing switchover NOW, please wait...
Error: ORA-16655: specified standby database not the current fast-start failover target standby

プライマリ・ファスト・スタート・ターゲットではないスタンバイにスイッチオーバーするには、次のようにします。

  1. ファスト・スタート・フェイルオーバーを無効にします。
    DGMGRL> DISABLE FAST_START FAILOVER;
  2. FastStartFailoverTargetプロパティを編集して、最初にスイッチオーバー先となるスタンバイをリストします。
    DGMGRL> edit database moe set property FastStartFailoverTarget='curly,larry';
Property "faststartfailovertarget" updated
  3. ファスト・スタート・フェイルオーバーを有効にします。
    DGMGRL> ENABLE FAST_START FAILOVER;
  4. スイッチオーバー操作を実行します。
    DGMGRL> switchover to curly
Performing switchover NOW, please wait...
ファスト・スタート・フェイルオーバーの停止処理

スタンバイ・データベースまたはインスタンスが停止しているか、REDOの転送に問題があるなどの理由で、プライマリ・データベースのファスト・スタート・フェイルオーバーのターゲット・スタンバイ・データベースが使用できなくなった場合、プライマリのファスト・スタート・フェイルオーバー・ターゲットはFastStartFailoverTargetプロパティで構成されている次のターゲットに自動的に切り替えられます。

ターゲット・スイッチを有効にするために、複数のpingサイクルが必要になる場合があります: 1つは現在のターゲットが有効でないことを認識するためのpingで、もう1つはターゲット・スイッチを提示してファイナライズするためのpingです。

元のファスト・スタート・フェイルオーバー・ターゲットがオンラインに戻っても、元のターゲットへの切替えは自動的には実行されません。停止後に元のターゲットに戻すには、ファスト・スタート・フェイルオーバーを無効にしてから有効にする必要があります。

Oracle Active Data Guard遠隔同期ソリューション

データ損失ゼロをサポートするために、プライマリ・データベースとスタンバイ・データベースの間にOracle Data Guard遠隔同期インスタンスをデプロイできます。これは、プライマリ・データベースからREDOを受け取り、そのREDOをOracle Data Guard構成の他のメンバーに送信するリモートのOracle Data Guardの宛先です。

遠隔同期について

遠隔同期は、データ損失ゼロの保護を実装する必要がある場合に、障害時リカバリ・サイトの場所の柔軟性を高めることができるOracle Active Data Guard機能です。

Oracle Data Guard同期トランスポートをすでにデプロイしているユーザーであっても、現在のスタンバイよりもプライマリに近い遠隔同期インスタンスを構成することで、本番データベースへのパフォーマンスの影響を軽減できます。

WANのディスタンスを超える、またはパフォーマンスが低いネットワークでの同期REDO転送では、プライマリ・データベースのパフォーマンスに対する影響が大きすぎてデータ損失ゼロの保護をサポートできないことがよくあります。Oracle Active Data Guard遠隔同期は、2つ目のスタンバイ・データベースまたは複雑な操作を必要とせずに、リモート・スタンバイ・データベースへのデータ損失ゼロのフェイルオーバーを実行する機能です。

遠隔同期を使用すると、同期REDO転送用のプライマリの許容範囲内である距離に遠隔同期インスタンス(軽量Oracleインスタンス)をデプロイすることで、これが可能になります。遠隔同期インスタンスでは、同期転送を使用してプライマリからREDOを受信し、非同期転送を使用して最大29個のリモート・スタンバイ・データベースにREDOを転送します。

遠隔同期インスタンスはOracle Active Data Guard遠隔同期機能の一部で、Oracle Active Data Guardのライセンスが必要です。

遠隔同期インスタンスへのオフロード

遠隔同期インスタンスは、リモート・スタンバイ・データベースで受信したREDOのギャップを解消するオーバーヘッドを(たとえば、ネットワークまたはスタンバイ・データベースの停止後に)プライマリからオフロードし、プライマリ・データベースのパフォーマンスに影響を与えずにREDO転送圧縮を実行してWAN帯域幅を節約できます。

REDO圧縮では、Advanced Compression Optionのライセンスが必要です。

さらに、REDO転送暗号化も遠隔同期インスタンスにオフロードできます。Advanced Security Option (ASO)を含め、MAAテスト時の暗号化は、プライマリのパフォーマンスにもスタンバイ・データベースの有効性にも影響しないことがわかっています。

Oracle NetおよびOracle Data Guardとテストおよび統合されているため、暗号化にはASOを使用することをお薦めします。

Oracle Advanced Security Optionはライセンス供与されたオプションです。

遠隔同期デプロイメント・トポロジ

Oracle Active Data Guard遠隔同期は、2つ目のスタンバイ・データベースまたは複雑な操作を必要とせずに、リモート・スタンバイ・データベースへのデータ損失ゼロのフェイルオーバーを実行する機能です。

Data Guardでこれを可能にするには、遠隔同期インスタンス(制御ファイル、SPFILE、パスワード・ファイルおよびスタンバイ・ログ・ファイルのみを含む軽量Oracleインスタンス。データベース・ファイルまたはオンラインREDOログはありません)を同期転送のプライマリの許容範囲内にある距離にデプロイします。遠隔同期インスタンスでは、同期転送を使用してプライマリからREDOを受信し、非同期転送を使用して最大29個のリモート・スタンバイ・データベースにREDOをすぐに転送します。遠隔同期インスタンスでは、REDOを新しいOracle Databaseバックアップ、ロギングおよびリカバリ・アプライアンスに転送することもできます。

図14-1 遠隔同期アーキテクチャの概要

前の段落で説明した一般的な遠隔同期設定

次のユースケースは、遠隔同期インスタンスで実装できる様々なアーキテクチャの選択肢の利点を示しています。

ケース1: ロール・トランジション後のデータ損失ゼロの保護

これは、プライマリ・データベースが高可用性遠隔同期インスタンスを使用して、データ損失ゼロのフェイルオーバーをリモート・スタンバイ・データベースに拡張する最も基本的な例です。

高可用性遠隔同期インスタンスは、サイト障害から分離するためにプライマリ・データベースとは別の場所にデプロイすることが理想的ですが、大都市地域の距離内(ネットワークRTT 5 ms以下、パフォーマンス・テストの対象)にします。別の場所を確保できない場合でも、遠隔同期インスタンスを同じデータ・センター内にデプロイすると、サイト全体の障害を除くすべてのリカバリ不能な停止に対して高速でデータ損失ゼロのフェイルオーバーを実現できるという利点があります。

スタンバイ・データベースがスタンバイ・ロールである間、リモート高可用性遠隔同期インスタンスはアイドル状態になります。これは、スタンバイ・データベースがプライマリ・データベース・ロールに遷移するとアクティブになって、新しいスタンバイ(古いプライマリ)へのデータ損失ゼロのフェイルオーバーが可能になります。元のプライマリ・データベースに対してローカルな高可用性遠隔同期インスタンスは、スタンバイ・ロールのときには非アクティブになります。

図14-2 遠隔同期によって容易になるロール・トランジション

遠隔同期では、前の段落で説明したように、ロール・トランジション中にデータ損失がゼロに保たれます

高可用性遠隔同期オプションの詳細は、「遠隔同期インスタンスの高可用性トポロジ」を参照してください。

ケース2: リーダー・ファーム・サポート

遠隔同期は、最大30のリモート宛先をサポートできるため、リーダー・ファームをサポートするための非常に便利なツールとなります。Active Data Guard構成では、複数のアクティブ・スタンバイ・データベースを設定して、読取りパフォーマンスを容易に拡張できます。

この例では、リーダー・ファームはプライマリ・データベースのリモートの場所に構成されます。プライマリはいったんWAN経由でリモート宛先にある遠隔同期インスタンスに送信され、遠隔同期はリーダー・ファーム内のすべてのアクティブ・スタンバイ・データベースにREDOをローカルに分散します。

図14-3 遠隔同期によるリーダー・ファームへのREDOの送信

プライマリ・データベースは、前述の段落で説明したように、遠隔同期インスタンスを介してREDOをリーダー・ファームに送信します
ケース3: 遠隔同期ハブを使用したクラウド・デプロイメント

遠隔同期は、非常に軽量なプロセスです。単一の物理サーバーで複数の遠隔同期インスタンスをサポートでき、各インスタンスがリモート宛先へのデータ損失ゼロのフェイルオーバーを実現します。

次の図では、プライマリ・データベースが単一の物理マシンに送信され、そのマシンは複数の遠隔同期インスタンスで構成された遠隔同期ハブとして動作しています。プライマリおよび遠隔同期ハブはオンプレミスですが、スタンバイ・データベースはクラウドにリモートでデプロイされています。

この構成のすべてのシステム(プライマリ・データベース・ホスト、スタンバイ・データベース・ホストおよび遠隔同期インスタンス・ホスト)は、Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration (Doc ID 413484.1)で説明されているように、Data Guard構成で互換性の確保に必要な通常の要件を満たしている必要があります。

図14-4 遠隔同期ハブのアーキテクチャ

遠隔同期は、プライマリ・データベースのグループとクラウドとの間のシステムとして表示されます
遠隔同期高可用性トポロジ

遠隔同期インスタンスの可用性を高く保つには、次のデプロイメント・トポロジを考慮してください。

Oracle Real Application Clustersでの遠隔同期インスタンスのデプロイ

遠隔同期インスタンスは、Oracle RACクラスタに配置できます。この構成では、遠隔同期インスタンスは一度に1つのサーバーでのみアクティブになり、他のサーバーは高可用性のための自動フェイルオーバーを提供します。この方法の特徴は次のとおりです。

  • アクティブな遠隔同期インスタンスまたはノードに障害が発生した場合、データ損失の可能性が最も低く、ブラウンアウトします。

  • 遠隔同期インスタンス障害後、データ損失ゼロの保護を短時間で再開できます。

  • このソリューション単独で、クラスタ障害には対処しません。

最重要アプリケーションには、互いの代替として構成されて異なる場所にデプロイされたOracle RAC遠隔同期インスタンスのペアが適しています。これにより、(インスタンス、ノード、クラスタおよびサイトの停止中に)最も堅牢なHAおよびデータ保護を実現できます。

代替宛先および複数の遠隔同期インスタンスでの遠隔同期インスタンスのデプロイ

2つの別個の遠隔同期インスタンスを異なる物理マシンで構成し、それぞれが他方の代替宛先として機能して、非Oracle RAC環境での遠隔同期インスタンスの高可用性を実現します。プライマリ・データベースで定義された各宛先にはALTERNATEキーワードが含まれ、他方の遠隔同期インスタンスを代替として割り当てています。アクティブな遠隔同期インスタンスがエラー状態に入ると、代替遠隔同期インスタンスを指している代替宛先は自動で有効になります。遠隔同期インスタンスを代替宛先として定義することで、一時的に再同期化状態に落ちながら新しい宛先が用意されると、最大可用性保護が維持されます。

この方法の特徴は次のとおりです。

  • 遠隔同期インスタンス転送障害(インスタンスまたはネットワークの停止)後、データ損失ゼロの適用範囲が維持されます。

  • 障害テストから、次のことがわかっています。

    • 遠隔同期インスタンス障害時、SYNC REDO転送が開始する間、約3.5秒のパフォーマンス・ブラウンアウトが発生しました(ネットワーク同期サービス - NSS)。

    • ネットワーク障害時、宛先のnet_timeoutパラメータの設定と等しい短時間のブラウンアウトが認められました。

  • マシンの停止に対するHAでは、各遠隔同期インスタンスが別個のハードウェア上にあることを前提としています。

  • サイトの停止に対するHAでは、遠隔同期インスタンスが別個のサイトにデプロイされることを前提としています。

  • 遠隔同期インスタンスの停止中のアプリケーション・ブラウンアウトおよび再同期化時間がOracle RACによる遠隔同期と比較して長くなります

ターミナル・スタンバイでの遠隔同期インスタンスの代替宛先としてのデプロイ

遠隔同期インスタンスの停止中にデータ保護を維持する最も簡単な方法は、ターミナル・スタンバイを直接指す代替LOG_ARCHIVE_DEST_n (端末フェイルオーバー・ターゲット)を作成することです。WANネットワーク待機時間が原因でプライマリのパフォーマンスに影響が及ばないようにするには、リモート宛先への非同期トランスポートが最も有力な選択肢です。

非同期トランスポートではゼロに近いデータ損失保護を実現できますが(公開までに1秒もかかりません)、スタンバイ確認応答を待機しないため、データ損失ゼロは保証できません。この構成では、遷移を実行するためにレベルはターゲットに対して強制力がある必要があるため、スイッチオーバー(計画済のイベント)の前に保護レベルを最大パフォーマンスに落とす必要があります。保護レベルおよび転送方法の変更は、停止時間を必要としない動的操作です。

遠隔同期インスタンスの停止中に、REDO転送は代替宛先を使用して自動的にフェイルオーバーします。遠隔同期インスタンスが修復されて操作が再開されると、トランスポートは自動的に遠隔同期インスタンスに切り替わり、データ損失ゼロの保護がリストアされます。

この方法の特徴は次のとおりです。

  • 管理対象となる追加ハードウェアまたは遠隔同期インスタンスはありません。

  • 遠隔同期インスタンスの停止中、データ損失ゼロの適用範囲が失われます。遠隔同期インスタンスが動作を再開し、スタンバイが完全に同期されるまで、データ保護レベルがASYNC転送によるUNSYNCHRONIZEDに落ちます。

遠隔同期デプロイメント・トポロジの選択

REDOの送受信に関して、遠隔同期インスタンスの高可用性のための構成はすべて等しく機能します。構成は、最大データ損失(RPO)に対するアプリケーションの許容度および様々な障害シナリオでのアプリケーション・ブラウンアウト期間に基づいて選択する必要があります。

  • Oracle RACにデプロイされた遠隔同期インスタンスでは、ブラウンアウトが最小で保護が最適になりますが、クラスタまたはサイトの停止は対象に含まれません。最重要アプリケーションには、互いの代替として構成されて異なる場所にデプロイされたOracle RAC遠隔同期インスタンスのペアが適しています。最も堅牢な遠隔同期高可用性(インスタンス、ノード、クラスタおよびサイトの障害)の保護を実現できます。

  • RAC以外の環境で代替遠隔同期インスタンスを使用すると、各インスタンスを個別の物理データベース・サーバーに配置できます。この構成では、遠隔同期インスタンスを異なるサイトにデプロイすることで保護を実現します。データ保護が不可欠でも、コストが重要な考慮事項であるアプリケーションには、単一ノードの遠隔同期インスタンスのペアをそれぞれが他方の代替としてデプロイすることが最適です。しかし、一方の遠隔同期インスタンスから他方への転送の遷移中、アプリケーション・ブラウンアウトが若干増え、再同期時間が長くなります。転送が遠隔同期インスタンス間で遷移する際に、1秒の停止でもプライマリ・データベースに影響する場合には、データが損失する可能性があります。

  • ターミナル・スタンバイ代替構成では、遠隔同期インスタンスが使用できない間、データ損失ゼロの保護がないことをアプリケーションで許容する必要がありますが、追加ハードウェアの実装が不要です。遠隔同期インスタンスの停止中にデータ損失の可能性が高くなることを許容でき、低コストが主な考慮事項であるアプリケーションには、非同期REDO転送を使用してターミナル・スタンバイを代替場所として構成することが最適です。ターミナル・スタンバイを代替宛先として使用するには、遠隔同期インスタンスの停止を解決するために必要な期間中に構成が非同期モードで実行されることを受け入れる必要があります。このアプローチの利点は、追加のハードウェアまたはソフトウェアをデプロイまたは管理する必要がないことです。遠隔同期インスタンスの停止中にデータ損失の可能性が高くなることを許容でき、低コストが主な考慮事項であるアプリケーションには、ASYNC REDO転送を使用してターミナル・スタンバイを代替場所として構成することが最適です。

  • 遠隔同期ハブは、単一の物理ホスト上の複数のData Guard構成の遠隔同期インスタンスを効率的に統合する方法です。データ損失ゼロのサービス・レベル・カテゴリを含むクラウド・デプロイメントでは、遠隔同期ハブをデプロイして、単一の物理マシンまたはクラスタ上の複数のデータ損失ゼロ構成の遠隔同期インスタンスを効率的に統合できます

  • データ保護が不可欠でも、コストが重要な考慮事項であるアプリケーションには、単一ノードの遠隔同期インスタンスのペアをそれぞれが他方の代替としてデプロイすることが最適です。

遠隔同期構成のベスト・プラクティス

次に、同期REDO転送先に適用されるベスト・プラクティスに加えて必要な遠隔同期構成のベスト・プラクティスを示します。

  • プライマリ・データベースと遠隔同期インスタンスの間のネットワークでは次のことが必要です。

    • レスポンス時間およびプライマリ・データベースのスループットへの影響がビジネス要件を超えないように、ラウンド・トリップ待機時間を十分に低くします。影響の程度はアプリケーション固有であり、テストで検証する必要があります。通常、経験的には、ラウンド・トリップ待機時間が5ミリ秒未満である場合に成功する可能性が高くなることがわかっています。ただし、待機時間がこれよりも長くても成功するデプロイメントはあります。

    • ネットワークを共有する他のトラフィックに加えて、プライマリ・データベースと遠隔同期インスタンスとの間にピークREDOボリュームに対応するために十分な帯域幅を提供します。REDO転送圧縮を使用すると、ネットワーク帯域幅の要件を減らすことができます。

    • ネットワーク・コンポーネントの障害を許容する冗長なネットワーク・リンクを確保するのが理想的です。

  • 標準Oracle Data Guardネットワークのベストプラクティス(適切なTCP送受信バッファ・サイズを帯域幅遅延積の3倍に設定するなど)。オンラインREDOログの適切な構成を参照してください。

  • 遠隔同期インスタンスのスタンバイREDOログは十分なIOPS (書込み数/秒)能力を持つストレージに配置して、他のアクティビティからのIOPSに加えて、ピーク・アクティビティ時にプライマリ・データベースのLGWRプロセスのI/Oを超えても対応できるようにする必要があります。これは、重要な考慮事項です。たとえば:

    • 遠隔同期インスタンスにプライマリ・データベースよりもパフォーマンスが低いディスクがある場合、受信と同じ速度でREDOをリモート宛先に転送できず、アーカイブ・ログのギャップが生じることがあります。

    • REDOギャップ解消のシナリオの場合、たとえば、スタンバイでの計画メンテナンスまたはネットワークの停止のために、ピークREDOの頂点でギャップ解消用の追加I/Oリクエストが受信されます。

    • 遠隔同期インスタンスにあるパフォーマンスが低いディスクはプライマリ・データベースへの確認応答を遅らせるため、プライマリ・データベースとスタンバイ・データベースの間のラウンドトリップ時間が長くなり、アプリケーションのレスポンス時間に影響を及ぼします。この影響を解消するには、プライマリ・データベースと遠隔同期インスタンスとの間で遠隔同期を使用します。

  • 遠隔同期インスタンスは、スタンバイ・データベースと同じスタンバイREDOログのベスト・プラクティスに従う必要があります。オンラインREDOログの適切な構成を参照してください。

  • 代替遠隔同期がアクティブ化されたら同期転送に最速で戻るようにするには、代替遠隔同期インスタンスのスタンバイREDOログを手動でクリアしてから使用する必要があります。たとえば:

    ALTER DATABASE CLEAR LOGFILE GROUP 4, GROUP 5, GROUP 6;

  • Oracle MAAパフォーマンス・テストによって、小規模の遠隔同期インスタンスSGAは遠隔同期インスタンスやプライマリ・データベースのパフォーマンスに影響を及ぼさないことが示されています。システム・リソースを節約するために、遠隔同期の動作に必要な最小限のSGAを構成できます。

    • CPU_COUNT=4を設定します。圧縮も暗号化も使用しない場合には、値を1または2に設定できます。

    • テスト中にCPU_COUNTを削減しても、遠隔同期インスタンスのパフォーマンスには影響はありません。

  • ロール・トランジション後もデータ損失ゼロの保護を維持するには、プライマリ・データベースとスタンバイ・データベースの両方に対して遠隔同期インスタンスを構成します。スタンバイ・データベースに近接して構成された2つ目の遠隔同期インスタンスは、スタンバイがプライマリ・データベースになるまでアイドル状態であるため、逆方向の同期REDO転送が可能です。

    Data Guard Broker構成では、ターゲット・スタンバイ・サイトから保護モードを強制できないかぎり、最大可用性モードである間はスイッチオーバー(計画済のロール移行)を実行できません。スタンバイ・データベースに独自の遠隔同期インスタンスがない場合は、ロールを元に戻した後に元のプライマリ・データベースに非同期REDOを送信するように構成する必要があります。これにより、プライマリ・データベースの保護モードを最大可用性から最大パフォーマンスに初めて落とした場合を除いて、スイッチオーバーの実行が防止されます。

  • 遠隔同期では、ネットワーク待機時間および遠隔同期インスタンス・ハードウェアのI/O速度に応じて、同期転送と比較してプライマリ・データベースのパフォーマンスが4%から12%向上します。

  • CPU、I/Oおよびネットワークの所定の要件を満たします。

    • 遠隔同期インスタンスを仮想マシンに配置しても、物理ハードウェア構成のパフォーマンスは低下しません。

    • 複数のData Guard構成を処理している複数の遠隔同期インスタンスは、同じ物理サーバー、クラスタまたは仮想マシンを共有できます。

  • 遠隔同期サーバーでアーカイブを管理する必要がある場合があります。

Active Data Guardの遠隔同期アーキテクチャの構成

次の各トピックでは、Active Data Guardの遠隔同期アーキテクチャの構成例を示します。

遠隔同期インスタンスの構成

次の例は、遠隔同期インスタンスをOracle Data Guard Broker構成に追加する方法を示しています。

最初のステップでは、プライマリ・データベース・サーバーから独立している、または障害が分離されていて、アプリケーション・パフォーマンスで許容できるようにプライマリ・サーバーと遠隔同期サーバー間のネットワーク待機時間が一貫して低い(たとえば、5ミリ秒未満)遠隔同期スタンバイ・インスタンスを追加します。

次の例では、プライマリ・データベースNorth_Salesに対して遠隔同期インスタンスFS1が作成されます。

DGMGRL> ADD FAR_SYNC FS1 AS CONNECT IDENTIFIER IS FS1.example.com;
Far Sync FS1 added
DGMGRL> ENABLE FAR_SYNC FS1;
Enabled.
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

  Protection Mode: MaxPerformance
  Members:
  North_Sales  - Primary database
    FS1        - Far Sync
    South_Sales - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

遠隔同期インスタンスが構成に追加された後、最大可用性モードをサポートするようにREDO転送を設定してから、次の例に示すように保護モードをアップグレードします。

DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS1 SYNC)';
DGMGRL> EDIT FAR_SYNC 'FS1' SET PROPERTY 'RedoRoutes' = '(North_Sales : South_Sales ASYNC)';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

  Protection Mode: MaxAvailability
  Members:
  North_Sales  - Primary database
    FS1          - Far Sync
      South_Sales - Physical standby database
 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

スイッチオーバーまたはフェイルオーバー後に、リモート・スタンバイ・データベースSouth_Salesがプライマリ・データベースになった場合に最大可用性保護モードを保持できるようにするには、2番目の遠隔同期インスタンスを構成に追加して、South_SalesがREDOを同期モードで送信できるようにし、ロール・トランジション後に新しいターミナル・データベースNorth_SalesにREDOが送信されるようにします。

次の例は、ブローカ構成に2番目の遠隔同期インスタンス(FS2)を追加する方法を示しています。

DGMGRL> ADD FAR_SYNC FS2 AS CONNECT IDENTIFIER IS FS2.example.com;
Far Sync FS2 added
DGMGRL> EDIT FAR_SYNC 'FS2' SET PROPERTY 'RedoRoutes' = '(South_Sales : North_Sales ASYNC)';
DGMGRL> ENABLE FAR_SYNC FS2;
Enabled.
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'RedoRoutes' = '(LOCAL : FS2 SYNC)';
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

  Protection Mode: MaxAvailability
  Members:
  North_Sales  - Primary database
    FS1          - Far Sync
      South_Sales - Physical standby database
      FS2         - Far Sync (inactive)
 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
HA遠隔同期インスタンスの設定

代替HA遠隔同期インスタンスは、プライマリ・データベースおよびリモート・スタンバイ・データベース用に作成した遠隔同期インスタンスに高可用性を提供するために設定します。

次の例は、Oracle Data Guard Broker構成のプライマリ・データベースの遠隔同期インスタンス(FS1)に2つ目の遠隔同期インスタンス(FS1a)を追加して、プライマリ遠隔同期インスタンスが使用できなくなった場合にREDO転送で代替遠隔同期インスタンスが使用されるようにする方法を示しています。

DGMGRL> ADD FAR_SYNC FS1a AS CONNECT IDENTIFIER IS FS1a.example.com;
Far Sync FS1a added
DGMGRL> EDIT DATABASE 'North_Sales' SET PROPERTY 'RedoRoutes' = ' (LOCAL:(FS1 SYNC PRIORITY=1, FS1a SYNC PRIORITY=2))';
DGMGRL> EDIT FAR_SYNC 'FS1' SET PROPERTY 'RedoRoutes' = '(North_Sales : South_Sales ASYNC)';
DGMGRL> EDIT FAR_SYNC 'FS1a' SET PROPERTY 'RedoRoutes' = '(North_Sales : South_Sales ASYNC)';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

  Protection Mode: MaxAvailability
  Members:
  North_Sales  - Primary database
    FS1          - Far Sync
    FS1a          - Far Sync
      South_Sales - Physical standby database
 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

プライマリで代替遠隔同期インスタンスを追加した後、次の例を使用して、スタンバイで代替遠隔同期インスタンス(FS2a)を追加します。

DGMGRL> ADD FAR_SYNC FS2a AS CONNECT IDENTIFIER IS FS2a.example.com;
Far Sync FS2a added
DGMGRL> EDIT DATABASE 'South_Sales' SET PROPERTY 'RedoRoutes' = ' (LOCAL:(FS2 SYNC PRIORITY=1, FS2a SYNC PRIORITY=2))';
DGMGRL> EDIT FAR_SYNC 'FS2' SET PROPERTY 'RedoRoutes' = '(South_Sales : North_Sales ASYNC)';
DGMGRL> EDIT FAR_SYNC 'FS2a' SET PROPERTY 'RedoRoutes' = '(South_Sales : North_Sales ASYNC)';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MaxAvailability;
DGMGRL> SHOW CONFIGURATION;

Configuration - DRSolution

  Protection Mode: MaxAvailability
  Members:
    North_Sales - Primary database
      FS1 - Far Sync
      FS1a - Far Sync
        South_Sales - Physical standby database
          FS2 - Far Sync (inactive)
          FS2a - Far Sync (inactive)

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
Oracle RACまたはOracle Clusterwareによる遠隔同期インスタンスの構成

遠隔同期インスタンスが(たとえばOracle Restart、Oracle Real Application Clusters (Oracle RAC)またはOracle RAC One Nodeのインストールの)Oracle Clusterwareを使用してサーバーまたはクラスタにデプロイされる場合は、SRVCTLユーティリティを使用して、デフォルトのオープン・モードのマウントを指定します。

次のようなコマンドを使用できます。

srvctl modify database -d db_unique_name -startoption MOUNT

Data Guardおよび高速オフライン暗号化を使用したデータベースの暗号化

透過的データ暗号化(TDE)を使用したデータベースの暗号化は、スタンバイ・データベースとオフライン暗号化を使用して、停止時間を最小限に抑え、追加の領域要件なしで、より迅速に実行できます。

この2フェーズ・プロセスでは、スタンバイ・データベースはオフラインで暗号化され、その後スイッチオーバーが行われ、新しいスタンバイ・データベース(以前のプライマリ)でオフライン暗号化が繰り返されます。

最新のOracleリリースでは、オンライン暗号化も使用できます。オンライン暗号化は一部のユーザーには適していますが、表領域の変換中に追加のストレージが必要で、各ブロックが新しい暗号化データ・ファイルに読み書きされるため、オンライン暗号化は時間のかかるプロセスになる場合があります。高速オフライン暗号化では、マウントされたスタンバイ・データベースで各データ・ファイルが直接インプレースで暗号化されます。

ステップ1: 透過的データ暗号化(TDE)の構成

様々なTDE構成オプションがあります。Oracleリリースごとに要件が異なります。データベース・リリースの『Oracle Database Advanced Securityガイド』の透過的データ暗号化の概要を確認して、TDEの構成オプションおよび影響を理解することをお薦めします。

ノート:

このプロセスでは、統合ファイルベースのキーストアの構成について説明します。つまり、ウォレットはファイル・システムに格納され、すべてのPDBのすべてのキーは単一のウォレットに格納されます。

分離されたPDB、Oracle Key Vault (OKV)またはハードウェア・セキュリティ・モジュール(HSM)などのより複雑な構成の詳細は、『Oracle Database Advanced Securityガイド』の透過的データ暗号化の使用を参照してください。

次に、統合ファイルベースのキーストアを構成するために必要な基本パラメータを示します。パラメータはプライマリ・データベースとスタンバイ・データベースで構成されますが、値が異なる場合があります。

パラメータ 構成のベスト・プラクティス

WALLET_ROOT

Oracle Database 18c以降では、すべてのデータベース・ウォレットのルート・ディレクトリを指定するためのベスト・プラクティスは、WALLET_ROOTデータベース・パラメータの構成です。クラスタ化されたデータベースの場合、WALLET_ROOTで指定された場所は、ASMディスクなどの共有の場所である必要があります。 

ALTER SYSTEM SET
 WALLET_ROOT='+DATA/db_unique_name'
 SCOPE=SPFILE SID='*';

ノート:

WALLET_ROOTは静的パラメータです。変更を有効にするには、データベースを再起動する必要があります。TDE_CONFIGURATIONは、WALLET_ROOTを設定してデータベースを再起動するまで設定できません。

詳細は、『Oracle Databaseリファレンス』のWALLET_ROOTを参照してください。

TDE_CONFIGURATION

TDE_CONFIGURATIONデータベース・パラメータは、キーストアのタイプを設定します。

TDE_CONFIGURATIONは動的ですが、WALLET_ROOTを構成してデータベースを再起動した後にのみ設定できます。 

ALTER SYSTEM SET
 TDE_CONFIGURATION='KEYSTORE_CONFIGURATION=FILE'
 SCOPE=SPFILE SID='*';

詳細は、『Oracle Databaseリファレンス』のTDE_CONFIGURATIONを参照してください。

TABLESPACE_ENCRYPTION

データベース・パラメータTABLESPACE_ENCRYPTIONは、Oracle 19c (19.16)で使用できます。TABLESPACE_ENCRYPTIONは、ENCRYPT_NEW_TABLESPACESのかわりとなるもので、作成時に新しい表領域を暗号化するかどうかを指定します。TABLESPACE_ENCRYPTIONパラメータとENCRYPT_NEW_TABLESPACESパラメータの両方が設定されている場合、TABLESPACE_ENCRYPTIONが優先されます。

TABLESPACE_ENCRYPTIONの値は次のとおりです。

  • AUTO_ENABLE - 新しく作成されたすべての表領域が暗号化されます。これは、Oracle 19c (19.16)以降ではオーバーライドできないOracle Cloudのデフォルトです。
  • MANUAL_ENABLE - 表領域をCREATE文のENCRYPTION句で暗号化するかどうかを手動で制御します。
  • DECRYPT_ONLY - 表領域は暗号化されません。この設定はハイブリッドData Guard構成で使用され、ここではクラウド・データベースの暗号化中にオンプレミス・データベースが暗号化されないままになります。 
ALTER SYSTEM SET 
TABLESPACE_ENCRYPTION=MANUAL_ENABLE 
SCOPE=BOTH SID='*';

詳細は、『Oracle Databaseリファレンス』のTABLESPACE_ENCRYPTIONを参照してください。

ENCRYPT_NEW_TABLESPACES

Oracle Database 19c (19.16)より前のENCRYPT_NEW_TABLESPACESパラメータは、新しい表領域を暗号化するかどうかを指定します。

ENCRYPT_NEW_TABLESPACESの値は次のとおりです。

  • CLOUD_ONLY - 表領域がOracle Cloudで作成されると、暗号化句が含まれているかどうかに関係なく、デフォルトの暗号化アルゴリズムで透過的に暗号化されます。デフォルトの暗号化アルゴリズムはステップ2に示すように変更できますが、AES128がデフォルトのアルゴリズムです。
  • ALWAYS - 新しい表領域は、データベースがOracle Cloudにあるかどうかに関係なく透過的に暗号化されます。
  • DDL - 表領域をENCRYPTION句で暗号化するかどうかを手動で制御します。

詳細は、『Oracle Databaseリファレンス』のENCRYPT_NEW_TABLESPACESを参照してください。

次の表に、Oracle Databaseリリースに基づいて構成するTDEパラメータを示します。

Oracleリリース WALLET_ROOTおよびTDE_CONFIGURATION TABLESPACE_ENCRYPTION ENCRYPT_NEW_TABLESPACES
Oracle 19c (19.16)以降 あり あり なし
Oracle 18cから19c (19.15) あり なし あり

ステップ2: デフォルトの暗号化アルゴリズムの設定

TDEのデフォルトの暗号化アルゴリズムはAES128です。Oracle 21c以降のリリースでは、TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHMパラメータを使用してアルゴリズムを設定できますが、ウォレットを作成する前にこの設定を構成する必要があります。同様に、_tablespace_encryption_default_algorithmは、パッチ30398099を含むOracle 19c以前で使用できます。

この設定によって、TABLESPACE_ENCRYPTION=AUTO_ENABLE、ENCRYPT_NEW_TABLESPACES=ALWAYS、およびこのプロセスで使用されるオフライン暗号化の新しい表領域で使用される暗号化アルゴリズムが決まります。

プライマリ・データベースおよびスタンバイ・データベースで、次が発行されます。

-- for Oracle 21c and later
ALTER SYSTEM SET "tablespace_encryption_default_algorithm"='AES256' scope=both;

 -- for Oracle 19c and earlier
ALTER SYSTEM SET "_tablespace_encryption_default_algorithm"='AES256' scope=both;

ステップ3: 暗号化ウォレットの作成およびマスター・キーの設定

TDEドキュメントでは、ウォレットまたはキーストアの作成、およびプライマリ・データベースでのマスター暗号化キーの設定について詳細に説明します。

詳細は、『Oracle Database Advanced Securityガイド』の統一モードのソフトウェア・キーストアおよびTDEマスター暗号化キーの構成を参照してください。

スタンバイの暗号化後にプライマリ・データベースを暗号化しないままにする場合でも、ハイブリッドData Guardユースケースでは、マスター・キーをプライマリ・データベースに設定する必要があります。このキーは、REDO適用時およびロール・トランジション後のスタンバイのデータの暗号化に使用されます。このキーは、ロール・トランジション後に暗号化されたプライマリ・クラウド・データベースからデータを復号化するために使用されます。

ステップ4: スタンバイ・データベース環境へのウォレット・ファイルのコピー

スタンバイ・データベースで暗号化操作を実行するには、スタンバイ・データベースに暗号化ウォレットと自動ログイン・キーストアのコピーが必要です。ファイルはプライマリ・データベースからスタンバイ・データベースに適宜コピーします。

WALLET_ROOTで定義された場所から、実行します。ターゲット・ディレクトリがスタンバイに存在しない場合は、手動で作成する必要があります。

各ノードにファイルをコピーします。

ASMCMD> cp +DATA/PRIMARY_ORACLE_UNQNAME/TDE/cwallet.sso /tmp
ASMCMD> cp +DATA/PRIMARY_ORACLE_UNQNAME/TDE/ewallet.p12 /tmp

<primary host>$ scp /tmp/cwallet.sso ewallet.p12 oracle@standby_host:/tmp

<standby host> ASMCMD> cp /tmp/cwallet.sso +DATA/STANDBY_db_unique_name/TDE/
<standby host> ASMCMD> cp /tmp/ewallet.p12 +DATA/STANDBY_db_unique_name/TDE/

または、ASMからASMにファイルを直接コピーすることもできます。

ASMCMD>cp cwallet.sso sys/password@stbyhost1.+ASM1:+DATA/STANDBY_ORACLE_UNQNAME/TDE/
ASMCMD>cp ewallet.p12 sys/password@stbyhost1.+ASM1:+DATA/STANDBY_ORACLE_UNQNAME/TDE/

ステップ5: Data Guardのヘルスの確認

オフライン暗号化プロセスを開始する前に、スタンバイ・データベースがプライマリに遅れていないことを確認します。管理対象リカバリは暗号化プロセス中に停止する必要があるため、スタンバイ・データベースがプライマリに遅れていないことを確認すると、暗号化プロセス後に適用する必要があるREDOギャップが削減されます。

プライマリまたはスタンバイ・データベースで、REDO適用ラグを検索し、次の例に示すようにスタンバイ・データベースを検証します。Data Guard BrokerコマンドVALIDATE DATABASEは、潜在的な構成のギャップをリストします。ギャップに対処し、「Ready for Switchover」および「Ready for Failover」のステータスが両方ともYESであることを確認します。 

DGMGRL> SHOW CONFIGURATION LAG

Configuration - dgconfig

  Protection Mode: MaxPerformance
  Members:
primary_db    - Primary database
  standby_db - Physical standby database 
               Transport Lag:       0 seconds (computed 1 second ago)
               Apply Lag:           0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 11 seconds ago)


DGMGRL> VALIDATE DATABASE <standby>

  Database Role:     Physical standby database
  Primary Database:  primary

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

ステップ6: スタンバイ・データベースのマウントおよびリカバリの停止

オフライン暗号化プロセスをデータ・ファイルに対して直接実行する前に、スタンバイ・データベースをマウントし、リカバリを停止する必要があります。暗号化プロセス中にスタンバイのすべてのインスタンスを使用して、複数のファイルを同時に暗号化できます。

$ srvctl stop database -d standby -o immediate

$ srvctl start database -d standby -o mount

DGMGRL> EDIT DATABASE standby SET STATE=APPLY-OFF;

REDO転送サービスは、アーカイブ・ログがスタンバイ・データベースに存在するようにREDOを引き続き送信します。このプロセスでは、暗号化プロセス中に障害が発生した場合にリカバリ・ポイント目標(RPO)が維持されます。

非常にアクティブなデータベースの場合、必要な数のアーカイブ・ログが重要になる可能性があるため、リカバリ領域に十分な領域があることを確認してください。

ステップ7: スタンバイ・データベースでのデータ・ファイルのインプレースおよびパラレルな暗号化

TEMP表領域の暗号化プロパティは、作成後に変更できません。TEMP表領域を暗号化するには、暗号化して作成する必要があります。

暗号化されたTEMP表領域を使用するには、ENCRYPTION句を使用して新しいTEMP表領域を作成し、それをデフォルトの一時表領域にします。次に、元のTEMP表領域を削除します。 

SQL> CREATE TEMPORARY TABLESPACE TEMP_ENC ENCRYPTION ENCRYPT;

SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP_ENC;

暗号化された表領域の機密データから生成されるUNDOおよびTEMPメタデータは、すでに暗号化されているため、UNDOおよびTEMP表領域の暗号化はオプションです。

  1. スタンバイ・データベースがマウントされ、キーストアがオープンしていることを確認します。

    SQL> select inst_id,database_role,open_mode from gv$database;

   INST_ID DATABASE_ROLE    OPEN_MODE
---------- ---------------- --------------------
         1 PHYSICAL STANDBY MOUNTED
         2 PHYSICAL STANDBY MOUNTED

SQL> col WRL_PARAMETER format a40
SQL> set linesize 120 pagesize 9999
SQL> select * from gv$encryption_wallet;

INST_ID WRL_TYPE WRL_PARAMETER                          STATUS
------- -------- --------------------------------------- ------
      1 file     +DATA/ORACLE_UNQNAME/TDE             OPEN

  2. データ・ファイルを暗号化します。

    オフライン暗号化コマンドは、各データ・ファイルを単一のプロセスで暗号化しますが、複数のデータ・ファイルを別々のセッションでパラレルで暗号化できます。各セッションは、CPUコアを完全に使用できます。各インスタンスでホストのコア数以下のセッション数を発行することをお薦めします。

    次の問合せを使用して、データ・ファイルを変換するスクリプトを生成できます。スクリプトを複数のスクリプトに分割し、個々のセッションで小さいスクリプトをそれぞれ実行します。最も効率的なプロセスは、複数の小さなファイルを個々のスクリプトに配置しながら、大きなファイルを個別に暗号化することです。

    ノート:

    シード・データベース・ファイルを暗号化する必要はありません。 
    set lines 120
set pages 9999
spool encrypt.sql
select 'alter session set container='||pdb.name||';'||chr(10)||'alter database datafile '||chr(39)||df.name||chr(39)||' encrypt;' COMMAND
from v$tablespace ts, v$datafile df, v$pdbs pdb where ts.ts#=df.ts# and ts.con_id=df.con_id and df.con_id=pdb.con_id and pdb.name <> 'PDB$SEED';

spool off
COMMAND
------------------------------------------------------------------------------------------------------------------------
alter session set container=ORADBP11;
alter database datafile '+DATA/DB_UNIQUE_NAME/E73F249E7030C3B8E0537B544664A065/DATAFILE/system.336.1113852973' encrypt;

alter session set container=ORADBP11;
alter database datafile '+DATA/DB_UNIQUE_NAME/E73F249E7030C3B8E0537B544664A065/DATAFILE/sysaux.335.1113852973' encrypt;

alter session set container=ORADBP11;
alter database datafile '+DATA/DB_UNIQUE_NAME/E73F249E7030C3B8E0537B544664A065/DATAFILE/undotbs1.337.1113852973' encrypt;

<...>

  3. TEMPファイルは、CREATE文のENCRYPTION句を使用して削除および再作成することで暗号化できます。V$TEMPFILEビューを使用して、既存のTEMPファイルを識別します。

  4. V$DATAFILE_HEADER.ENCRYPTEDを問い合せて、すべてのデータ・ファイルが暗号化されていることを確認します。ファイルの暗号化の完了後、ENCRYPTED列はファイルが暗号化されているか(YES)いないか(NO)を示します。シードPDBに属するデータ・ファイルを除くすべてのデータ・ファイルを暗号化する必要があります。

ステップ8: REDO適用の再開とスタンバイ・データベースへのキャッチ・アップ

すべてのデータ・ファイルが暗号化されていることを確認した後、スタンバイ・データベースは、暗号化プロセス中に生成されたプライマリからのすべてのREDOを適用する必要があります。適用する必要があるREDOの量に応じて、スタンバイ・データベースでREDOをキャッチ・アップするには、次の方法をお薦めします。

  • ギャップが小さい場合は、管理対象リカバリを再起動し、適用ラグが0になるまでREDOギャップを適用します。

    プライマリ・データベースまたはスタンバイ・データベースで、次を実行します

    DGMGRL> edit database standby set state=apply-on;

  • 暗号化プロセスに時間がかかり、プライマリ・データベースがアクティブだった場合、ギャップが大きくなる可能性があります。多くの場合、増分ロール・フォワード・アプローチを使用して、適用の停止後に変更されたブロックのみをコピーする方が高速です。

    このプロセスについては、My Oracle Supportノートサービスからのデータベースのリカバリによるスタンバイ・データベースのロール・フォワードの方法(ドキュメントID 2850185.1)に記載されています。ロール・フォワードが完了してもリカバリは必要ですが、このプロセスによって、大きなギャップを埋めるまでの時間が大幅に短縮される可能性があります。

ステップ9: Data Guardスイッチオーバーの実行によるプライマリ・データベースでの暗号化の開始

プライマリ・データベースを暗号化する準備が整うまで、暗号化されていないプライマリ・データベースが暗号化されていないREDOをスタンバイに送信して、スタンバイによって無期限に暗号化するようにできます。

プライマリ・データベースを暗号化する準備ができたら、データベース・ロールを切り替え、Data Guardスイッチオーバーを実行して、暗号化されたスタンバイ・データベースを新しいプライマリ・データベースとし、暗号化されていないプライマリ・データベースを新しいスタンバイにすると、便利です。

スタンバイになった元のプライマリ・データベースで、ステップ5から8を繰り返してデータ・ファイルを暗号化し、REDOにキャッチ・アップします。

ステップ11: Data Guardスイッチオーバーの実行(オプション)

スタンバイ・データベースとプライマリ・データベースの両方が暗号化された後、元のプライマリ/スタンバイ・データベース・ロールに戻す場合は、Data Guardスイッチオーバーを実行して元のロールを再設定します。