将来のセカンダリ・データベースの設定

Oracle Cloud Infrastructure (OCI)で最初のフィジカル・スタンバイを確立した後、別のリージョンに2番目のフィジカル・スタンバイを作成します。この2番目のデータベースは、クラウドベースのディザスタ・リカバリ環境のデータベースです。

Oracle Data Guardカスケード・スタンバイ機能。2番目のスタンバイは、オンプレミスのプライマリから直接ではなく、1番目のスタンバイからredoを受信するため、オンプレミス・ホスト・サイトからのネットワーク・トラフィックが減少します。また、最終的にメインのredo伝播ルートとなるものも確立されます。

現時点では、OCIツールを使用して将来のディザスタ・リカバリ・データベースを確立し、完全に管理できない制約があります。Oracle Data Guard Associationクラウド・サービスは、現在、既存のスタンバイ・データベース関係を登録できず、スタンバイ・データベース構成を管理できません。したがって、たとえば、Oracle Managed Disaster Recovery Cloud Serviceは使用できません。

両方のスタンバイ・データベースはOCIベースのプレースホルダ・データベースを使用して確立されるため、OCIコントロール・プレーンはそれぞれに対するパッチ適用およびその他のライフサイクル・アクティビティを管理できます。

プレースホルダ・データベースの作成

OCIコンソールを使用して、異なるリージョン(推奨)または同じリージョン内の別の可用性ドメインに新しいプレースホルダ・データベースを作成します。

ここに示すステップに従って、OCIやdbaascliなどのツールを使用してプレースホルダ・データベースを削除しないでください。
  1. 「Oracle Public Cloud上のExadata」を選択します。データベースをデプロイするOracle Exadata Database Service on Dedicated Infrastructureサービスを選択します。

    次の制約に従います。

    • データベース・ホームは、ソースと同じソフトウェア・バージョン、リリースおよびパッチ・レベルである必要があります。
    • DB_NAMEは、プライマリ・データベースおよび最初のスタンバイ・データベースと同じである必要があります。
    • DB_UNIQUE_NAMEは空白のままにすることも指定することもできますが、オンプレミスのプライマリ・データベースと最初のフィジカル・スタンバイ・データベースの両方と異なる必要があります。
    • このデータベースのプロビジョニング時に自動バックアップを構成しないでください。
    • このデータベースのプロビジョニング時にPDB名を指定しないでください。
  2. カスケード・スタンバイ構成データを取得します。
    1. 作成したプレースホルダ・データベースをホストしているデータベース・ノードの1つで、oracle OSユーザーとしてログインします。
    2. このデータベースの環境のソースを指定します。
    3. DB_UNIQUE_NAMEを使用して、次のコマンドを実行します。
    $ srvctl config database -db DB_UNIQUE_NAME
    この構成データを保存します。次のステップで使用します。
  3. プレースホルダ・データベースを停止します。
    $ srvctl stop database -db cascade standby placeholder database -stopoption immediate
  4. grid OSユーザーとしてログインします。コマンドasmcmdを使用して、+DATAC1/DB_UNIQUE_NAMEの下のディレクトリにあるファイルを空にします。
    1. DATAFILE
    2. ONLINELOG
    3. すべて PDB GUID/DATAFILE
    4. +DATAC1/DB_UNIQUE_NAME/CONTROLFILEの下にあるすべての制御ファイル
    5. ステップ1で取得した構成データで指定されているパスワード・ファイル
  5. +RECOC1/DB_UNIQUE_NAMEで、ディレクトリARCHIVELOGAUTOBACKUPおよびFLASHBACKLOG内のファイルを削除します。
  6. spfileを削除しないでください。

データベースのリストアの準備

データベースのリストアに備えて、新しいOracleホームを構成します。

  • 各環境のtnsnames.oraファイルを調整して、他の各データベースを認識するようにします。環境間の通信を確認します。
  • 最初のスタンバイ・データベースからパスワード・ファイルをコピーします。
  • 最初のスタンバイ・データベースからTransparent Data Encryption (TDE)ウォレットをコピーします。
  • カスケード・スタンバイ・データベースのデータベース・パラメータを調整します。

カスケード・スタンバイ用のTNSの構成

各環境のtnsnames.oraファイルを調整して、他の各データベースを認識するようにします。環境間の通信を確認します。

Data Guard Brokerは、接続先のインスタンスに関係なく、構成内の各データベースと通信できる必要があります。Oracle Zero Downtime Migrationは、初期スタンバイ関係に対してこの構成を実行しました。カスケード・スタンバイ・データベースを構成に追加する必要があります。
  • オンプレミス・プライマリおよび最初のスタンバイ・データベースのすべてのOracle Real Application Clusters (Oracle RAC)インスタンスで使用されるtnsnames.oraファイルに、カスケード・スタンバイ・データベースのTNS接続文字列を追加します
  • オンプレミス・プライマリ・データベースと最初のOCIスタンバイ・データベースのTNS接続文字列を、カスケード・スタンバイ・データベースのすべてのOracle RACインスタンスで使用されるtnsnames.oraファイルに追加します。
これらのTNSエントリでは、それぞれSCAN名ではなくSCAN IPアドレスを使用する必要があります。Oracle Zero Downtime Migrationが最初のスタンバイ・データベース用に作成した準拠のTNSエントリの例を次に示します:
CDBHCM_iad1dx =
          (DESCRIPTION =
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  1>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  2>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  3>)) (PORT = 1521))
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = CDBHCM_iad1dx)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
              (UR=A)
             )
          )

各データベース・サーバーにoracle OSユーザーとしてログインし、環境をソースにして、ディレクトリを$TNS_ADMINに変更する必要があります。

  1. オンプレミス・プライマリと最初のOCIスタンバイの両方のOracle RACインスタンスごとに、tnsnames.oraファイルを編集し、カスケード・スタンバイ・データベースのTNS接続文字列を追加します。
  2. OCIカスケード・スタンバイのOracle RACインスタンスごとに、tnsnames.oraファイルを編集し、オンプレミス・プライマリ・データベースと最初のOCIスタンバイ・データベースの両方にTNS接続文字列を追加します。
  3. 接続文字列別名を追加したtnspingユーティリティを使用して、最初のスタンバイ・データベースをカスケード・スタンバイからpingできることをテストします。
    $ tnsping CDBHCM_iad1dx
    これにより、待機時間(ミリ秒)で OKが返されます。OKが返されない場合は、エラーを確認し、それに応じて対処します。
  4. SQL*Plusを使用して、カスケード・スタンバイ・データベースをホストする各データベース・サーバーから最初のスタンバイ・データベース(CDBHCM_iad1dx)への接続をテストします。プライマリにはSYSパスワードが必要です。
    $ sqlplus sys/<password>@CDBHCM_iad1dx as sysdba
    エラーを修正し、正常に接続できるまで繰り返します。

パスワード・ファイルのコピー

最初のスタンバイ・データベースからパスワード・ファイルをコピーします。

  1. oracle OSユーザーとして、最初のスタンバイ・データベース(CDBHCM_iad1dx)をホストしているサーバーの1つにログインします。
  2. srvctlを使用して、このデータベースのパスワード・ファイルがどこにあるかを判断し、/tmpディレクトリにコピーします。
    ウォレット・ルートの場所を確認するには、sysdbaとして次を実行します:
    $ srvctl config database -db first standby db name
  3. 「パスワード・ファイル: 」という行を探し、その場所(Oracle Automatic Storage Management (Oracle ASM)パス)を記録します。
  4. grid OSユーザーになり、asmcmdコマンドを使用してパスワード・ファイルを/tmpディレクトリにコピーします。
    $ asmcmd -p
    asmcmd> cd +DATAC1/path from step 3
    asmcmd> cp <password file name> /tmp/password file name
  5. scpを使用して、またはOCI内のファイルの転送に使用する手段によって、パスワード・ファイルをカスケード・スタンバイ・データベース・サーバーのいずれかの一時的な場所に転送します。
  6. パスワード・ファイルが配置されたカスケード・スタンバイ・データベース・サーバーに、grid OSユーザーとしてログインします。上のカスケード・スタンバイ構成データで指定された場所を使用して、パスワード・ファイルをOracle ASMにコピーします。
    $ asmcmd -p --privilege sysdba
    asmcmd> pwcopy –dbuniquename cascade standby db unique name /tmp/password-file-name +ASM Diskgroup/path/password-file-name -f
    asmcmd> pwcopy –dbuniquename CDBHCM_phx5s   /tmp/password file name +DATAC1/CDBHCM_phx5s/PASSWORD/orapwCDBHCM_phx5s -f 
  7. 各データベースが他のすべてのデータベースに接続できることを検証して、すべてのTNS接続文字列が正しく構成されていることを確認します。次の接続試行が失敗した場合の接続エラーを修正します。
    1. オンプレミス(プライマリ)データベースから:
      $ sqlplus sys/password@first standby db as sysdba
      $ sqlplus sys/password@cascade standby db as sysdba
    2. 最初のフィジカル・スタンバイから:
      $ sqlplus sys/password@on-prem primary as sysdba
      $ sqlplus sys/password@cascade standby db as sysdba
    3. カスケード・フィジカル・スタンバイから:
      $ sqlplus sys/password@on-prem primary as sysdba
      $ sqlplus sys/password@first standby db as sysdba
    すべての接続試行が成功するまで続行しないでください。

TDE Walletのコピー

最初のスタンバイ・データベースからTransparent Data Encryption (TDE)ウォレットをコピーします。Oracle Exadata Database Service on Dedicated Infrastructureでは、クラウド・ツールがTDEウォレットを格納するために使用する場所は、クラスタ内のすべてのデータベース・サーバーが共有するOracle Advanced Cluster File System (Oracle ACFS)上にあります。
  1. oracle OSユーザーとして最初のスタンバイ・データベース(CDBHCM_iad1dx)をホストしているサーバーの1つにログインし、ディレクトリをウォレット・ルートの場所に変更します。
    ウォレット・ルートの場所を確認するには、sysdbaとして次を実行します:
    $ sqlplus / as sysdba
    SQL> show wallet_root
    $ cd wallet root location from “show wallet_root” above
  2. ウォレット・ルートの場所に移動し、tdeディレクトリを圧縮します。
    tdeディレクトリは、ステップ1で指定したディレクトリ(通常は/var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root)の下にあります。
    $ zip -r CDBHDM_tde_wallet.zip  tde
  3. このZIPファイルを、カスケード・データベース(CDBHCM_phx5s)をホストするデータベース・サーバーのいずれかに一時的な場所(/tmpなど)に転送します。
    scpを使用するか、OCI内のファイルの転送に使用するどのような方法でも使用します。
  4. カスケード・データベース(CDBHCM_phx5s)をホストし、zipファイルが配置されたデータベース・サーバーにoracle OSユーザーとしてログインし、ディレクトリをウォレット・ルートの場所に変更します。

    DB_NAMEは同じ(CDBHCM)であるため、この場所は前の場所と同じである必要があります。

    $ cd /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root
  5. 既存のTDEディレクトリを別の名前に移動します。
    $ mv tde tde_date
  6. ステップ2で作成したTDEウォレット(CDBHDM_tde_wallet.zip)を含むZIPファイルを次のパスに移動します:/var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root
    DB_NAMEをデータベースの名前に置き換えます。
  7. CDBHDM_tde_wallet.zipファイルを解凍します。
    $ unzip CDBHDM_tde_wallet.zip

これにより、最初のフィジカル・スタンバイ・データベースのウォレット・ファイルを含む新しいtdeサブディレクトリが作成されます。

カスケード・スタンバイのデータベース・パラメータの調整

カスケード・スタンバイ・データベースの構成をファイナライズします。

  1. oracle OSユーザーとして最初のスタンバイ・データベース(CDBHCM_iad1dx)をホストしているサーバーの1つにログインし、環境をソースにします。
    $ . ./CDBHCM.env
  2. カスケード・スタンバイ・データベースのパラメータを調整するための参照として使用する、最初のスタンバイ・データベースからpfileを作成します。
    $ cd $ORACLE_HOME/dbs
    $ sqlplus / as sysdba
    SQL> create pfile=’tmp_CDBHCM_iad1dx_init.ora’ from spfile;
  3. カスケード・スタンバイ・データベース(CDBHCM_phx5s)をホストするデータベース・サーバーの1つにログインし、環境をソースにします。
    $ . ./CDBHCM.env
  4. 1つのインスタンスでNOMOUNTを起動します。
    $ sqlplus / as sysdba
    SQL> startup nomount
  5. 前述のステップ2のデータベース・パラメータのリストを参照して、カスケード・データベースのデータベース・パラメータを次のように調整します。
    SQL> alter system set control_files=’’ sid=’*’ scope=spfile;
    SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 1>’ scope=spfile;
    SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 2>’ scope=spfile;
    SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance N>’ scope=spfile;
    SQL> alter system set sga_target=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
    SQL> alter system set log_buffer=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
  6. PeopleSoftに固有のパラメータを調整します。
    SQL> alter system set “_gby_hash_aggregation_enabled”=false sid=’*’ scope=spfile;
    SQL> alter system set “_ignore_desc_in_index”=true sid=’*’ scope=spfile;
    SQL> alter system set “_unnest_subquery”=true sid=’*’ scope=spfile;
    SQL> alter system set nls_length_semantics='CHAR' sid=’*’ scope=spfile;

    ノート:

    次のパラメータは変更しないでください。
    • DB_NAME
    • DB_UNIQUE_NAME
    • WALLET_ROOT
  7. 変更を実装するには、インスタンスでNOMOUNTを停止し、再起動します。
    $ sqlplus / as sysdba
    SQL> shutdown immediate
    SQL> startup nomount

カスケード・スタンバイへのデータベースのリストア

最初のフィジカル・スタンバイ・データベースからカスケード・スタンバイ・フットプリントにデータベースをリストアします。Oracle Recovery Manager (RMAN)コマンドRESTORE FROM SERVICEを使用して、制御ファイルおよびデータファイルをリストアします。

  1. カスケード・スタンバイのインスタンスが起動されていない場合は、NOMOUNTで起動します。
    $ sqlplus / as sysdba 
    $ SQL> startup nomount
  2. RMANを使用して、最初のスタンバイからカスケード・スタンバイに制御ファイルおよびデータファイルをリストアします。

    ノート:

    ネットワークが飽和しないように、RMANチャネルの数をデバイス・タイプ・ディスク用に調整する必要がある場合があります。変更が必要な場合は、コマンドrestore database from serviceを実行する前に行います。これは、必要に応じてNを置換して、次のコマンドで実行できます。
    RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM N; 
    $ rman target / nocatalog
    RMAN> restore standby controlfile from service ‘first standby db name’;
    RMAN> alter database mount;
    RMAN> restore database from service ‘first standby db name’ section size 8G;
    RMAN> shutdown immediate;
    RMAN> exit
  3. すべてのインスタンスを再起動し、srvctlを使用してカスケード・スタンバイ・データベースをマウントします。
    $ srvctl start database -db cascade standby db unique name -startoption mount
  4. 次のスクリプトを使用して、すべてのオンラインおよびスタンバイのログ・ファイルを作成してクリアします。
    $ sqlplus “/ as sysdba”
    SQL> set pagesize 0 feedback off linesize 120 trimspool on
    SQL> spool /tmp/clearlogs.sql
    SQL> select distinct 'alter database clear logfile group '||group#||';' from v$logfile;
    SQL> spool off
  5. 生成されたclearlogs.sqlスクリプトを実行する前に調べます。これにより、データベース・インスタンスは、すべてのスレッドのオンライン・ログ・ファイルとスタンバイ・ログ・ファイルの両方を作成およびクリアします。次にスクリプトを実行します。
    SQL> @/tmp/clearlogs.sql

カスケード・スタンバイ用のData Guard Brokerの構成

Oracle Zero Downtime Migrationによって、オンプレミスのプライマリ・データベースと最初のOCIスタンバイ・データベースの間にData Guard Brokerがすでに構成されています。ここでは、構成にカスケード・スタンバイを追加します。

カスケード・スタンバイとオンプレミス・データベースは、相互に直接通信しません。必要に応じて、redoは最初のオンプレミス・スタンバイ・データベースを介して出荷されます。

  • オンプレミス・データベースがプライマリの場合、redoはオンプレミス・プライマリから最初のスタンバイへ、または最初のスタンバイを介してカスケード・スタンバイに送信されます。
    • オンプレミス・プライマリからOCIファースト・スタンバイ
    • OCI第1スタンバイからOCIカスケード・スタンバイ
  • 最初のスタンバイがプライマリ・ロールの場合、redoは、そのデータベースからオンプレミス・データベースとカスケード・スタンバイ・データベースの両方に直接送信されます。
    • OCIプライマリからオンプレミス・スタンバイ
    • OCIプライマリからOCIカスケード・スタンバイ
  • この構成でカスケード・スタンバイがプライマリになると、REDOはそのデータベースからOCIの最初のスタンバイへ、またはOCIを介してオンプレミス・データベースへ送信されます。
    • OCIファースト・スタンバイからオンプレミス・スタンバイ
    • OCIはプライマリをOCIの最初のスタンバイにカスケードします
  1. カスケード・スタンバイをホストするデータベース・サーバーでData Guard Brokerを構成します。oracle OSユーザーとしてカスケード・スタンバイ・データベースをホストしているデータベース・サーバーの1つにログインし、環境をソースにします。
    $ sqlplus / as sysdba
    SQL> alter system set dg_broker_config_file1=’+DTAC1/cascade standby db/DG/dr1 cascade standby db.dat’ sid=’*’ scope=both;
    SQL> alter system set dg_broker_config_file2=’+RECOC1/cascade standby db/DG/dr2 cascade standby db.dat’ sid=’*’ scope=both;
    SQL> alter system set dg_broker_start=TRUE sid=’*’ scope=both;
  2. プライマリ・データベースまたは最初のフィジカル・スタンバイ・データベースにログインし、環境をソースにします。新しいカスケード・スタンバイを既存のData Guard Broker構成に追加します。
    $ dgmgrl 
    DGMGRL>  connect sys/password
    DGMGRL> show configuration
    DGMGRL> add database 'cascade standby db’
     as connect identifier is cascade standby db;
  3. redo routesを追加します。
    DGMGRL> edit database on-premises db set property redoroutes='(LOCAL : first standby db ASYNC)';
    DGMGRL> edit database first standby db set property redoroutes='(LOCAL : on-premises db ASYNC, cascade standby db ASYNC)(on-premises db : cascade standby db ASYNC)(cascade standby db : on-premises db ASYNC)';
    DGMGRL> edit database cascade standby db set property redoroutes='(LOCAL : first standby db ASYNC)';
  4. 新しいカスケード・スタンバイ・データベースを有効にします。
    DGMGRL> enable database cascade standby db;
  5. カスケード・データベースを有効にすると、最初のスタンバイ・データベースを介してオンプレミス・プライマリ・データベースによって生成されたredoの受信が開始されます。Data Guard Broker内から、構成を表示します。
    DGMGRL> show configuration lag
    Configuration - zdm_psfthcm_dg
      Protection Mode: MaxPerformance
      Members:
      CDBHCM_sca6dp  - Primary database
        CDBHCM_iad1dx - Physical standby database 
                          Transport Lag:      0 seconds (computed 0 seconds ago)
                          Apply Lag:          0 seconds (computed 1 second ago)
          CDBHCM_phx5s - Physical standby database (receiving current redo)
                            Transport Lag:      1 second (computed 1 second ago)
                            Apply Lag:          2 seconds (computed 1 second ago)
    
    Fast-Start Failover:  Disabled
    
    Configuration Status:
    SUCCESS   (status updated 47 seconds ago)

将来のスタンバイに対するロールベースのデータベース・サービスの定義

OCIセカンダリ・データベースがPRIMARYロールを満たしているときにPeopleSoftアプリケーションが使用するロールベースのデータベース・サービスを追加します。

  1. プロセス・スケジューラにロールベースのデータベース・サービスを追加します。
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_BATCH -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3
  2. オンライン・ユーザー用のロールベースのデータベース・サービスを追加します。
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_ONLINE -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3