1. 管理者ガイド
  2. リカバリ・アプライアンスの管理
  3. 追加の高可用性計画の実装

15 追加の高可用性計画の実装

レプリケーションに加えて、他の高可用性計画をリカバリ・アプライアンスとともに使用して、特定のシナリオでのデータ損失に対する保護を強化できます。

サイト障害およびシステムの停止に対してアプライアンスを保護するOracle最大可用性アーキテクチャ(MAA)のベスト・プラクティスは、リカバリ・アプライアンス・レプリケーションを使用して障害回復戦略を実装することです。レプリカ・アプライアンスを使用すると、保護されたデータベースのバックアップ、REDOおよびリストア操作は中断されることなく続行され、完全なデータ保護が維持されます。

組織に障害回復戦略がない場合、または既存の障害回復戦略にローカル・システムの高可用性を追加する場合は、リカバリ・アプライアンスのバックアップおよびREDOフェイルオーバー機能を使用できます。

高可用性(HA)および障害回復ソリューションのもう1つのコンポーネントは、Oracle Data Guardです。Oracle Data Guardは、保護されたデータベースの同期化されたスタンバイ・データベースを維持することによって、サービス中断および生じたデータ損失を最小限に抑えます。

関連項目:

バックアップおよびREDOフェイルオーバー計画を使用した一時的な停止の管理

バックアップおよびREDOフェイルオーバーは、プライマリ・リカバリ・アプライアンスが停止したとき、または計画メンテナンスが必要なときに、保護されたデータベースがバックアップおよびREDOを一時的に代替リカバリ・アプライアンスに送ることを許可する高可用性機能です。これによって、保護されたデータベースのバックアップおよびREDOは中断することなく続行され、完全なデータ保護を維持できます。また、データベースのローカル・アーカイブ・ログの宛先が一杯になりデータベースに影響を与えることを防止します(代替のバックアップ宛先がない場合はそのようになることがあります)。

バックアップおよびREDOフェイルオーバー機能の概要

バックアップおよびREDOフェイルオーバーが構成されている環境で、保護されたデータベースは、通常の状況ではプライマリ・リカバリ・アプライアンスにバックアップおよびREDOを送信します。そのアプライアンスが使用できない場合、保護されたデータベースは、プライマリのサービスがリストアされるまで、バックアップおよびREDOを代替リカバリ・アプライアンスに送信します。

代替アプライアンスは、受信した一時バックアップから仮想完全バックアップを作成せず、バックアップ・ピースの格納のみを行います(増分バックアップおよびアーカイブ・ログ・バックアップ)。プライマリ・アプライアンスがオンラインに戻って機能するようになると、代替アプライアンスはすべての一時バックアップをプライマリ・アプライアンスに転送し、プライマリ・アプライアンスはそのバックアップを使用して対応する仮想完全バックアップを作成します。すべての仮想完全バックアップが作成されると、保護されたデータベースはプライマリ・アプライアンスへのバックアップおよびREDOの送信を再開します。代替アプライアンスは、プライマリ・アプライアンスに正常に転送して初めて、ローカル記憶域から一時バックアップ・ピースを削除します。

バックアップおよびREDOフェイルオーバーの構成

この項では、バックアップおよびREDOフェイルオーバーを構成する方法について説明します。基本的なワークフローは次のとおりです。

  1. 「バックアップおよびREDOフェイルオーバーのためのプライマリ・リカバリ・アプライアンスの構成」の説明に従って、プライマリ・リカバリ・アプライアンスを構成します。

  2. 「バックアップおよびREDOフェイルオーバーのための代替リカバリ・アプライアンスの構成」の説明に従って、代替リカバリ・アプライアンスを構成します。

  3. 「バックアップおよびREDOフェイルオーバーのためのレプリケーションの構成」の説明に従って、代替リカバリ・アプライアンスからプライマリ・リカバリ・アプライアンスへのレプリケーションを構成します。

  4. 「バックアップおよびREDOフェイルオーバーのための保護されたデータベースの構成」の説明に従って、バックアップを送信するために保護されたデータベースを構成します。

バックアップおよびREDOフェイルオーバーのためのプライマリ・リカバリ・アプライアンスの構成

バックアップおよびREDOフェイルオーバーのためにプライマリ・リカバリ・アプライアンスを構成するには、レプリケーション・シナリオのダウンストリーム・リカバリ・アプライアンスの設定用タスクの多くを実行します。

タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成

racli add db_userに関する項の手順に従います。

たとえば、リカバリ・アプライアンスにrootとしてログインし、binディレクトリに変更し、次のコマンドを使用してVPCユーザーを作成します。

# ./racli add db_user --user_name=vpcuser --user_type=vpc

プロンプト表示されたら、vpcuserユーザーのパスワードを入力します。

CREATE SESSION権限のあるレプリケーション・ユーザーrepuser_from_alternateを作成するには、次のようにします。 

CREATE USER repuser_from_alternate IDENTIFIED BY password;
GRANT CREATE SESSION TO repuser_from_alternate;

代替で作成されたuser_nameは、プライマリで作成されたVPCユーザーと同じである必要があります。ただし、パスワードは同じである必要はありません。

タスク2 プライマリ・リカバリ・アプライアンスでの保護ポリシーの作成

「保護ポリシーの作成」の手順に従います。store_and_forwardフィールドがNOに設定されていることを確認します。

たとえば、次のPL/SQLプログラムを実行して、primary_brfポリシーを作成します。 

BEGIN
  DBMS_RA.CREATE_PROTECTION_POLICY (
    protection_policy_name => 'primary_brf',
    description            => 'For protected dbs on primary',
    storage_location_name  => 'delta',
    recovery_window_goal   => INTERVAL '28' DAY,
    guaranteed_copy        => 'NO',
    store_and_forward      => 'NO');
END;

タスク3: プライマリ・リカバリ・アプライアンスでの保護ポリシーへのデータベースの追加

「保護されたデータベースの登録」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、orcl12を前のタスクで作成したprimary_brfポリシーに追加します。 

BEGIN
  DBMS_RA.ADD_DB (
    db_unique_name         => 'orcl12',
    protection_policy_name => 'primary_brf',
    reserved_space         => '128G');
END;

タスク4: プライマリ・リカバリ・アプライアンスでのVPCユーザーおよびレプリケーション・ユーザーへのデータベース・アクセスの付与

「保護されたデータベースの登録」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、VPCユーザーvpcuserおよびレプリケーション・ユーザーrepuser_from_alternateに、保護されたデータベースorcl12で必要な権限を付与します。 

BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpcuser',
    db_unique_name => 'orcl12');
END;
BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'repuser_from_alternate',
    db_unique_name => 'orcl12');
END;
バックアップおよびREDOフェイルオーバーのための代替リカバリ・アプライアンスの構成

代替リカバリ・アプライアンスを構成するには、レプリケーション・シナリオのアップストリーム・リカバリ・アプライアンスの設定に類似したタスクを実行します。

タスク1 代替リカバリ・アプライアンスでのバックアップおよびREDOフェイルオーバーのための保護ポリシーの作成

「保護ポリシーの作成」の手順に従います。store_and_forwardフィールドをYESに設定していることを確認します。

たとえば、次のPL/SQLプログラムを実行して、alt_brfポリシーを作成します。 

BEGIN
  DBMS_RA.CREATE_PROTECTION_POLICY (
    protection_policy_name => 'alt_brf',
    description            => 'For protected dbs on alternate',
    storage_location_name  => 'delta',
    recovery_window_goal   => INTERVAL '28' DAY,
    guaranteed_copy        => 'NO',
    store_and_forward      => 'YES');
END;

タスク2: 代替リカバリ・アプライアンスでの保護ポリシーへのデータベースの追加

「保護されたデータベースの登録」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、orcl12を前のタスクで作成したalt_brfポリシーに追加します。 

BEGIN
  DBMS_RA.ADD_DB (
    db_unique_name         => 'orcl12',
    protection_policy_name => 'alt_brf',
    reserved_space         => '128G');
END;

タスク3: 代替リカバリ・アプライアンスでのVPCユーザーへのデータベース・アクセスの付与

このユーザーは、「タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成」で作成されました。

「保護されたデータベースの登録」の手順に従います。

たとえば、次のPL/SQLプログラムを実行して、VPCユーザーvpcuserに保護されたデータベースorcl12で必要な権限を付与します。 

BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpcuser',
    db_unique_name => 'orcl12');
END;
バックアップおよびREDOフェイルオーバーのレプリケーションの構成

プライマリ・リカバリ・アプライアンスおよび代替リカバリ・アプライアンスを構成した後、代替アプライアンスからプライマリ・アプライアンスへのレプリケーションの設定に類似したタスクを実行します。このシナリオでは、代替アプライアンスはアップストリーム・ロールを持ち、プライマリ・アプライアンスはダウンストリーム・ロールを持ちます。

タスク1: 代替リカバリ・アプライアンスでのOracleウォレットの構成

代替リカバリ・アプライアンスで、mkstoreユーティリティを使用してOracle自動ログイン・ウォレットを作成し、「タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成」で作成したレプリケーション・ユーザーの資格証明を追加します。代替リカバリ・アプライアンスは、プライマリ・リカバリ・アプライアンスへのログイン時にこれらの資格証明が必要となります。

代替リカバリ・アプライアンスで自動ログイン・ウォレットを構成するには:

  1. 次のコマンドを実行して、/dbfs_repdbfs/REPLICATIONディレクトリにOracleウォレットを作成します。 

    mkstore -wrl /dbfs_repdbfs/REPLICATION -createALO

    mkstoreユーティリティにより、cwallet.ssoという名前のファイルが指定した場所に作成されます。

  2. 次のコマンドを実行して、レプリケーション・ユーザー資格証明を追加します。

    mkstore -wrl wallet_location -createCredential serv_name rep_user pwd

    プレースホルダは次のように定義されています。

    たとえば、次のコマンドは、ポート1522およびデータベース名rapriを使用するネット・サービス名rapribrf-scan.acme.comと、レプリケーション・ユーザー名repuser_from_alternateの資格証明を追加します。 

    mkstore -wrl /dbfs_repdbfs/REPLICATION -createCredential \
"rapribrf-scan.acme.com:1522/rapri" "repuser_from_alternate" "pwd"

  3. 次のコマンドを実行して、このユーザーに資格証明が適切に追加されたことを確認します。

    mkstore -wrl /dbfs_repdbfs/REPLICATION -listCredential

Oracle Secret Store Tool : Version 12.1.0.1 Copyright (c) 2004, 2012, Oracle and/or its affiliates. All rights reserved.
List credential (index: connect_string username)
1: rapribrf-scan.acme.com:1522/rapri repuser_from_alternate

    結果にパスワードは表示されません。

タスク2: 代替リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成

DBMS_RA.CREATE_REPLICATION_SERVERを実行して、この代替リカバリ・アプライアンスが停止後にバックアップを転送するプライマリ・リカバリ・アプライアンスにレプリケーション・サーバー構成を作成します。

このタスクでは、次のことを想定しています。

レプリケーション・サーバー構成を作成するには:

  1. SQL*PlusまたはSQL Developerで、RASYSとして代替リカバリ・アプライアンスのメタデータ・データベースに接続します。

  2. プライマリ・リカバリ・アプライアンスに対してDBMS_RA.CREATE_REPLICATION_SERVERプロシージャを実行します。

    次の例では、プライマリ・リカバリ・アプライアンスにraprimary_repというレプリケーション・サーバー構成を作成します。 

    BEGIN
  DBMS_RA.CREATE_REPLICATION_SERVER (
    replication_server_name => 'raprimary_rep',
    sbt_so_name      => '/u01/app/oracle/product/12.1.0.2/dbh1/lib/libra.so',
    catalog_user_name       => 'RASYS',
    wallet_alias            => 'rapribrf-scan.acme.com:1522/rapri',
    wallet_path             => 'file:/dbfs_repdbfs/REPLICATION');
END;

  3. レプリケーション・サーバー構成の作成を確認します。replication_server_nameは大文字に変換されて、格納されます。したがって、名前の問合せも大文字にする必要があります。

    たとえば、次の問合せを実行します。

    SELECT COUNT(*) should_be_one 
FROM   RA_REPLICATION_SERVER
WHERE  REPLICATION_SERVER_NAME = 'RAPRIMARY_REP';

SHOULD_BE_ONE
-------------
1

    構成が正しく作成された場合、戻り値は1です。

タスク3: 代替リカバリ・アプライアンスのバックアップおよびREDOフェイルオーバーの保護ポリシーとの関連付け

レプリケーション・サーバー構成を保護ポリシーに割り当てることで、代替リカバリ・アプライアンスが停止後にバックアップを転送するプライマリ・リカバリ・アプライアンスを指定します。

このタスクでは、次のことを想定しています。

レプリケーション・サーバー構成をバックアップおよびREDOフェイルオーバー保護ポリシーに関連付けるには:

  1. リカバリ・アプライアンス管理者として代替リカバリ・アプライアンスのメタデータ・データベースに接続していることを確認します。

  2. バックアップおよびREDOフェイルオーバー保護ポリシーとレプリケーション・サーバー構成に対して、DBMS_RA.ADD_REPLICATION_SERVERプロシージャを実行します。

    たとえば、次のPL/SQLプログラムを実行します。

    BEGIN
  DBMS_RA.ADD_REPLICATION_SERVER (
   replication_server_name => 'raprimary_rep',
   protection_policy_name  => 'alt_brf');
END;

関連項目:

「ADD_REPLICATION_SERVER」

バックアップおよびREDOフェイルオーバーのための保護されたデータベースの構成

バックアップおよびREDOフェイルオーバーのレプリケーションを構成した後、保護されたデータベースの管理者はこの項のタスクを実行して、保護されたデータベースが通常の状況ではバックアップをプライマリ・リカバリ・データベースに送信し、計画停止または計画外の停止の間は代替リカバリ・アプライアンスに送信できるようにする必要があります。

タスク1: ウォレットの場所を指定するsqlnet.oraの構成

sqlnet.oraファイルに、Oracleウォレットの場所が含まれていることを確認します。

次の例は、ウォレットの場所のエントリがどのように表示されるかを示しています。

SQLNET.WALLET_OVERRIDE = true
WALLET_LOCATION = 
(SOURCE = 
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra)
   )
  )

タスク2: sqlnet.oraで指定した場所での自動ログイン・ウォレットの作成

次の例では、「タスク1: ウォレットの場所を指定するsqlnet.oraの構成」で指定したディレクトリに自動ログイン・ウォレットを作成します。 

$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createALO

タスク3: プライマリおよび代替リカバリ・アプライアンスの資格証明のウォレットへの追加

このタスクでは、保護されたデータベースの管理者は、「タスク1: プライマリ・リカバリ・アプライアンスでのVPCユーザー・アカウントおよびレプリケーション・ユーザー・アカウントの作成」で作成したVPCユーザーを使用して、プライマリおよび代替アプライアンスの資格証明をウォレットに追加します。

次の例では、プライマリ・アプライアンスrapribrf-scan.acme.com:1521/rapri:dedicatedおよび代替アプライアンスraaltbrf-scan.acme.com:1521/raalt:dedicatedのvpcuser資格証明を、保護されたデータベース上のウォレットに追加します。 

$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createCredential "rapribrf-scan.acme.com:1521/rapri:dedicated" "vpcuser" "pwd"
$ mkstore -wrl /u01/app/oracle/product/12.1.0/dbhome_1/dbs/zdlra/ -createCredential "raaltbrf-scan.acme.com:1521/raalt:dedicated" "vpcuser" "pwd"

タスク4: データベースの代替リカバリ・アプライアンスへの登録および制御ファイルのバックアップ

このタスクでは、保護されたデータベースの管理者がステップ1および2を実行し、リカバリ・アプライアンス管理者がステップ3を実行します。

データベースを登録し、制御ファイルをバックアップするには:

  1. RMANを使用して、保護されたデータベースにはTARGETとして、代替リカバリ・アプライアンス・カタログにはCATALOGとして接続し、REGISTER DATABASEコマンドを実行します。

  2. REGISTER DATABASEコマンドが完了した後、現在の制御ファイルを代替アプライアンスにバックアップします。 

    BACKUP DEVICE TYPE SBT CURRENT CONTROLFILE;

  3. 制御ファイルのバックアップが代替アプライアンスからプライマリ・アプライアンスにレプリケートされたことを確認します。

タスク5: データベースがプライマリ・リカバリ・アプライアンスに登録されていることの確認

このステップでは、保護されたデータベースがプライマリ・アプライアンスに登録されていることを確認します。前のタスクでデータベースが代替アプライアンスに登録されるときにレプリケーションが構成されるため、データベースはプライマリ・アプライアンスに自動的に登録される必要があります。

プライマリ・アプライアンスへの登録を確認するには:

  1. RMANで、CATALOG接続文字列にプライマリ・アプライアンス資格証明を使用して、データベースに接続します。

    rman TARGET / CATALOG /@rapribrf-scan.acme.com:1521/rapri:dedicated

  2. REGISTER DATABASEコマンドを実行します。

    次のエラーが表示されます。

    RMAN-20002: target database already registered in recovery catalog

ノート:

  • 保護されたデータベースの管理者は、プライマリ・アプライアンスが使用できないときにバックアップを代替リカバリ・アプライアンスに送り、プライマリ・アプライアンスが機能するようになったらバックアップをプライマリ・アプライアンスにリダイレクトする、別のRMANバックアップ・スクリプトを作成する必要もあります。このスクリプトは代替リカバリ・アプライアンス・カタログに接続する必要があり、credential_aliasを代替アプライアンスに設定したCONFIGURE CHANNELまたはALLOCATE CHANNELコマンドが必要です。リカバリ・アプライアンスのRMANバックアップ・スクリプトを作成する方法の例は、Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイドを参照してください。

  • プライマリ・アプライアンスの停止中にリアルタイムREDOを代替リカバリ・アプライアンスに送信するには、プライマリ・アプライアンスへの接続に使用するログ・アーカイブ宛先のALTERNATEとして追加のログ・アーカイブ宛先を定義する必要があります。接続文字列は、プライマリ・アプライアンスに必要な接続文字列と同様に、Oracle自動ログイン・ウォレットに定義して、同じVPCユーザー(パスワードは異なる場合がありますが)を使用する必要があります。ALTERNATE属性を使用して代替リモート宛先に自動的にフェイルオーバーする方法の例は、Data Guard概要および管理を参照してください。

ダウンストリーム・リカバリ・アプライアンスへのDRフェイルオーバーの実装

この項では、ダウンストリーム・リカバリ・アプライアンスにバックアップ操作およびREDOトランスポートの透過的フェイルオーバーを行うために保護されたデータベースを構成するステップについて説明します。

障害回復の一環として、保護されたデータベースは、アップストリーム・リカバリ・アプライアンスが使用できなくなった場合に、バックアップ・ファイルおよびREDOトランスポートを送信するためのターゲットとしてダウンストリーム・リカバリ・アプライアンスにフェイルオーバーします。

わかりやすくするために、この例では次のことを想定しています。

  • リアルタイムREDOトランスポートが有効な場合、エラーを受信し、アップストリーム・リカバリ・アプライアンスへのREDOの送信を停止します。1分以内に、リアルタイムREDOトランスポートはダウンストリーム・リカバリ・アプライアンスに接続し、そこでREDOの送信を再開します。
  • 保護されたデータベースの例の名前はCDB122DRです。これは、1つのプラガブル・データベースを持つコンテナ・データベースです。
  • アップストリーム・リカバリ・アプライアンスの例の名前はRAHADR1です。
  • ダウンストリーム・リカバリ・アプライアンスの例の名前はRAHADR2です。
  • HADR_COMMON_VPCUSERという共通VPCユーザーを両方のリカバリ・アプライアンス上に作成済で、両方に同じパスワードを使用する必要があります。
  • HADR_LOCAL_VPCUSERというローカルVPCユーザーを両方のリカバリ・アプライアンス上に作成済ですが、パスワードは2つの間で異なっていてもかまいません。
  • RAHADR1とRAHADR2の間のレプリケーション・サーバーは、VPCユーザーREPUSER_FROM_HADR1を使用しています。

プライマリ・データベースとスタンバイ・データベースを持つData Guard設定を使用する場合、dbidとdbnameが同じであるため、それぞれに異なるdb_unique_nameが必要です。一意性を保証するには、プライマリおよびスタンバイで一意の制御ファイルautobackup形式を使用します。形式は、RMAN構成設定を使用して指定できます。デフォルトのControlfile Autobackup Formatは次のとおりです: 

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F';

プライマリ・データベースとスタンバイ・データベースの両方のデフォルト形式にdb_unique_nameを追加します: 

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '<db_unique_name>_%F';

db_unique_nameは、v$databaseから取得されます。 

select db_unique_name from v$database;

フェイルオーバーの設定および構成

この項では、フェイルオーバーのために後で使用するリカバリ・アプライアンスのVPCユーザーを設定します。このユーザーは、必要なネットワーク構成ファイルを変更し、レプリケーション・サーバーを構成し、保護ポリシーを作成し、保護されたデータベースを登録し、アップストリームおよびダウンストリーム・リカバリ・アプライアンスにいくつかの権限を追加します。

VPCユーザーの作成

このタスクでは、アップストリームおよびダウンストリーム・リカバリ・アプライアンスにデータベースVPCユーザー・アカウントを作成します。

アカウントの作成時には、次のパスワードの要件に注意してください。

  • 最初のVPCユーザー(HADR_LOCAL_VPCUSER)アカウントは、他の保護されたデータベースで使用でき、リカバリ・アプライアンスRAHADR1とRAHADR2で異なるパスワードを持つことができます。
  • 2番目のVPCユーザー(HADR_COMMON_VPCUSER)アカウントは、リカバリ・アプライアンスRAHADR1とRAHADR2の両方で同じパスワードを使用する必要があり、他の保護されたデータベースで使用できます

この個別の例には、次の条件が適用されます。

  • リカバリ・アプライアンスRAHADR1は、以前にrahadr1のDB_UNIQUE_NAMEでインストールされています。
  • リカバリ・アプライアンスRAHADR2は、以前にrahadr2のDB_UNIQUE_NAMEでインストールされています。
  1. アップストリーム・リカバリ・アプライアンスRAHADR1上の保護されたデータベース用に2つのVPCユーザーを作成します。
    # racli add db_user --user_name HADR_LOCAL_VPCUSER --user_type=vpc
[HADR_LOCAL_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_LOCAL_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_LOCAL_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_LOCAL_VPCUSER.

# racli add db_user --user_name HADR_COMMON_VPCUSER --user_type=vpc
[HADR_COMMON_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_COMMON_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_COMMON_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_COMMON_VPCUSER.
  2. ダウンストリーム・リカバリ・アプライアンスRAHADR2上の保護されたデータベース用に2つのVPCユーザーを作成します。
    # racli add db_user --user_name HADR_LOCAL_VPCUSER --user_type=vpc
[HADR_LOCAL_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_LOCAL_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_LOCAL_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_LOCAL_VPCUSER.

# racli add db_user --user_name HADR_COMMON_VPCUSER --user_type=vpc
[HADR_COMMON_VPCUSER] New Password: ***********
Sun Mar 25 08:27:53 2018: Start: Add vpc user HADR_COMMON_VPCUSER.
Sun Mar 25 08:27:53 2018: Add vpc user HADR_COMMON_VPCUSER successfully.
Sun Mar 25 08:27:53 2018: End: Add vpc user HADR_COMMON_VPCUSER.
  3. アップストリーム(HARADR1)からダウンストリーム(RAHADR2)のリカバリ・アプライアンスにバックアップを送信するためにレプリケーション・サーバーが使用するVPCユーザー・アカウントが作成されていない場合は、VPCユーザーを今すぐ作成してください。
    # racli add db_user --user_name REPUSER_FROM_HADR1 --user_type=vpc
[REPUSER_FROM_HADR1] New Password: ***********

Sun Mar 25 08:35:01 2018: Start: Add vpc user REPUSER_FROM_HADR1.
Sun Mar 25 08:35:01 2018: Add vpc user REPUSER_FROM_HADR1 successfully.
Sun Mar 25 08:35:01 2018: End: Add vpc user REPUSER_FROM_HADR1.
トランスポート・フェイルオーバーの構成の変更

このタスクでは、ダウンストリーム・リカバリ・アプライアンスへの透過的フェイルオーバーに使用されるOracleネットワーク構成ファイルを変更します。

RACデータベースがある場合、保護されたデータベースが実行されている各ホストでこれを実行する必要があります。
  1. どのホストにも${ORACLE_HOME}/dbs/ra${ORACLE_SID}.oraファイルがないことを確認してください。
    このファイルはこのステップで定義されているすべての構成パラメータをオーバーライドするため、存在する場合は削除する必要があります。
  2. 適切なリカバリ・アプライアンスに接続するためにRMANが使用するTNS別名をtnsnames.oraファイルで構成します。
    $ cd ${ORACLE_HOME}/network/admin
  3. tnsnames.oraを編集し、次のエントリを追加します。
    DR_RAHADR =
(DESCRIPTION_LIST =
  (LOAD_BALANCE = off)
  (FAILOVER = on)
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra1ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr1)
    )
  )
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra2ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr2)
    )
  )
)
DR_RAHADR1 =
(DESCRIPTION_LIST =
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra1ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr1)
    )
  )
)
DR_RAHADR2 =
(DESCRIPTION_LIST =
  (DESCRIPTION =
    (CONNECT_TIMEOUT = 5)
    (TRANSPORT_CONNECT_TIMEOUT = 3)
    (RETRY_COUNT = 3)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = ra2ingest-scan)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = rahadr2)
    )
  )
)
レプリケーション・サーバーの構成

このタスクでは、リカバリ・アプライアンスRAHADR1からRAHADR2にデータベース・バックアップを送信するレプリケーション・サーバーを構成します。

専用のレプリケーション・ネットワークがない場合、ここで使用される操作およびネーミング規則はEnterprise Managerのものと同じです。詳細は、リカバリ・アプライアンスでのバックアップのレプリケートを参照してください。
RAHADR1とRAHADR2の間のレプリケーション・サーバーはまだ作成されていません。
  1. RAHADR1にレプリケーション・ウォレットが存在しない場合は、RAHADR2を指すレプリケーション・ウォレットを作成します。
    $ mkstore -wrl file:/dbfs_repdbfs/REPLICATION -createALO
  2. 資格証明をウォレットに追加します。RAHADR1で、RAHADR2にログインするための資格証明を追加します。
    $ mkstore -wrl file:/dbfs_repdbfs/REPLICATION 
-createCredential <rahadr2-scan>:1521/rahadr2 REPUSER_FROM_HADR1 my_v3ry_c0mplex_pa55w0rd
  3. RAHADR1でリカバリ・アプライアンスのレプリケーション・サーバーを作成します。
    $ sqlplus rasys/ra

SQL> exec dbms_ra.create_replication_server( 
replication_server_name =>'RAHADR2_REP', 
sbt_so_name => 'libra.so', max_streams => 8, 
catalog_user_name=> 'RASYS', 
wallet_alias => '<rahadr2-scan>:1521/rahadr2',
wallet_path => 'file:/dbfs_repdbfs/REPLICATION');

PL/SQL procedure successfully completed.
アップストリームおよびダウンストリーム・リカバリ・アプライアンスの構成

このタスクでは、ダウンストリームとアップストリームのリカバリ・アプライアンス上で保護されたデータベースの保護ポリシーを構成し、保護ポリシーをレプリケーション・サーバーに追加します。

たとえば、CBR122DRデータベースなどによって使用される保護ポリシーがそれぞれのリカバリ・アプライアンスに存在しない場合、このステップによって作成されます。保護ポリシー名は、ダウンストリームとアップストリームのリカバリ・アプライアンス間で一意である必要はありません。

RAHADR1とRAHADR2の間の循環参照を回避するために、RAHADR2からの保護ポリシーはレプリケーション・サーバーに追加されませんが、RAHADR1からの保護ポリシーは追加されます。保護ポリシー内のすべてのデータベースがレプリケートされます。

ノート: RAHADR2は通常CDB122DRデータベースからREDOを受け入れないため、CDB122DRデータベースがアイドル状態の場合、保護されていないデータ・ウィンドウ・パラメータを1.25日に設定して、falseアラートの発生を回避します。

  1. ダウンストリーム・リカバリ・アプライアンスRAHADR2のrasys/raとしてSQLPLSにログインします。このステップと後続のステップのいくつかは、特に明記されていないかぎりRAHADR2で実行されます。
    $ sqlplus rasys/ra
  2. 保護ポリシーを作成します。
    SQL> exec dbms_ra.create_protection_policy( 
protection_policy_name => 'cdb122dr_PP', 
storage_location_name => 'DELTA', 
recovery_window_goal => numtodsinterval(3,'DAY'), 
unprotected_window => numtodsinterval(1.25,'DAY'), 
allow_backup_deletion => 'NO');

PL/SQL procedure successfully completed.
  3. (この例の)データベースとその保護ポリシーを、リカバリ・アプライアンスによる保護の対象のリストに追加します。
    SQL> exec dbms_ra.add_db(
db_unique_name => 'cdb122dr', 
protection_policy_name=> 'cdb122dr_PP', 
reserved_space => '1T');

PL/SQL procedure successfully completed.
  4. レプリケーション・ユーザーに(この例の)データベースへのアクセス権を付与します。
    SQL> exec dbms_ra.grant_db_access(
username => 'REPUSER_FROM_HADR1',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.
  5. アップストリーム・リカバリ・アプライアンスRAHADR1のrasys/raとしてsqlplusにログインします。このステップと後続のすべてのステップがRAHADR1で実行されます。
    $ sqlplus rasys/ra
  6. 保護ポリシーを作成します。保護ポリシー名は一意である必要はありません。
    SQL> exec dbms_ra.create_protection_policy( 
protection_policy_name =>'cdb122dr_PP', 
storage_location_name => 'DELTA', 
recovery_window_goal => numtodsinterval(3,'DAY'), 
unprotected_window => numtodsinterval(5,'MINUTE'), 
allow_backup_deletion => 'NO');

PL/SQL procedure successfully completed.
  7. (この例の)データベースとその保護ポリシーを、リカバリ・アプライアンスによる保護の対象のリストに追加します。
    SQL> exec dbms_ra.add_db(
db_unique_name => 'cdb122dr', 
protection_policy_name=> 'cdb122dr_PP', 
reserved_space => '1T');

PL/SQL procedure successfully completed.
  8. レプリケーション・ユーザーに(この例の)データベースへのアクセス権を付与します。
    SQL> exec dbms_ra.grant_db_access(
username => 'HADR_LOCAL_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.
  9. レプリケーション・サーバーに保護ポリシーを追加します。このステップはアップストリーム・リカバリ・アプライアンス(RAHADR1)で実行されます。2つのリカバリ・アプライアンス間の循環参照を回避するために、このステップはダウンストリーム・リカバリ・アプライアンスで実行されませんでした。
    SQL> exec dbms_ra.add_replication_server( 
replication_server_name =>'RAHADR2_REP', 
protection_policy_name => 'cdb122dr_PP');

PL/SQL procedure successfully completed.
アップストリーム・リカバリ・アプライアンスでの保護されたデータベースの登録

このタスクでは、ウォレットを構成し、VPCユーザー資格証明を追加し、それらの資格証明をテストし、保護されたデータベースをアップストリーム・リカバリ・アプライアンスに登録します。RACデータベースの場合は、保護されたデータベースが実行されている各ホストでこのステップを実行する必要があります。

ここで使用される操作およびネーミング規則は、Enterprise Managerのものと同じです。
  1. 適切なリカバリ・アプライアンスに接続するためにRMANが使用するsqlnet.oraファイルを構成します。正しいディレクトリに移動します。
    $ cd ${ORACLE_HOME}/network/admin
  2. sqlnet.oraファイルを編集し、次のパラメータが正しく設定されていることを確認します。
    SQLNET.WALLET_OVERRIDE = true

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)

WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra)
    )
  )

SQLNET.EXPIRE_TIME = 10
  3. 各VPCユーザー資格証明を格納するレプリケーション・ウォレットを作成します。このステップは、レプリケーション・ウォレットが存在しない場合のみ実行します。各ホストで、次の手順を実行します。
    $ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createALO
  4. RMANで使用される3つの資格証明ごとに資格証明別名を作成します。各ホストで、mkstoreコマンドを実行します。プロンプトが表示されたら、適切なパスワードを入力します。
    $ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createCredential dr_rahadr2 hadr_local_vpcuser hadr2_L0cal_Pa55w0rd

$ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createCredential dr_rahadr1 hadr_local_vpcuser hadr1_L0cal_Pa55w0rd

$ mkstore -wrl file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra -
createCredential dr_rahadr hadr_common_vpcuser c0mm0n_Pa55w0rd
  5. 資格証明別名のみを使用して各ターゲットにログインして、資格証明が正しく機能していることを確認します。各ホストで、次のように実行します。
    $ sqlplus /@dr_rahadr1
  6. 保護されたデータベースをRAHADR1のリカバリ・アプライアンスに登録します。いずれかのホストで、次のように実行します。
    $ rman target / catalog /@dr_rahadr1

RMAN> register database;
  7. 現在の制御ファイルのテスト・バックアップをリカバリ・アプライアンスhadr1 (RAHADR1)に対して実行します。保護されたデータベースのホストで、現在の制御ファイルのバックアップを実行します。
    $ rman target / catalog /@dr_rahadr1

RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%U' PARMS
"SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/z
dlra credential_alias=dr_rahadr1')";

RMAN> backup device type sbt current controlfile tag 'controltest';

Starting backup at 05-JUN-18
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=2320 instance=cdb122dr1 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (RAHADR1)
SID=6DE9FE3D49ED4598E05311F3850AC59F
allocated channel: ORA_SBT_TAPE_2
channel ORA_SBT_TAPE_2: SID=2516 instance=cdb122dr1 device type=SBT_TAPE
channel ORA_SBT_TAPE_2: RA Library (RAHADR1)
SID=6DE9FE48D84C48C8E05311F3850A89BE
channel ORA_SBT_TAPE_1: starting full datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_SBT_TAPE_1: starting piece 1 at 05-JUN-18
channel ORA_SBT_TAPE_1: finished piece 1 at 05-JUN-18
piece handle=CDB122DR_2kt4m80u_1_1 tag=CONTROLTEST comment=API Version
2.0,MMS Version 3.17.1.26
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:15
Finished backup at 05-JUN-18
Starting Control File and SPFILE Autobackup at 05-JUN-18
piece handle=c-3244939197-20180605-00 comment=API Version 2.0,MMS Version
3.17.1.26
Finished Control File and SPFILE Autobackup at 05-JUN-18
  8. 作成したバックアップ・セットをリストします。制御ファイルのコピーが2つあり、1つはリカバリ・アプライアンスhadr1 (RAHADR1)に、もう1つはリカバリ・アプライアンスhadr2 (RAHADR2)にあることを確認します。
    RMAN> list backupset tag CONTROLTEST;

List of Backup Sets
===================
BS Key Type LV Size
------- ---- -- ----------
220 Full 138.75M
Control File Included: Ckp SCN: 9076177 Ckp time: 05-JUN-18
Backup Set Copy #1 of backup set 220
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
SBT_TAPE 07:00:21 05-JUN-18 NO CONTROLTEST
List of Backup Pieces for backup set 220 Copy #1
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
221 1 AVAILABLE Recovery Appliance (RAHADR1)
CDB122DR_2kt4m80u_1_1
Backup Set Copy #2 of backup set 220
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
SBT_TAPE 07:00:21 05-JUN-18 NO CONTROLTEST
List of Backup Pieces for backup set 220 Copy #2
BP Key Pc# Status Media Piece Name
------- --- ----------- ----------------------- ----------
246 1 AVAILABLE Recovery Appliance (RAHADR2)
RA_SBT_CDB122DR_3244939197_230_2kt4m80u_1_2_220
アップストリームおよびダウンストリーム・リカバリ・アプライアンスへの残りの権限の追加

このタスクでは、アップストリームとダウンストリームの両方のリカバリ・アプライアンスでVPCユーザーにアクセス権を付与します。

  1. RAHADR1で、残りの1つのVPCユーザーにアクセス権を追加します。
    SQL> exec dbms_ra.grant_db_access(
username => 'HADR_COMMON_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.
  2. RAHADR2で、残りの2つのVPCユーザーにアクセス権を追加します。これらのユーザーは、RAHADR1が使用できないことに起因するバックアップのフェイルオーバー時に事前設定されます。
    SQL> exec dbms_ra.grant_db_access(
username => 'HADR_LOCAL_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.

SQL> exec dbms_ra.grant_db_access(
username => 'HADR_COMMON_VPCUSER',
db_unique_name => 'cdb122dr');

PL/SQL procedure successfully completed.
  3. 資格証明別名のみを使用して各ターゲットにログインして、資格証明が正しく機能していることを確認します。各ホストで、次のように実行します。
    $ sqlplus /@dr_rahadr2

$ sqlplus /@dr_rahadr
チャネル・デバイス・パラメータの構成

このタスクでは、DR_RAHADR別名で使用するチャネル・デバイス・パラメータを構成します。

  1. 保護されたデータベースのホストのいずれかで、次のように実行します。
    $ rman target / catalog /@dr_rahadr1

RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%U' PARMS
"SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/z
dlra credential_alias=dr_rahadr')";
  2. (オプション)次のパラメータを構成します。これらのパラメータはベスト・プラクティスの推奨事項です。
    RMAN> CONFIGURE BACKUP OPTIMIZATION on;

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP on;

RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;

RMAN> CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 2 BACKUP TYPE TO BACKUPSET;

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+RECOC1/cdb122dr/snapcf.f';

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO backed up 1 times to device
type sbt;

アップストリームおよびダウンストリーム・リカバリ・アプライアンスの構成

このタスクでは、バックアップ用のホスト固有のファイルを作成し、それぞれのホストにスクリプトをロードして、資格証明を検証します。

  1. アップストリーム・リカバリ・アプライアンスのホストで、次の内容のbackup_database_rahadr1.rmanテキスト・ファイルを作成します。
    {
allocate channel rahadr1_sbt_1 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

allocate channel rahadr1_sbt_2 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

backup
  tag '&1'
  cumulative incremental level 1
  filesperset 1
  section size 64g
  database
    plus archivelog
      not backed up
      filesperset 32
      delete input;
}
  2. ダウンストリーム・リカバリ・アプライアンスのホストで、次の内容のbackup_database_rahadr2.rmanテキスト・ファイルを作成します。
    {
allocate channel rahadr2_sbt_1 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr2')";

allocate channel rahadr1_sbt_2 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr2')";

backup
  tag '&1'
  cumulative incremental level 1
  filesperset 1
  section size 64g
  database
    plus archivelog
      not backed up
      filesperset 32
      delete input;
}
  3. まずRAHADR1のスクリプトの削除を試行して、それが存在しないことを確認してください。次に、HADR1スクリプトをリカバリ・アプライアンスRAHADR1にロードします。
    $ rman target / catalog /@dr_rahadr1

RMAN> delete script backup_database;

RMAN> create script backup_database from file
'/home/oracle/backup_database_rahadr1.rman';
  4. まずRAHADR2のスクリプトの削除を試行して、それが存在しないことを確認してください。次に、HADR2スクリプトをリカバリ・アプライアンスRAHADR2にロードします。
    $ rman target / catalog /@dr_rahadr2

RMAN> delete script backup_database;

RMAN> create script backup_database from file
'/home/oracle/backup_database_rahadr2.rman';
  5. 資格証明にデータベースへのアクセス権があることを確認してください。
    $ rman target / catalog /@dr_rahadr

RMAN> print script backup_database;

printing stored script: backup_database
{
allocate channel rahadr1_sbt_1 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

allocate channel rahadr1_sbt_2 device type sbt
  format '%d_%U'
  PARMS="SBT_LIBRARY=/u01/app/oracle/product/12.2.0.1/dbhome_1/lib/libra.so,
  ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.2.0.1/dbhome_1/dbs/zdlra
  credential_alias=dr_rahadr1')";

backup
  tag '&1'
  cumulative incremental level 1
  filesperset 1
  section size 64g
  database
    plus archivelog
      not backed up
      filesperset 32
      delete input;
}

バックアップ操作

このタスクでは、backup_databaseスクリプトを起動します。

次のRMANコマンドは、保護されたデータベースで実行する必要があり、すべてのRMANバックアップ操作に使用する必要があります。

ノート:

スクリプトが実行されると、チャネル割当てによって、ログインしているリカバリ・アプライアンスとリカバリ・アプライアンス・データベース名が示されます。
  1. RMANを起動します
    $ rman target / catalog /@dr_rahadr
  2. backup_databaseスクリプトを起動します。RAHADR1が実行中の場合、スクリプトはRAHADR1にログインします。それ以外の場合、スクリプトはRAHADR2にログインします。
    RMAN> run { execute script backup_database using 'Level1'; }

executing script: backup_database

allocated channel: rahadr1_sbt_1
channel rahadr1_sbt_1: SID=1936 instance=cdb122dr1 device type=SBT_TAPE
channel rahadr1_sbt_1: RA Library (RAHADR1)
SID=6DEA2A958DFBE0CFE05311F3850AB3AB

allocated channel: rahadr1_sbt_2
channel rahadr1_sbt_2: SID=394 instance=cdb122dr1 device type=SBT_TAPE
channel rahadr1_sbt_2: RA Library (RAHADR1)
SID=6DEA2A9CC2BBE0D0E05311F3850AC634

リアルタイムREDOトランスポート

保護されたデータベースのリアルタイムREDOトランスポートは、アップストリーム・リカバリ・アプライアンスを定期的に使用するように構成できますが、アップストリーム・リカバリ・アプライアンスが使用できないときにダウンストリーム・リカバリ・アプライアンスにフェイルオーバーできます。アップストリーム・リカバリ・アプライアンスが再度使用可能になると、REDOトランスポートはダウンストリームの使用からアップストリームの使用に自動的に変更されます。

リアルタイムREDOトランスポート用のVPCユーザーの構成

このタスクでは、REDOトランスポート用のVPCユーザーを設定し、(1) Data Guard Brokerのパラメータの有効化と、(2)ログ・アーカイブ・パラメータの有効化を行います。

  1. redo_transport_userをローカルVPCユーザーに設定します。
    $ sqlplus / as sysdba

SQL> alter system set redo_transport_user=hadr_local_vpcuser;

System altered.
  2. 次の2つのオプションのいずれかを選択します。
オプション1: Data Guard Brokerを使用したリアルタイムREDOトランスポートの構成

このタスクでは、アップストリーム・リカバリ・アプライアンスからダウンストリームへのリアルタイムREDOトランスポートのフェイルオーバーを確立するData Guard Brokerパラメータを有効にします。

  1. SQLPLUSセッションからsysdbaとしてdg_broker*パラメータを有効にします。
    $ sqlplus / as sysdba

SQL> alter system set
dg_broker_config_file1='+DATAC1/cdb122dr/dr1cdb122dr.dat';
System altered.

SQL> alter system set
dg_broker_config_file2='+DATAC1/cdb122dr/dr2cdb122dr.dat';
System altered.

SQL> alter system set dg_broker_start=true;
System altered.
  2. プライマリ・データベース、リカバリ・アプライアンスの接続識別子、ネットワーク・タイムアウト、および障害の最大数に関してData Guard Brokerを構成します。最後に、構成の変更を有効にします。
    $ dgmgrl sys/myPassword

DGMGRL for Linux: Release 12.2.0.1.0 - Production on Tue Jun 5 11:37:44 2018

Copyright (c) 1982, 2017, Oracle and/or its affiliates. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected to "cdb122dr"
Connected as SYSDG.

DGMGRL> create configuration cdb122dr as primary database is cdb122dr connect
identifier is '//scam06-scan3/cdb122dr';
Configuration "cdb122dr" created with primary database "cdb122dr"

DGMGRL> add recovery_appliance rahadr1 as connect identifier is 'dr_rahadr1';
Recovery Appliance "rahadr1" added

DGMGRL> add recovery_appliance rahadr2 as connect identifier is 'dr_rahadr2';
Recovery Appliance "rahadr2" added

DGMGRL> edit recovery_appliance rahadr1 set property MaxFailure=1;
Property "maxfailure" updated

DGMGRL> edit recovery_appliance rahadr1 set property ReopenSecs=10;
Property "reopensecs" updated

DGMGRL> edit recovery_appliance rahadr1 set property NetTimeout=8;
Property "nettimeout" updated

DGMGRL> edit recovery_appliance rahadr2 set property MaxFailure=1;
Property "maxfailure" updated

DGMGRL> edit recovery_appliance rahadr2 set property NetTimeout=8;
Property "nettimeout" updated

DGMGRL> edit database cdb122dr set property RedoRoutes = '(LOCAL : (rahadr1
async priority=1, rahadr2 async priority=2))';
Warning: ORA-16677: Standby database has the same or higher priority than
other members specified in the RedoRoutes group.
Property "redoroutes" updated

DGMGRL> enable configuration;
Enabled.

ノート:

REDOトランスポートが開始しない場合は、保護されたデータベースのバウンスが必要になることがあります。RACデータベースの場合、これはローリング方式で実行できます。
オプション2: log_archive*パラメータを使用したリアルタイムREDOトランスポートの構成

このタスクでは、アップストリーム・リカバリ・アプライアンスからダウンストリームへのリアルタイムREDOトランスポートのフェイルオーバーを確立する、いくつかのlog_archive*パラメータを手動で変更します。

  • rasys/raとしてsqlplusにログインし、プライマリ・データベース、リカバリ・アプライアンスの接続識別子、ネットワーク・タイムアウト、および障害の最大数に関するいくつかのパラメータを変更します。最後に、構成の変更を有効にします。
    $ sqlplus rasys/ra

SQL> alter system set log_archive_config =
'dg_config=(cdb122dr,rahadr1,rahadr2)';

SQL> alter system set log_archive_dest_2='service=dr_rahadr1 ASYNC NOAFFIRM
delay=0 optional compression=disable max_failure=1 max_connections=1
reopen=10 db_unique_name=rahadr1 net_timeout=8 group=1 priority=1
valid_for=(online_logfile,all_roles)';

SQL> alter system set log_archive_dest_3='service=dr_rahadr2 ASYNC NOAFFIRM
delay=0 optional compression=disable max_failure=1 max_connections=1
reopen=300 db_unique_name=rahadr2 net_timeout=8 group=1 priority=2
valid_for=(online_logfile,all_roles)';

SQL> alter system set log_archive_dest_state_2=enable;

SQL> alter system set log_archive_dest_state_3=enable;

ノート:

REDOトランスポートが開始しない場合は、保護されたデータベースのバウンスが必要になることがあります。RACデータベースの場合、これはローリング方式で実行できます。

HADRのレプリケーション・モード

レプリケートされたリカバリ・アプライアンスを含む高可用性障害回復シナリオを示します。

図15-1では、2つのデータ・センターが示されており、1つはローカルで1つはリモートです。それぞれのデータ・センターには、レプリケーション・ペア、つまり双方向レプリケーションとして構成されたリカバリ・アプライアンスRA-xとRA-yがあります。

ローカル・データ・センターのデータベースは、通常どおり、バックアップおよびREDOログをRA-xに送信します。次に、RA-xは、バックアップおよびREDOログをリモート・ローカル・データ・センターのRA-yにレプリケートします。ローカルRA-xがオフラインになると、バックアップとREDOはリモートRA-yにリダイレクトされ、両方のデータ・センターへの完全リカバリが可能になります。RA-xがオンラインに戻ると、リモートRA-yはバックアップをローカルRA-xにレプリケートして、現在の状態と同期させます。

この例では、リモート・データ・センターのデータベースからRA-yへのバックアップは、ローカル・データ・センターのRA-xにレプリケートされません。

図15-1 2つのリカバリ・アプライアンスにレプリケートされたバックアップ

図15-1の説明が続きます
「図15-1 2つのリカバリ・アプライアンスにレプリケートされたバックアップ」の説明

Data Guardの場所を問わないバックアップ・モード

場所を問わないバックアップがData Guardをどのようにサポートしているかを示します。

図15-2に、ローカルとリモートの2つのデータ・センターを示します。ここで、プライマリ・サイト(アップストリーム)はローカルRA-xであり、スタンバイ・サイト(ダウンストリーム)はリモートRA-yです。ローカル・データ・センターのデータベースは、通常どおり、プライマリ・バックアップおよびログをRA-xに送信します。request_onlyモードでは、アップストリームとダウンストリームの間にアクティブなレプリケーションはありません。レプリケーションは、停止後にギャップを埋めるためにアップストリームRA-xによってバックアップが要求された場合にのみ発生します。Data GuardおよびREDOログは、リモート・データベースとローカル・データベースの同期を維持します。

フェイルオーバーまたはスイッチオーバーが実行されると、リモート・データベースが新しいプライマリになり、REDOをバックアップしてRA-yに送信します。一方、レプリケーションの逆向きは、バックアップおよびログに対してRA-yからRA-xに自動的に行われます。RA-yの同期に必要なすべてのバックアップはRA-xからレプリケートされますが、新しいプライマリ・バックアップおよびREDOはRA-yに通常どおりにレプリケートされます。最初の完全バックアップはレプリケートされないため、WANの消費が削減されます。

図15-2 Data Guardの場所を問わないバックアップ・モード

図15-2の説明が続きます
「図15-2 Data Guardの場所を問わないバックアップ・モード」の説明

Data Guardの一般的なユースケースでは、1つのデータベースでのみバックアップを作成します。これは、バックアップが影響を受ける可能性がある本番ワークロードがプライマリ・データベースで実行されている場合です。かわりに、スタンバイ・データベースからそのリカバリ・アプライアンス(RA-y)にバックアップが作成されます。RA-yからRA-xへのレプリケーションでは、同期が維持されます。

Data GuardのRequest_Onlyモード

レプリケーションのrequest_onlyモードでData Guardがどのようにサポートされるかを示します。

request_onlyモードの目的は、リカバリ・アプライアンスがオフライン期間後などにバックアップのギャップを埋めるために、ペアの2番目のリカバリ・アプライアンスからバックアップをリクエストできるようにすることです。図15-3に、ローカルとリモートの2つのデータ・センターを示します。ここで、プライマリ・サイトはローカルRA-xであり、スタンバイ・サイトはリモートRA-yです。バックアップはプライマリ・データベースとスタンバイ・データベースで作成され、それぞれがそれぞれのローカル・リカバリ・アプライアンスに保存されます。request_onlyモードでは、RA-xからRA-yへのレプリケーション・トラフィックは発生しません。Data GuardおよびREDOログは、リモート・データベースとローカル・データベースの同期を維持します。

レプリケーション・サーバーは、双方向レプリケーション用に構成されています。add_replication_serverを使用すると、RA-yは通常どおり保護ポリシーを取得します。ただし、RA-xのadd_replication_serverには、REQUEST_ONLY=TRUEの保護ポリシーがあります。

プライマリ(ローカル)からセカンダリ(リモート)へのスイッチオーバーが発生した場合、RA-xからRA-yへのレプリケーション・トラフィックは発生しません。ただし、RA-xカタログではRA-yバックアップとの同期が維持されます。RA-xがオフラインの場合、スタンバイ・バックアップは引き続きRA-yに送信され、両方のデータ・センターへの完全リカバリが可能です。RA-xがオンラインに戻ると、RA-xは現在の状態と同期するために、RA-yから欠落しているバックアップを要求します。

図15-3 場所を問わないバックアップのレプリケーション・リクエスト・モード

図15-3の説明が続きます
「図15-3 場所を問わないバックアップのレプリケーション・リクエスト・モード」の説明

新しいデータ・センターへの移行時のレプリケーション読取り専用モード

レプリケーション読取り専用モードで、あるデータ・センターから別のデータ・センターへの移行がどのようにサポートされているか、およびダウンストリーム・リカバリ・アプライアンス上の既存のバックアップにアップストリーム・リカバリ・アプライアンスから読取り専用でアクセスする方法を示します。

図15-4に、RA-xにバックアップするローカル・データ・センターのデータベースを示します。この例では、すべてのローカル・データベースをリモート・データ・センターに移動する必要があり、RA-xは廃止されます。

リモート・データ・センターのデータベースは、RA-xからクローニングすることで作成されます。次に、レプリケーション・サーバーがアップストリームとしてRA-yに作成され、ダウンストリームとしてRA-xに作成されます。RA-yでは、READ_ONLY=TRUEを使用して保護ポリシーがレプリケーション・サーバーに追加されます。

リモート・データ・センターのデータベースがRA-yへのバックアップを開始します。データベースをリカバリする必要がある場合、RA-xのバックアップが不要になってRA-xが廃止されるまで、ローカル・データ・センターRA-xのバックアップはRA-yを介してアクセス可能なままになります。

図15-4 場所を問わないバックアップの読取り専用モード

図15-4の説明が続きます
「図15-4 場所を問わないバックアップの読取り専用モード」の説明