1. 管理者ガイド
  2. リカバリ・アプライアンスの管理
  3. リカバリ・アプライアンスでのバックアップのレプリケート

14 リカバリ・アプライアンスでのバックアップのレプリケート

この章では、障害回復のためのリカバリ・アプライアンスのレプリケーションの目的について説明し、レプリケーション・トポロジの例を示します。また、Cloud Controlを使用してレプリケーションを構成する方法、およびDBMS_RAを使用してレプリケーションを構成する方法について説明します。この章には次の項が含まれます。

リカバリ・アプライアンス・レプリケーションについて

障害回復戦略の一部として、リカバリ・アプライアンスでは他のリカバリ・アプライアンスにバックアップをレプリケートできます。また、テープ・アーカイブをレプリケートされたリカバリ・アプライアンスにオフロードすることで、プライマリ・リカバリ・アプライアンスのリソースを解放できます。レプリケーションは保護ポリシーによって制御されます。すなわち、ポリシーに関連付けられているすべてのデータベースが、初期設定後、完全に自動的にレプリケートされます。

リカバリ・アプライアンス・レプリケーション専用のレプリケーション・ユーザー・アカウントを作成し、組織内の各アップストリーム・アプライアンスには一意のレプリケーション・ユーザー・アカウントを作成する必要があります。

Oracleでは、レプリケーション・ユーザー・アカウントの形式はREPUSER_FROM_[ZDLRA_DB_NAMEまたはZDLRA_DB_LOCATION]_TO_[ZDLRA_DB_NAMEまたはZDLRA_DB_LOCATION]にすることをお薦めします。

たとえば、2つのリカバリ・アプライアンスのDB_UNIQUE_NAMEがZDLRA1およびZDLRA2の場合、レプリケーション・ユーザー・アカウントはREPUSER_FROM_ZDLRA1_TO_ZDLRA2およびREPUSER_FROM_ZDLRA2_TO_ZDLRA1のようになります。または、同じ2つのリカバリ・アプライアンスがFlorenceおよびViennaにある場合、レプリケーション・ユーザー・アカウントはREPUSER_FROM_FLORENCE_TO_VIENNAおよびREPUSER_FROM_VIENNA_TO_FLORENCEのようになります。

レプリケーション・ユーザー・アカウントは、リカバリ・アプライアンスへの接続やバックアップの送信を行うために保護されたデータベースが使用する通常のVPCユーザーとして使用しないでください。

この項には次のトピックが含まれます:

関連項目:

「セキュア・レプリケーション」および「リカバリ・アプライアンス・レプリケーション」

リカバリ・アプライアンス・レプリケーションの概要

図14-1の簡易なレプリケーション・トポロジでは、保護されたデータベースがあるリカバリ・アプライアンスにバックアップを送信し、そのリカバリ・アプライアンスが他のリカバリ・アプライアンスにバックアップを渡します。このトポロジを一方向リカバリ・アプライアンス・レプリケーションと呼びます。1つめのリカバリ・アプライアンスはアップストリーム・リカバリ・アプライアンスで、2つめはダウンストリーム・リカバリ・アプライアンスです。

図14-1 単純なレプリケーション・トポロジ

図14-1の説明が続きます
「図14-1 単純なレプリケーション・トポロジ」の説明

この項には次のトピックが含まれます:

レプリケーションの保護ポリシー

保護されたデータベースのレプリケーションが行われるのは、次の条件が満たされる場合です。

  • アップストリーム・リカバリ・アプライアンスで、レプリケーション・サーバー構成によってダウンストリーム・リカバリ・アプライアンスとして動作するリカバリ・アプライアンスが指定されていること(CREATE_REPLICATION_SERVER)。

  • アップストリーム・リカバリ・アプライアンスで、保護ポリシーがレプリケーション・サーバー構成に関連付けられていること(ADD_REPLICATION_SERVER)。

  • アップストリーム・リカバリ・アプライアンスで、レプリケーション・サーバー構成に関連付けられている保護ポリシーに保護されたデータベースが割り当てられていること(ADD_DB)。

  • ダウンストリーム・リカバリ・アプライアンスで、レプリケートされたバックアップの保護ポリシーが存在し(CREATE_PROTECTION_POLICY)、保護されたデータベースがそれに追加されていること(ADD_DB)。

アップストリーム・リカバリ・アプライアンスで保護ポリシーの構成が完了すると、リカバリ・アプライアンスはポリシーで保護されている各データベースの最新の全体バックアップのみをただちにレプリケートします。バックアップは、受信された直近のレベル0バックアップか、受信された直近のレベル1バックアップに基づいた仮想全体バックアップのいずれか新しい方です。アップストリーム・リカバリ・アプライアンスは、新しいバックアップを受け取るとそれをレプリケートします。

レプリケーション・トポロジの例

レプリケーション・トポロジは、必要だけ複雑にすることができます。主な変数は、次のとおりです。

  • レプリケーション環境内のリカバリ・アプライアンスの合計数および相互の関係

  • 送信レプリケート済バックアップを管理するアップストリーム・リカバリ・アプライアンスの保護ポリシー(CREATE_PROTECTION_POLICY)、および受信レプリケート済バックアップを管理するダウンストリーム・リカバリ・アプライアンスのポリシー

  • レプリケーション環境内の各リカバリ・アプライアンスのレプリケーション・サーバー構成(CREATE_REPLICATION_SERVER)

  • レプリケーション・サーバー構成と保護ポリシーとの関連付け(ADD_REPLICATION_SERVER)

アップストリーム・リカバリ・アプライアンスが複数のダウンストリーム・リカバリ・アプライアンスにレプリケートし、ダウンストリーム・リカバリ・アプライアンスが複数のアップストリーム・リカバリ・アプライアンスからバックアップを受け取るように、レプリケーションをチェーンすることができます。ダウンストリーム・リカバリ・アプライアンスは、自らの保護されたデータベースとレプリケートされたバックアップの両方からバックアップを受け取ることができます。レプリケーション・トポロジ内のすべてのリカバリ・アプライアンスは、アップストリーム・レプリケーション・ロールとダウンストリーム・レプリケーション・ロールを同時に実行できます。

ノート:

リカバリ・アプライアンスがアップストリームとダウンストリームの両方である場合、両方のロールに対して構成する必要があります。

1つのダウンストリーム・リカバリ・アプライアンスへのレプリケーション

図14-2に、reppolicy_us_bronze保護ポリシー(orcl08、orcl09およびorcl10)に関連付けられている3つのデータベースと、reppolicy_us_gold保護ポリシー(orcl11、orcl12およびorcl13)に関連付けられている3つのデータベースを示します。reppolicy_us_goldのみがus_bost_ds_desmというレプリケーション・サーバー構成に関連付けられています。このトポロジでは、アップストリームZDLRA Bostonはreppolicy_us_goldポリシーによって保護されたデータベースのバックアップのみをダウンストリームZDLRA Des Moinesに転送します。

図14-2 1つのリカバリ・アプライアンスへのデータベースのレプリケート

図14-2の説明が続きます
「図14-2 1つのリカバリ・アプライアンスへのデータベースのレプリケート」の説明
複数のダウンストリーム・リカバリ・アプライアンスへのレプリケーション

保護されたデータベースそれぞれに独自の保護ポリシーがあるため、各ポリシーを異なるレプリケーション・サーバー構成に関連付けることができます。たとえば、図14-3では、reppolicy_us_bronzeポリシーは、reppolicy_us_bronze (orcl08、orcl09およびorcl10)によって保護されたデータベースのバックアップをZDLRA San Franciscoというダウンストリーム・リカバリ・アプライアンスにレプリケートするレプリケーション・サーバー構成us_bost_ds_sfに関連付けられています。reppolicy_us_bronzeポリシーは、reppolicy_us_gold (orcl11、orcl12およびorcl13)によって保護されたデータベースのバックアップをZDLRA Des Moinesというダウンストリーム・リカバリ・アプライアンスにレプリケートするレプリケーション・サーバー構成us_bost_ds_desmに関連付けられています。

図14-3 複数のリカバリ・アプライアンスへのデータベースのレプリケート

図14-3の説明が続きます
「図14-3 複数のリカバリ・アプライアンスへのデータベースのレプリケート」の説明
ダウンストリーム・リカバリ・アプライアンスでの異なるポリシーを使用したレプリケーション

レプリケーション・スキーマの各ダウンストリーム・リカバリ・アプライアンスでは、保護ポリシーによってディスク・リカバリ・ウィンドウ目標と受け取ったバックアップのテープ保存ポリシーが定義されます。ダウンストリーム構成とアップストリーム構成は完全に独立しています。このため、ダウンストリーム・リカバリ・アプライアンスを長期保存バックアップ・リポジトリとして使用するなど、アップストリーム・リカバリ・アプライアンスよりも多くの記憶域および長いリカバリ・ウィンドウでダウンストリーム・リカバリ・アプライアンスを構成することができます。

図14-4は、アップストリーム・リカバリ・アプライアンスのreppolicy_us_bronzeバックアップが、ZDLRA San Franciscoのreppolicy_ds_bronzeポリシーによって保護されていることを示しています。アップストリーム・リカバリ・アプライアンスのreppolicy_us_bronzeバックアップは、ZDLRA Des Moinesのreppolicy_ds_goldポリシーによって保護されています。

図14-4 各リカバリ・アプライアンスの保護ポリシーが異なる場合

図14-4の説明が続きます
「図14-4 各リカバリ・アプライアンスの保護ポリシーが異なる場合」の説明
カスケード型レプリケーション

図14-5に、より複雑なトポロジを示します。データベースorcl11、orcl12およびorcl13は、最も遠いアップストリームであるZDLRA Bostonのreppolicy_us_gold保護ポリシーによって保護されています。reppolicy_us_goldポリシーはこれらのデータベースのバックアップを、すぐ下流のZDLRA Des Moinesにレプリケートします。ただし、ZDLRA Des Moinesには、データベースorcl11およびorcl12を保護するreppolicy_ds_gold1とデータベースorcl13のみを保護するreppolicy_ds_gold2の2つの別個の保護ポリシーがあります。

図14-5 各リカバリ・アプライアンスに異なる保護ポリシーがあるカスケード型レプリケーション

図14-5の説明が続きます
「図14-5 各リカバリ・アプライアンスに異なる保護ポリシーがあるカスケード型レプリケーション」の説明

図14-5では、reppolicy_ds_gold2保護ポリシーはレプリケーション・サーバー構成us_desm_ds_laに関連付けられています。その後、ZDLRA Des Moinesはreppolicy_ds_gold2によって保護されている唯一のデータベースorcl13のバックアップを、最も遠いダウンストリーム・リカバリ・アプライアンスであるZDLRA Los Angelesにレプリケートします。ZDLRA Los Angelesにあるorcl13のバックアップは、reppolicy_dds_goldポリシーによって保護されています。3つ以上のリカバリ・アプライアンスがチェーンにリンクされているこの構成を、カスケード型レプリケーションと呼びます。

リカバリ・アプライアンス間での場所を問わないバックアップのレプリケーション

場所を問わないバックアップのレプリケーションを使用すると、2つのリカバリ・アプライアンスRA-xおよびRA-yで、同じ(または異なる)保護されたデータベースを相互にレプリケートできます。したがって、どちらのリカバリ・アプライアンスにも、バックアップの完全なセットがあります。

rep_backupanywhere.pngの説明が続きます
図rep_backupanywhere.pngの説明

2つのリカバリ・アプライアンスRA-xとRA-yは相互にレプリケートされ、相互にアップストリームでありダウンストリームです。保護されたデータベースDB-aおよびDB-bからのバックアップは、それぞれのアップストリーム・リカバリ・アプライアンスであるRA-xおよびRA-yに送信されます。リカバリ・アプライアンス間でバックアップ状態を同期化するために、新しいバックアップが他の(ダウンストリーム)リカバリ・アプライアンスにレプリケートされます。

高可用性/障害回復(HADR)構成でのこの動作の例については、HADRのレプリケーション・モードを参照してください。

レプリケーション・リクエスト専用モード

リクエスト専用モードのレプリケーションは計画メンテナンスに有用であり、データベース・バックアップ、REDOログおよびアーカイブ・ログの量を減らします。これを、メンテナンスの完了時にデータベースの完全なリカバリ性を再確立するためにリカバリ・アプライアンス間で転送する必要があります。

request_onlyモード・レプリケーションでは、アップストリーム(RA-x)のリカバリ・アプライアンスはプライマリ・データベースのバックアップを受信し、ダウンストリーム(RA-y)はスタンバイ・データベースのバックアップ、REDOログおよびアーカイブ・ログを受信します。計画メンテナンスのためにアップストリームRA-xがオフラインの場合、プライマリ・データベースのREDOログおよびアーカイブ・ログはダウンストリームRA-yにリダイレクトされ、そこでデータベースのリカバリ性を維持するために新しいアーカイブ・ログのバックアップが作成されます。

RA-yはRA-xの停止の影響を受けず、通常どおりスタンバイ・データベースからレベル1のバックアップを受け取ります。RA-yのスタンバイ・バックアップは、プライマリ・データベースのリストアに使用できます。RA-xがオンラインに戻ると、以前にリダイレクトされたすべてのバックアップがダウンストリームRA-yからアップストリームRA-xにレプリケートされ、データベースの完全なリカバリ性が再確立されます。

rep_request.pngの説明が続きます
図rep_request.pngの説明

リクエスト・モードは、「実行されていない間に作成できなかったバックアップをリクエストする機能を持つ読取り専用レプリケーション」と考えることができます。リクエスト・モードは、場所を問わないバックアップを有効にしたテクノロジを使用して構築されますが、場所を問わないバックアップではありません。

ローカルのアーカイブ・ログ・ディレクトリが一杯になるとデータベースがハングする可能性があるため、REDOログおよびアーカイブ・ログはアップストリーム・データベースから取得する重要なデータです。したがって、DB-a上のRMANで安全に削除できるように、これらはRA-yに転送されます。

コマンドRMAN CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP 1 TIMESでは、REDOがRA-yに送信およびバックアップされた場合、RA-xがローカルのアーカイブ・ログを安全に削除して領域を再利用できるようにします。このポリシーが構成されている場合、コマンドRMAN DELETE ARCHIVELOGを使用して、ローカルのアーカイブ・ログ領域を安全に再利用することもできます。

リカバリ・アプライアンス間での読取り専用のレプリケーション

read_onlyレプリケーション・モードは、データベース・バックアップの宛先リカバリ・アプライアンスを元のRA-xから別のRA-yに変更する一方で、RA-x上のバックアップは必要に応じてリストア操作でRA-yから引き続き使用できるようにする際に役立ちます。read_onlyモードのレプリケーション・サーバーは、RA-yの保護ポリシーで構成でき、RA-xをダウンストリームとして指定します。ダウンストリームに存在する、ポリシー内のデータベースのすべてのバックアップは、必要な場合にアップストリームから取得できます。保護ポリシーに従って元のRA-x上の古いバックアップが期限切れになると、RA-yはRA-x上のバックアップを必要としなくなります。これにより、RA-xをバックアップ・シナリオから移行できます。

rep_readonly.pngの説明が続きます
図rep_readonly.pngの説明

read_onlyレプリケーションの重要なユースケースは、ロード・バランシングや古いリカバリ・アプライアンスのデコミッションのために新しいリカバリ・アプライアンスをコミッションする場合など、異なるリカバリ・アプライアンスをデータベース・バックアップの宛先として使用する場合です。これにより、リカバリ・アプライアンス間でバックアップ/リストアを正常に転送できます。

リカバリ・アプライアンスでのバックアップのレプリケート方法: 基本プロセス

保護されたデータベースを永久的増分ポリシーを使用してリカバリ・アプライアンスにバックアップすると想定します。保護されたデータベースが、レプリケーションが構成されたリカバリ・アプライアンスにバックアップを送信すると、次の基本ステップが行われます。

  1. アップストリーム・リカバリ・アプライアンスはバックアップを収集し、レプリケーション・サーバー構成に関連付けられているかどうか保護ポリシーを確認します。

  2. 保護ポリシーのレプリケーション・サーバー構成が存在する場合、アップストリーム・リカバリ・アプライアンスはバックアップをレプリケートします。レプリケーション・プロセスは次のとおりです。

    • メタデータ・レコードを作成して、レプリケートされたレコードを追跡

      ノート:

      リアルタイムREDOトランスポートが有効である場合、受信したREDO変更はリカバリ・アプライアンスによってリアルタイムではレプリケートされません。アーカイブREDOログのバックアップが作成されると、リカバリ・アプライアンスは、このバックアップをデータ・ファイルのバックアップとともにレプリケートします。

    • 指定された各ダウンストリーム・リカバリ・アプライアンスにネットワークを介してデータ・ブロックを転送

  3. ダウンストリーム・リカバリ・アプライアンスはバックアップを収集して、仮想バックアップを作成します。

    ノート:

    ダウンストリームの収集フェーズは、ステップ1で説明した収集フェーズと同じです。このため、ダウンストリーム・リカバリ・アプライアンスもバックアップをレプリケートするように構成されている場合、アップストリーム・リカバリ・アプライアンスのロールを負い、バックアップをすぐ下流のリカバリ・アプライアンスにバックアップします。

  4. その後間もなく、アップストリーム・リカバリ・アプライアンスはダウンストリーム・リカバリ・アプライアンスに調整リクエストを送信し、今度はダウンストリーム・リカバリ・アプライアンスがバックアップに関するメタデータをアップストリーム・リカバリ・アプライアンスに送信します。

    リカバリ・アプライアンス・レプリケーションでは、調整はリカバリ・アプライアンスがすぐ下流のリカバリ・アプライアンスからメタデータを受信するプロセスです。

このため、バックアップがレプリケートされた後は、アップストリームおよびダウンストリーム・リカバリ・カタログの両方が保護されたデータベースのバックアップのレコードを所持します。

RMANがレプリケーション環境でバックアップをリストアする方法

保護されたデータベースをリストアする場合、一般にRMANは当初バックアップを送信した同じリカバリ・アプライアンスにAS CATALOGを接続します。たとえば、図14-2では、RMANがorcl11をリストアする必要がある場合、RMANはアップストリーム・リカバリ・アプライアンス上のカタログに接続します。

バックアップがレプリケーション・スキーマの任意のリカバリ・アプライアンスにある場合、アップストリーム・リカバリ・アプライアンスは他のリカバリ・アプライアンスからバックアップを取得してリストアできます。たとえば、図14-2で、RMANがorcl11をリストアする必要があるが、バックアップがアップストリーム・リカバリ・アプライアンスからパージされている場合、ダウンストリーム・リカバリ・アプライアンスがバックアップをアップストリーム・リカバリ・アプライアンスに提供し、その後にリストアできます。

必要に応じて、RMANはダウンストリーム・リカバリ・アプライアンスから直接バックアップをリストアすることもできます。RMANはAS CATALOGをダウンストリーム・リカバリ・アプライアンスに接続してから、バックアップをリストアします。たとえば、図14-2で、RMANがprod3をリストアする必要があるが、アップストリーム・リカバリ・アプライアンスが一時的にアクセス不可である場合、RMANはダウンストリーム・リカバリ・アプライアンス上のカタログに直接接続して、保護されたデータベース・ホストに直接バックアップをリストアできます。

ノート:

Oracle Enterprise Manager Cloud Control (Cloud Control)またはコマンドラインを使用している場合、ダウンストリーム・リカバリ・アプライアンスからバックアップをリストアするには追加構成が必要です。『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

リカバリ・アプライアンス・レプリケーションのユーザー・インタフェース

この項には次のトピックが含まれます:

Cloud Controlでのレプリケーション・ページへのアクセス

Cloud Controlのレプリケーション・ページは、デリカバリ・アプライアンス・レプリケーションを構成するための推奨インタフェースです。

レプリケーション・ページにアクセスするには:

  1. 「リカバリ・アプライアンスのホームページへのアクセス」の説明に従って、リカバリ・アプライアンスのホームページにアクセスします。

  2. 「リカバリ・アプライアンス」メニューから、「レプリケーション」を選択します。

    図14-6に示すように、レプリケーション・ページが表示されます。

    図14-6 レプリケーション・ページ

    図14-6の説明が続きます
    「図14-6 レプリケーション・ページ」の説明

    上の図では、RADENS14_REPという名前のレプリケーション・サーバーがすでに構成されています。「ステータス」列に使用可能であることが示されます。

レプリケーションに関連するDBMS_RAプロシージャ

DBMS_RAパッケージを使用して、レプリケーションを作成および管理できます。表14-1で、レプリケーションに関連する主なプログラム・ユニットについて説明します。

表14-1 レプリケーションに関連する主なプロシージャ

プログラム・ユニット 説明

CREATE_REPLICATION_SERVER

このリカバリ・アプライアンスによるバックアップのレプリケート先ダウンストリーム・リカバリ・アプライアンスを指定するレプリケーション・サーバー構成を作成します。

DELETE_REPLICATION_SERVER

レプリケーション・サーバー構成を削除します。

ADD_REPLICATION_SERVER

レプリケーション・サーバー構成を、CREATE_REPLICATION_SERVERプロシージャで作成された保護ポリシーに追加します。

REMOVE_REPLICATION_SERVER

レプリケーション・サーバー構成を、CREATE_REPLICATION_SERVERプロシージャで作成された保護ポリシーから削除します。

ADD_DB

保護ポリシーにデータベースを追加します。

CREATE_PROTECTION_POLICY

保護ポリシーを作成します。このポリシーに割り当てられているデータベースのレプリケーションを有効にするには、ADD_REPLICATION_SERVERを実行して、レプリケーション・サーバー構成をこのポリシーに関連付ける必要があります。

UPDATE_DB

保護されたデータベースのプロパティを更新します。

関連項目:

DBMS_RAパッケージのリファレンス

レプリケーションのリカバリ・カタログ・ビュー

リカバリ・アプライアンス・カタログ・ビューを使用して、レプリケーションをモニターできます。表14-2に、レプリケーションに最も有用なビューについてまとめます。

表14-2 レプリケーションのビュー

ビュー 説明

RA_REPLICATION_CONFIG

このビューには、レプリケーション・サーバー構成が表示されます。

RA_REPLICATION_DATABASE

このビューには、レプリケーション・サーバーおよび保護されたデータベースに関する情報が表示されます。

RA_REPLICATION_PAIR

このビューには、保護ポリシーをレプリケートするためのレプリケーション情報がリストされます。

RA_REPLICATION_POLICY

このビューには、レプリケーション・サーバーと保護ポリシーの関連付けがリストされます。

RA_DATABASE

このビューのPOLICY_NAME列に、この保護データベースで使用される保護ポリシーが示されます。REPLICATION_USAGE列に、このデータベースについてレプリケートされたディスク領域の累積量(GB単位)を示します。

RA_PROTECTION_POLICY

このビューは、定義済の保護ポリシーを示します。

関連項目:

リカバリ・アプライアンスのビュー・リファレンス

リカバリ・アプライアンス・レプリケーションを構成するための基本的なタスク

図14-7に、レプリケーションを構成するための基本的なワークフローを示します。「リカバリ・アプライアンスの計画」で、データベースの各サービス層のリカバリ要件を決定するワークフロー内のステージについて説明しています。

図14-7 レプリケーションのワークフロー

図14-7の説明が続きます
「図14-7 レプリケーションのワークフロー」の説明

構成は、Cloud Controlまたはコマンドライン・インタフェースのどちらかを使用して実行できます。ステップがあまり複雑でないため、Cloud Controlを使用することをお薦めします。

Cloud Controlを使用したリカバリ・アプライアンス・レプリケーションの構成

この項では、Cloud Controlでレプリケーション・ページを使用してリカバリ・アプライアンス・レプリケーションを構成する方法を説明します。

前提条件

環境が次の前提条件を満たしている必要があります。

  • アップストリームおよびダウンストリーム・リカバリ・アプライアンスが、ネットワークを超えて相互にやり取りできること。

  • バックアップ・データをレプリケートするすべての保護されたデータベースが、アップストリーム・リカバリ・アプライアンスに登録されていること。

  • ダウンストリーム・リカバリ・アプライアンスが起動され、バックアップを受け取るように構成されていること。

前提条件

リカバリ・アプライアンス環境において、次の文がtrueであると想定します。

  • 保護されたデータベースorcl11とorcl12をアップストリーム・リカバリ・アプライアンスZDLRA Bostonにバックアップします。

  • ZDLRA Bostonをダウンストリーム・リカバリ・アプライアンスZDLRA_DEN2にレプリケートするとします。

  • repuser_from_bostonというレプリケーション・ユーザー・アカウントがダウンストリーム・リカバリ・アプライアンス(ZDLRA_DEN2)に存在します。

  • vpc_boston1という仮想プライベート・カタログ・アカウントがアップストリーム・リカバリ・アプライアンス(ZDLRA Boston)に存在します。

  • アップストリーム・リカバリ・アプライアンス (ZDLRA Boston)のデータベース・インストールを所有するオペレーティング・システム・ユーザーの資格証明がわかっています。

リカバリ・アプライアンス・レプリケーションを構成するには:

  1. アップストリーム・リカバリ・アプライアンス上のリカバリ・アプライアンス・ホームページにアクセスします。「リカバリ・アプライアンス・ホームページへのアクセス」を参照してください。

  2. アップストリーム・リカバリ・アプライアンス上の「リカバリ・アプライアンス」メニューで「保護ポリシー」を選択して、レプリケーション用に作成します。

    この例では、アップストリーム・リカバリ・アプライアンスであるZDLRA Bostonの「保護ポリシーの作成」ページにアクセスします。

    必要に応じて、ログイン資格証明を入力してから、「ログイン」をクリックします。

    「保護ポリシー」ページが表示されます。

  3. レプリケーション保護ポリシーを作成します。これは通常の保護ポリシーであり、後でレプリケーションに関連付けられ、保護ポリシーの作成に表示されます。

    図14-8 「保護ポリシーの作成」ページ

    図14-8の説明が続きます
    「図14-8 「保護ポリシーの作成」ページ」の説明

    図14-9 保護ポリシー詳細パラメータ

    図14-9の説明が続きます
    「図14-9 保護ポリシー詳細パラメータ」の説明

    この例では、reppolicy_ds_goldというポリシーを作成します。

  4. アップストリーム・リカバリ・アプライアンス上の「リカバリ・アプライアンス」ドロップダウン・メニューから、「保護されたデータベース」を選択します。

    「保護されたデータベース」ツールバーから「追加」を選択します。「保護されたデータベースの追加」ダイアログ・ボックスが表示されます。

  5. このダイアログ・ボックスから「追加」を選択します。それにより、データベースを検索するための「ターゲットの選択」ツールが提供されます。

    データベースを選択すると、それが「データベース」表に表示されます。他のデータベースについても、これを繰り返すことができます。

  6. 「保護されたデータベースの追加」ダイアログ・ボックスでデータベースを選択した後、適切なレプリケーション・ポリシー(この例でのreppolicy_ds_goldなど)を選択します。

    終了したら、「次」を選択して、レプリケーション保護ポリシー内にそのデータベースのジョブを作成します。

  7. アップストリーム・リカバリ・アプライアンス上の「リカバリ・アプライアンス」ドロップダウン・メニューから、「レプリケーション」を選択します。

    「リカバリ・アプライアンス・ログイン」ページが表示された場合は、ログイン資格証明を入力してから、「ログイン」をクリックします。

    図14-6に示すように、レプリケーション・ページが表示されます。

    前述の例では、レプリケーション・サーバーにZDLRA9_REPという名前が付けられています。

  8. 「レプリケーション」ページで「レプリケーション・サーバーの作成」を選択します。

    レプリケーション・サーバーの作成ページが表示されます。

    図14-10 「レプリケーション・サーバーの作成」ページ

    図14-10の説明が続きます
    「図14-10 「レプリケーション・サーバーの作成」ページ」の説明

  9. 次のように値を入力して、「OK」をクリックします。

    • 「ダウンストリーム・リカバリ・アプライアンス」フィールドで拡大鏡をクリックし、検出されたターゲットのリストからダウンストリーム・ロールで構成するリカバリ・アプライアンスを選択します。

      たとえば、ZDLRA_DEN2を選択します。

    • 「ダウンストリーム・リカバリ・アプライアンス・データベース資格証明」セクションで、ダウンストリーム・リカバリ・アプライアンス上の仮想プライベート・カタログ・アカウントの資格証明を指定します。

      ノート:

      このカタログ・アカウントには、レプリケートされたバックアップをダウンストリーム・リカバリ・アプライアンス上で管理する権限が付与されている必要があります。racli add db_userを参照してください。

      たとえば、vpc_den2と入力します。

    • アップストリーム・リカバリ・アプライアンス・データベース資格証明セクションで、アップストリーム・リカバリ・アプライアンスのデータベース・インストールを所有するオペレーティング・システム・ユーザーの資格証明を指定します。

    ジョブ発行IDを示す情報メッセージが表示されます。

  10. 「レプリケーション」ページ内のリストに新しいレプリケーション・サーバーが表示されたら、「保護ポリシーの追加」を選択します。

    この例では、レプリケーション・サーバーに追加するreppolicy_ds_goldという名前のポリシーを作成しました。

アップストリーム・リカバリ・アプライアンスでレプリケーション・サーバーを構成すると、ダウンストリーム・リカバリ・アプライアンスのポリシーと構成が処理されます。

DBMS_RAを使用したリカバリ・アプライアンスでのレプリケーションの構成

この項では、コマンドライン・ツールを使用してレプリケーションを構成する方法について説明します。基本的なワークフローは次のとおりです。

  1. 「DBMS_RAを使用したダウンストリーム・リカバリ・アプライアンスでのレプリケーションの構成」の説明に従って、ダウンストリーム・リカバリ・アプライアンスを構成します。

  2. 「DBMS_RAを使用したアップストリーム・リカバリ・アプライアンスでのレプリケーションの構成」の説明に従って、アップストリーム・リカバリ・アプライアンスを構成します。

  3. 「リカバリ・アプライアンス・レプリケーションのための保護されたデータベースの構成」に説明されているとおりに、レプリケーションに関与する保護されたデータベースを構成します。

  4. 「リカバリ・アプライアンスのレプリケーション・サーバー構成のテスト」に説明されているとおりに、レプリケーションをテストします。

図14-11は、構成フェーズを図示したものです。

図14-11 レプリケーションの手動構成の概要

図14-11の説明が続きます
「図14-11 レプリケーションの手動構成の概要」の説明

レプリケーション例の仮定

次に続くレプリケーション・タスクでは、次の条件がtrueであると想定します。

  • データベースorcl11とorcl12を、アップストリーム・レプリケーション・ロールで構成するZDLRA Bostonというリカバリ・アプライアンスにバックアップします。

  • ZDLRA Des Moinesをダウンストリーム・リカバリ・アプライアンスとして使用します。

  • ダウンストリーム・リカバリ・アプライアンスで、repuser_from_bostonというリカバリ・アプライアンス・ユーザー・アカウントを作成します。このアカウントは、レプリケーション・ユーザー・アカウントです。

    ノート:

    このアカウントのネーミング規則は、バックアップのレプリケート元のリカバリ・アプライアンス(この場合、ZDLRA Boston)を使用します。この例の保護ポリシーの名前では、アップストリームにus、ダウンストリームにdsを使用します。

  • ダウンストリーム・リカバリ・アプライアンスで、reppolicy_ds_golという保護ポリシーを作成します。このポリシーは、レプリケーションでのみ使用します。

  • ダウンストリーム・リカバリ・アプライアンスで、vpc_des_moines1という仮想プライベート・カタログ・アカウントを作成します。RMANでは、このアカウントを使用してデータベースorcl11とorcl12をバックアップおよびリストアします。

  • アップストリーム・リカバリ・アプライアンスで、reppolicy_us_goldという保護ポリシーを作成します。このポリシーは、レプリケーションでのみ使用します。

  • アップストリーム・リカバリ・アプライアンスで、vpc_boston1という仮想プライベート・カタログ・アカウントを作成します。RMANでは、このアカウントを使用してデータベースorcl11とorcl12をバックアップおよびリストアします。

DBMS_RAを使用したダウンストリーム・リカバリ・アプライアンスでのレプリケーションの構成

この項では、ダウンストリーム・リカバリ・アプライアンスの構成方法について説明します。

ノート:

リカバリ・アプライアンスにアップストリーム・ロールとダウンストリーム・ロールの両方がある場合、次の手順はダウンストリーム・リカバリ・アプライアンスのロールのみに関係します。

タスク1: ダウンストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントの作成

保護されたデータベースをバックアップまたはリストアする際、RMANはこのアカウントを使用して、ダウンストリーム・リカバリ・アプライアンス上のリカバリ・カタログに接続します。

このタスクでは、ダウンストリーム・リカバリ・アプライアンスでvpc_des_moines1という仮想プライベート・カタログ・アカウントを作成すると想定します。

仮想プライベート・カタログ・アカウントを作成するには:

  • racli add db_userの手順に従います。

    たとえば、次の文を実行してユーザー・アカウントvpc_des_moines1を作成します。 

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

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

関連項目:

仮想プライベート・カタログについてさらに学習するには、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

タスク2: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション保護ポリシーの作成

このダウンストリーム・リカバリ・アプライアンスにレプリケートしたバックアップのリカバリ・ウィンドウおよびその他のプロパティを指定する保護ポリシーを作成するには、DBMS_RA.CREATE_PROTECTION_POLICYを実行します。

このタスクでは、reppolicy_ds_goldポリシーを作成してorcl11およびorcl12データベースを保護すると想定します。後から、このポリシーをリカバリ・アプライアンスに関連付けます。

レプリケーション保護ポリシーを作成するには:

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

  2. DBMS_RA.CREATE_PROTECTION_POLICYプロシージャで保護ポリシーを作成します。

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

    BEGIN
  DBMS_RA.CREATE_PROTECTION_POLICY (
    protection_policy_name => 'reppolicy_ds_gold',
    description            => 'For protected dbs in gold tier',
    storage_location_name  => 'delta',
    recovery_window_goal   => INTERVAL '28' DAY,
    guaranteed_copy        => 'NO');
END;

関連項目:

タスク3: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション・ユーザー・アカウントの作成

保護されたデータベースのバックアップをレプリケートするようダウンストリーム・リカバリ・アプライアンスを構成する場合、アップストリーム・リカバリ・アプライアンスがこのダウンストリーム・リカバリ・アプライアンスへのログインに使用するレプリケーション・ユーザー・アカウントを作成する必要があります。ダウンストリーム・リカバリ・アプライアンス上のユーザーの資格証明はアップストリーム・リカバリ・アプライアンスに格納されています(「タスク5: アップストリーム・リカバリ・アプライアンスでのOracleウォレットの作成」を参照)。

ノート:

管理しやすいように、リカバリ・アプライアンス・レプリケーション専用のレプリケーション・ユーザー・アカウントを作成し、各アップストリーム・アプライアンスには別のレプリケーション・ユーザー・アカウントを作成することをお薦めします。

このタスクでは、アップストリーム・リカバリ・アプライアンスがこのリカバリ・アプライアンスに対する認証に使用するrepuser_from_bostonというアカウントを作成すると想定します。

レプリケーション・ユーザー・アカウントを作成するには:

  1. SQL*PlusまたはSQL Developerで、SYSTEMとしてまたはDBAロールを持つユーザーとして、ダウンストリーム・リカバリ・アプライアンス・データベースに接続します。

  2. レプリケーション・ユーザー・アカウントを作成します。

    たとえば、次のSQL文を実行してrepuser_from_bostonデータベース・ユーザー・アカウントを作成し、CREATE SESSION権限を付与します。 

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

    ノート:

    セキュリティを強化するために非常に複雑なパスワードを使用することをお薦めします。このパスワードおよびユーザー名を後続のステップでOracleウォレットに追加します。これらの資格証明をウォレットに保存すると、パスワードを手動で再入力する必要がなくなります。

関連項目:

データベース・ユーザー・アカウントの作成方法を学習するには、『Oracle Databaseセキュリティ・ガイド』を参照してください。

タスク4: ダウンストリーム・リカバリ・アプライアンスでの保護ポリシーへのデータベースの追加

保護されたデータベースをレプリケーション保護ポリシーに追加するには、DBMS_RA.ADD_DBを実行します。保護されたデータベースごとに予約するディスク領域の量も指定する必要があります。

このタスクでは、データベースorcl11およびorcl12を「タスク2: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション保護ポリシーの作成」で作成したreppolicy_ds_gold保護ポリシーに追加し、保護されたデータベースごとに128GBの予約済領域を割り当てると想定します。

保護ポリシーにデータベースを追加するには:

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

  2. DBMS_RA.ADD_DBプロシージャを使用して、保護されたデータベースごとにメタデータを追加します。

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

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

関連項目:

「ADD_DB」

タスク5: ダウンストリーム・リカバリ・アプライアンスでのデータベース・アクセスの付与

DBMS_RA.GRANT_DB_ACCESSを実行して、次のデータベース・アカウントに保護されたデータベース・アクセスを付与します。

レプリケーションおよびカタログ・アカウントに保護されたデータベース・アクセスを付与するには:

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

  2. このアカウントで認証する必要のあるアップストリーム・リカバリ・アプライアンスにバックアップを送信する保護されたデータベースごとに、レプリケーション・ユーザーに権限を付与します。

    次の例では、レプリケーション・ユーザーrepuser_from_bostonに、保護されたデータベースorcl11およびorcl12で必要な権限を付与します。 

    BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'repuser_from_boston',
    db_unique_name => 'orcl11');
END;
BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'repuser_from_boston',
    db_unique_name => 'orcl12');
END;

  3. このアカウントで認証する必要のある各アップストリーム・リカバリ・アプライアンス上の保護されたデータベースごとに、仮想プライベート・カタログ・アカウントに権限を付与します。

    次の例ではリカバリ・カタログ・アカウントvpc_des_moines1に、保護されたデータベースorcl11およびorcl12で必要な権限を付与します。 

    BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpc_des_moines1',
    db_unique_name => 'orcl11');
END;
BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpc_des_moines1',
    db_unique_name => 'orcl12');
END;

関連項目:

「GRANT_DB_ACCESS」

DBMS_RAを使用したアップストリーム・リカバリ・アプライアンスでのレプリケーションの構成

この項では、アップストリーム・リカバリ・アプライアンスの構成方法について説明します。この項では、「DBMS_RAを使用したダウンストリーム・リカバリ・アプライアンスでのレプリケーションの構成」のステップが完了したと想定します。

ノート:

リカバリ・アプライアンスにアップストリーム・ロールとダウンストリーム・ロールの両方がある場合、次の手順はアップストリーム・ロールのみに関係します。

タスク1: アップストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントの作成

保護されたデータベースをバックアップする際、RMANはこのアカウントを使用して、アップストリーム・リカバリ・アプライアンス上のリカバリ・カタログに接続します。

この項では、アップストリーム・リカバリ・アプライアンスでvpc_boston1という仮想プライベート・カタログ・アカウントを作成すると想定します。

仮想プライベート・カタログ・アカウントを作成するには:

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

    たとえば、次の文を実行してユーザー・アカウントvpc_boston1を作成します。 

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

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

関連項目:

仮想プライベート・カタログについてさらに学習するには、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

DBMS_RA.CREATE_PROTECTION_POLICYを実行して、このアップストリーム・リカバリ・アプライアンスへのバックアップのディスク・リカバリ・ウィンドウおよびその他のプロパティを指定する保護ポリシーを作成します。アップストリーム・リカバリ・アプライアンスは、これらのバックアップをダウンストリーム・リカバリ・アプライアンスにレプリケートします。

このタスクでは、reppolicy_us_goldポリシーを作成してorcl11およびorcl12データベースを保護すると想定します。次のタスクでは、この保護ポリシーを保護されたデータベースに関連付けます。

リカバリ・アプライアンス・レプリケーションの保護ポリシーを作成するには:

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

  2. DBMS_RA.CREATE_PROTECTION_POLICYプロシージャで各保護ポリシーを作成します。

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

    BEGIN
  DBMS_RA.CREATE_PROTECTION_POLICY (
    protection_policy_name => 'reppolicy_us_gold',
    description            => 'For protected dbs in gold tier',
    storage_location_name  => 'delta',
    recovery_window_goal   => INTERVAL '28' DAY,
    guaranteed_copy        => 'NO');
END;

関連項目:

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

保護されたデータベースをレプリケーション保護ポリシーに追加するには、DBMS_RA.ADD_DBプロシージャを実行します。保護されたデータベースごとに予約するディスク領域の量も指定する必要があります。

このタスクでは、データベースorcl11およびorcl12を「タスク2: アップストリーム・リカバリ・アプライアンスでの保護ポリシーの作成」で作成したreppolicy_us_gold保護ポリシーに追加し、保護されたデータベースごとに128GBの予約済領域を割り当てると想定します。

保護ポリシーにデータベースを追加するには:

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

  2. DBMS_RA.ADD_DBプロシージャを使用して、保護されたデータベースごとにメタデータを追加します。

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

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

関連項目:

タスク4: アップストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントへのデータベース・アクセスの付与

「タスク1: アップストリーム・リカバリ・アプライアンスでの仮想プライベート・カタログ・アカウントの作成」で作成したアップストリーム・カタログ・アカウントに、保護されたデータベースのアクセス権を付与するには、DBMS_RA.GRANT_DB_ACCESSを実行します。このステップにより、保護されたデータベースのバックアップまたはリストア時にRMANがリカバリ・カタログに接続できるようになります。

仮想プライベート・カタログに保護されたデータベース・アクセスを付与するには:

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

  2. バックアップをレプリケートする保護されたデータベースごとに、仮想プライベート・カタログ・アカウントに権限を付与します。

    次の例ではカタログ・アカウントvpc_boston1に、保護されたデータベースorcl11およびorcl12で必要な権限を付与します。 

    BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpc_boston1',
    db_unique_name => 'orcl11');
END;
BEGIN
  DBMS_RA.GRANT_DB_ACCESS (
    username       => 'vpc_boston1',
    db_unique_name => 'orcl12');
END;

関連項目:

タスク5: アップストリーム・リカバリ・アプライアンスでのOracleウォレットの作成

アップストリーム・リカバリ・アプライアンスで、mkstoreユーティリティを使用してOracle自動ログイン・ウォレットを作成し、「タスク3: ダウンストリーム・リカバリ・アプライアンスでのレプリケーション・ユーザー・アカウントの作成」で作成したレプリケーション・ユーザー資格証明を追加します。アップストリーム・リカバリ・アプライアンスは、ダウンストリーム・アプライアンスへのログイン時にこれらの資格証明が必要となります。格納されている各資格証明には、リカバリ・アプライアンス・ユーザー・アカウントの名前と検証が含まれます。

ノート:

既存のウォレットが自動ログイン・ウォレットである(ウォレットにアクセスするたびにパスワードを入力する必要がない)場合、それを使用できます。Oracleのファイル拡張子は*.ssoです。既存のOracleウォレットを使用する場合は、下のステップ2をスキップします。

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

  • アップストリーム・リカバリ・アプライアンス・ホストの/dbfs_repdbfs/REPLICATIONディレクトリでレプリケーションに使用するOracleウォレットを作成します。

  • レプリケーション・ユーザーrepuser_from_bostonの資格証明を追加します。

アップストリーム・リカバリ・アプライアンスでOracleウォレットを作成するには:

  1. アップストリーム・リカバリ・アプライアンス・ホストに、リカバリ・アプライアンスをインストールしたオペレーティング・システム・ユーザーまたはそのユーザーのオペレーティング・システム・グループのメンバーとしてログインします。

  2. Oracleウォレットを作成するには、次のコマンドを実行します。wallet_locationは、ウォレットを格納するアップストリーム・リカバリ・アプライアンスの既存のディレクトリです。 

    mkstore -wrl wallet_location -createALO

    たとえば、次のコマンドは/dbfs_repdbfs/REPLICATIONディレクトリに自動ログイン・ウォレットを作成します。 

    mkstore -wrl file:/dbfs_repdbfs/REPLICATION -createALO

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

  3. 資格証明を追加するには、次のコマンドを実行します。

    mkstore -wrl wallet_location -createCredential serv_name ds_rep_user pwd

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

    • wallet_locationは、ウォレットを作成するディレクトリです。ディレクトリは存在している必要があります。

    • serv_nameは、Oracleネットワーク上でダウンストリーム・リカバリ・アプライアンスを識別するためにEZ接続記述子で使用するOracleネットワーク・サービス名です。

    • ds_rep_userは、ダウンストリーム・リカバリ・アプライアンス上のレプリケーション・ユーザー・アカウントのユーザー名です。

    • pwdは、ダウンストリーム・リカバリ・アプライアンス上のレプリケーション・ユーザーのセキュア・パスワードです。

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

    mkstore -wrl file:/dbfs_repdbfs/REPLICATION -createCredential \
"radsm01repl-scan.acme.com:1522/zdlradsm" "repuser_from_boston" "pwd"

  4. Oracleウォレットに資格証明のリストを表示する次のコマンドを実行して、すべてのユーザーの資格証明が正しく追加されたことを確認します(パスワードまたは検証は表示されません)。

    mkstore -wrl wallet_location -listCredential

    たとえば、次のコマンドは/dbfs_repdbfs/REPLICATIONに格納されているOracleウォレット内の資格証明のリストを表示します。 

    mkstore -wrl file:/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: radsm01repl-scan1.acme.com:1522/zdlradsm repuser_from_boston

関連項目:

タスク6: アップストリーム・リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成

DBMS_RA.CREATE_REPLICATION_SERVERを実行して、このアップストリーム・リカバリ・アプライアンスをレプリケートするダウンストリーム・リカバリ・アプライアンスごとにレプリケーション・サーバー構成を作成します。

注意:

ダウンストリーム・リカバリ・アプライアンスで保護ポリシー(ADD_DB)にデータベースを追加してデータベース・アクセス(GRANT_DB_ACCESS)を付与する前に、アップストリーム・リカバリ・アプライアンスでCREATE_REPLICATION_SERVERを実行すると、ORA-*エラーが発生する可能性があります。

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

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

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

  2. ダウンストリーム・リカバリ・アプライアンスごとにDBMS_RA.CREATE_REPLICATION_SERVERプロシージャを実行します。

    次の例では、ZDLRA Des Moinesというダウンストリーム・リカバリ・アプライアンスにzdlradsm_repというレプリケーション・サーバー構成を作成します。 

    BEGIN
  DBMS_RA.CREATE_REPLICATION_SERVER (
    replication_server_name => 'zdlradsm_rep',
    sbt_so_name      => 'libra.so',
    catalog_user_name       => 'RASYS',
    wallet_alias            => 'radsm01repl-scan.acme.com:1522/zdlradsm',
    wallet_path             => 'file:/dbfs_repdbfs/REPLICATION');
END;

  3. レプリケーション・サーバー構成の作成を確認します。

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

    SELECT COUNT(*) should_be_one 
FROM   RA_REPLICATION_CONFIG
WHERE  REPLICATION_SERVER_NAME = 'ZDLRADSM_REP';

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

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

関連項目:

タスク7: アップストリーム・リカバリ・アプライアンスの保護ポリシーとの関連付け

レプリケーション・サーバー構成を保護ポリシーに割り当てることで、保護されたデータベースそれぞれをレプリケートするダウンストリーム・リカバリ・アプライアンスを指定します。このタスクが完了すると、リカバリ・アプライアンス・レプリケーションは有効になります。

ノート:

1つの保護ポリシーに複数のレプリケーション・サーバー構成を割り当てることができます。

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

レプリケーション・サーバー構成を保護ポリシーに関連付けるには:

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

  2. 保護ポリシーとレプリケーション・サーバー構成の組合せごとに、DBMS_RA.ADD_REPLICATION_SERVERプロシージャを実行します。

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

    BEGIN
  DBMS_RA.ADD_REPLICATION_SERVER (
   replication_server_name => 'zdlradsm_rep',
   protection_policy_name  => 'reppolicy_us_gold');
END;

関連項目:

「ADD_REPLICATION_SERVER」

リカバリ・アプライアンス・レプリケーションのための保護されたデータベースの構成

リカバリ・アプライアンス・レプリケーション環境に参加する保護されたデータベースはそれぞれ、正しく構成する必要があります。たとえば、保護されたデータベースごとに、次を実行する必要があります。

  • アップストリームおよびダウンストリーム・リカバリ・アプライアンス上の仮想プライベート・カタログ所有者のOracleウォレット資格証明を、Oracleウォレットに追加します。

    ノート:

    レプリケーション構成では、ダウンストリーム資格証明の追加は要求されません。ただし、アップストリーム・リカバリ・アプライアンスがアクセス不可の場合、およびRMANがダウンストリーム・リカバリ・アプライアンスからバックアップのリストアを試行する場合、RMANはダウンストリーム・リカバリ・アプライアンスで仮想プライベート・カタログに直接接続する必要があります。この場合、Oracleウォレットでダウンストリーム資格証明が必要になります。

  • Oracleウォレットの内容を確認します。

  • アップストリーム・リカバリ・アプライアンスの仮想プライベート・カタログでデータベースを登録します。

  • 保護されたデータベースをバックアップし、RMANチャネルを割り当てる際に正しいOracleウォレットの場所を指定します。

保護されたデータベースの構成方法を学習するには、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

リカバリ・アプライアンスのレプリケーション・サーバー構成のテスト

レプリケーション・スキーマに関わる保護されたデータベースごとに、次のプロシージャを使用して、アップストリーム・リカバリ・アプライアンスからすべてのダウンストリーム・リカバリ・アプライアンスへのレプリケーションをテストします。このプロシージャを繰り返して、複雑なレプリケーション・トポロジの各レプリケーション・パスをテストします。

この項では、次のことを前提にしています。

  • アップストリーム・リカバリ・アプライアンスZDLRA Bostonからダウンストリーム・リカバリ・アプライアンスZDLRA Des Moinesへのorcl11のバックアップのレプリケーションをテストします。

  • ZDLRA Bostonではテープにもバックアップします。

保護されたデータベースのレプリケーションをテストするには:

  1. RMANを起動し、保護されたデータベースにTARGETとして接続し、アップストリーム・リカバリ・アプライアンス上の仮想プライベート・カタログにCATALOGとして接続します。

    たとえば、システム・プロンプトに次のコマンドを入力して、orcl11にTARGETとして、およびzdlra_bostonにCATALOGとして接続します。 

    rman TARGET ra_admin@orcl11 CATALOG /@zdlra01bosingest-scan1.acme.com:1521/zdlrabos:dedicated
  2. バックアップ・セットのリストを表示し、アップストリームおよびダウンストリーム・リカバリ・アプライアンスにバックアップが存在することを確認します。

    たとえば、次のコマンドを実行します(出力例も示します)。 

    RMAN> LIST BACKUPSET; 
.
.
.
 
BS Key  Size 
------- ----------
54746   224.25M  

  List of Archived Logs in backup set 54746
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
  1    17854   153525644  2014/07/01 12:59:40 153545145  2014/07/01 13:00:34
  1    17855   153545145  2014/07/01 13:00:34 153564529  2014/07/01 13:01:36 
  1    17856   153564529  2014/07/01 13:01:36 153585644  2014/07/01 13:02:26
  1    17857   153585644  2014/07/01 13:02:26 153606722  2014/07/01 13:03:18 
  1    17858   153606722  2014/07/01 13:03:18 153629480  2014/07/01 13:04:11
  1    17859   153629480  2014/07/01 13:04:11 153651278  2014/07/01 13:05:05 
  1    17860   153651278  2014/07/01 13:05:05 153672263  2014/07/01 13:05:59
  
  Backup Set Copy #1 of backup set 54746
  Device Type Elapsed Time Completion Time     Compressed Tag
  ----------- ------------ ------------------- ---------- --- 
  SBT_TAPE    02:52:20     2014/07/01 13:14:46 NO         TAG20140701T131434
  
    List of Backup Pieces for backup set 54746 Copy #1
    BP Key  Pc# Status      Media                   Piece Name 
    ------- --- ----------- ----------------------- ----------
    54747   1   AVAILABLE   Oracle Recovery Appliance (ZDLRA Boston) 4qpca79s_1_1_DB1211LG 
 
  Backup Set Copy #2 of backup set 54746 
  Device Type Elapsed Time Completion Time     Compressed Tag 
  ----------- ------------ ------------------- ---------- ---
  SBT_TAPE    02:52:20     2014/07/01 16:06:56 NO         TAG20140701T131434
 
    List of Backup Pieces for backup set 54746 Copy #2 
    BP Key  Pc# Status      Media                   Piece Name
    ------- --- ----------- ----------------------- ---------- 
    55019   1   AVAILABLE   Oracle Recovery Appliance (ZDLRA Des Moines) RA_SBT_54971_4qpca79s_1_2_54746_1
. 
.
.

    前述の出力では、バックアップ・セット54746には2つのコピーがあります。コピー#1はアップストリーム・リカバリ・アプライアンスZDLRA Bostonにあり、コピー#2はダウンストリーム・リカバリ・アプライアンスZDLRA Des Moinesにあります。

  3. SQL*PlusまたはSQL Developerで、RASYS権限がある名前付きユーザーとしてアップストリーム・リカバリ・アプライアンスに接続します。
  4. アップストリーム・リカバリ・アプライアンスのレプリケーション・ステータスが正しいことを確認します。

    たとえば、RA_REPLICATION_CONFIGを問い合せて、「タスク6: アップストリーム・リカバリ・アプライアンスでのレプリケーション・サーバー構成の作成」で作成したレプリケーション・サーバー構成のRUNNINGの状態を確認します。 

    SELECT REPLICATION_SERVER_NAME AS "RS_NAME", 
       REPLICATION_SERVER_STATE AS "RS_STATE",
FROM   RA_REPLICATION_CONFIG;

RS_NAME         RS_STATE
--------------- --------
ZDLRADSM_REP RUNNING

    前述のすべてのテストで予期した結果が出た場合、アップストリーム・リカバリ・アプライアンスはこの保護されたデータベースのバックアップを正常にレプリケートしています。

DBMS_RAを使用したTLSでのリカバリ・アプライアンス・レプリケーションの構成

この項では、TLSが一方または両方のリカバリ・アプライアンスで使用されている場合のリカバリ・アプライアンス・レプリケーションの構成方法について説明します。

前提条件

環境が次の前提条件を満たしている必要があります。

  • アップストリームおよびダウンストリーム・リカバリ・アプライアンスが、ネットワークを超えて相互にやり取りできること。

  • ダウンストリーム・リカバリ・アプライアンスが起動され、バックアップを受け取るように構成されていること。

次のレプリケーション・ケースを示します。

ケース1: 一方向レプリケーション、ダウンストリームでTLS無効

アップストリーム・リカバリ・アプライアンス(RA1)に、ダウンストリーム・リカバリ・アプライアンス(RA2)への一方向レプリケーションがあります。

  • アップストリーム・リカバリ・アプライアンスは、TLS有効、TLSのみ、またはTLS無効のモードにできます。

  • ダウンストリーム・リカバリ・アプライアンスはTLS無効になっています。

処置は必要ありません。

ケース2: 一方向レプリケーション、ダウンストリームでTLS有効

アップストリーム・リカバリ・アプライアンス(RA1)に、ダウンストリーム・リカバリ・アプライアンス(RA2)への一方向レプリケーションがあります。

  • アップストリーム・リカバリ・アプライアンス(RA1)は、TLS有効、TLSのみ、またはTLS無効のモードにできます。

  • ダウンストリーム・リカバリ・アプライアンス(RA2)は、TLS有効またはTLSのみになっています。

ダウンストリームとしてRA2を使用して次のステップを実行します。

  1. tnsnames.oraを新しいTCPS情報で更新します。

    1. ダウンストリーム・リカバリ・アプライアンス上

      cat /u01/app/oracle/product/19.0.0.0/dbhome_1/network/admin/tnsnames.ora

    2. アップストリーム・リカバリ・アプライアンスで、ダウンストリーム・リカバリ・アプライアンスからのTCPS情報で新しいエントリを追加するか既存のエントリを更新します。たとえば: 

      (ADDRESS = (PROTOCOL = TCPS)(HOST = <FULL_SCAN_NAME>)(PORT = 2484)

  2. pem拡張子が付いた信頼できる証明書(<NAME>.pemなど)を更新します。

    1. その信頼できる証明書をダウンストリーム・リカバリ・アプライアンスからアップストリーム・リカバリ・アプライアンスのtmpディレクトリにコピーします。

      ノート:

      アップストリーム・リカバリ・アプライアンスがTLS有効の場合は別の場所または別の名前を使用して、アップストリーム・リカバリ・アプライアンス上の証明書が上書きされないようにします。 
      scp DS_RA:<trusted_cert> US_RA:/tmp/<different_name_trusted_cert>

    2. RAウォレットのパスワードを準備します。

      ノート:

      RAウォレットとレプリケーション・ウォレットに同じパスワードを使用します。 
      mkstore --wrl /raacfs/raadmin/config/awallet/wallet/ --viewEntry oracle.security.client.password<NUMBER>

      • アップストリーム・リカバリ・アプライアンスもTLS有効である場合、RAウォレットではすでにその証明書がサポートされています。 

        orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        レプリケーションが双方向の場合は、同じ操作を実行しますが、ローカルのリカバリ・アプライアンスをダウンストリーム・リカバリ・アプライアンスとして扱います。

      • アップストリーム・リカバリ・アプライアンスがTLS有効でない場合は、それらの証明書をサポートするためにRAウォレットを移行する必要があります。

        1. 現在の資格証明をすべてリストします。

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet -–listCredential

        2. ウォレットをバックアップします。

          mv /raacfs/raadmin/config/ra_wallet/wallet /raacfs/raadmin/config/ra_wallet/wallet_old

        3. 新しいRAウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/config/ra_wallet/wallet

        4. コピーした信頼できる証明書をウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet --trusted_cert 
--cert /tmp/<different_name_trusted_cert>

        5. ウォレットを自動ログインに更新します。

          orapki wallet create -–wallet /raacfs/raadmin/config/ra_wallet/wallet
      --auto_login

        6. すべての資格証明をその新しいRAウォレットにリカバリします。古いウォレット内の資格証明ごとに、次のことを実行します:

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet 
--createCredential <alias> <user>  <pw>

    3. レプリケーション・ウォレットで証明書がサポートされていることを確認します。

      ls -lart  /raacfs/raadmin/replication/orapki

      これは、RACLIで推奨され証明書がサポートされている、レプリケーション・ウォレット標準です。

      • レプリケーション・ウォレットが存在する場合は、次のことを実行します:

        orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert -cert /tmp/<different_name_trusted_cert>

      • レプリケーション・ウォレットが存在しない場合は、次のことを実行します:

        1. 現在のレプリケーション・ウォレット内の資格証明をリストします。

          mkstore -–wrl /raacfs/raadmin/replication -–listCredential

        2. 新しいレプリケーション・ウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/replication/orapki

        3. コピーした信頼できる証明書を新しいレプリケーション・ウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        4. 自動ログインでウォレットを更新します。

          orapki wallet create -–wallet /raacfs/raadmin/replication/orapki --auto_login

        5. すべての資格証明を新しいレプリケーション・ウォレットにリカバリします

           mkstore -–wrl /raacfs/raadmin/replication/orapki --createCredential <tns_alias> <repl_user> <repl_user_pw>

  3. レプリケーション・サーバー・パラメータを更新します。

    1. レプリケーション・サーバーを一時停止します。

       dbms_ra.pause_replication_server()

    2. レプリケーション・パラメータを更新します。

      • wallet_pathは、新しいレプリケーション・ウォレットの場所である必要があります。

      • wallet_aliasは、ステップ1においてtnsnames.ora内で更新した別名である必要があります 

      dbms_ra.update_replication_server() 
wallet_path => 'file:/raacfs/raadmin/replication/orapki/’ 
wallet_alias => ‘TNS_ALIAS’

    3. レプリケーション・サーバーを再開します

       dbms_ra.resume_replication_server()

ケース3: 双方向レプリケーション、ダウンストリームでTLS無効

アップストリーム・リカバリ・アプライアンス(RA1)に、ダウンストリーム・リカバリ・アプライアンス(RA2)との双方向レプリケーションがあります。

  • アップストリーム・リカバリ・アプライアンスは、TLS有効またはTLSのみのモードにできます。

  • ダウンストリーム・リカバリ・アプライアンスはTLS無効になっています。

ダウンストリームとしてRA1を使用して、このステップを実行します。ダウンストリーム・リカバリ・アプライアンスで、

  1. tnsnames.oraを新しいTCPS情報で更新します。

    1. ダウンストリーム・リカバリ・アプライアンス上

      cat /u01/app/oracle/product/19.0.0.0/dbhome_1/network/admin/tnsnames.ora

    2. アップストリーム・リカバリ・アプライアンスで、ダウンストリーム・リカバリ・アプライアンスからのTCPS情報で新しいエントリを追加するか既存のエントリを更新します。たとえば: 

      (ADDRESS = (PROTOCOL = TCPS)(HOST = <FULL_SCAN_NAME>)(PORT = 2484)

  2. pem拡張子が付いた信頼できる証明書(<NAME>.pemなど)を更新します。

    1. その信頼できる証明書をダウンストリーム・リカバリ・アプライアンスからアップストリーム・リカバリ・アプライアンスのtmpディレクトリにコピーします。

      ノート:

      アップストリーム・リカバリ・アプライアンスがTLS有効の場合は別の場所または別の名前を使用して、アップストリーム・リカバリ・アプライアンス上の証明書が上書きされないようにします。 
      scp DS_RA:<trusted_cert> US_RA:/tmp/<different_name_trusted_cert>

    2. RAウォレットのパスワードを準備します。

      ノート:

      RAウォレットとレプリケーション・ウォレットに同じパスワードを使用します。 
      mkstore --wrl /raacfs/raadmin/config/awallet/wallet/ --viewEntry oracle.security.client.password<NUMBER>

      • アップストリーム・リカバリ・アプライアンスもTLS有効である場合、RAウォレットではすでにその証明書がサポートされています。 

        orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        レプリケーションが双方向の場合は、同じ操作を実行しますが、ローカルのリカバリ・アプライアンスをダウンストリーム・リカバリ・アプライアンスとして扱います。

      • アップストリーム・リカバリ・アプライアンスがTLS有効でない場合は、それらの証明書をサポートするためにRAウォレットを移行する必要があります。

        1. 現在の資格証明をすべてリストします。

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet -–listCredential

        2. ウォレットをバックアップします。

          mv /raacfs/raadmin/config/ra_wallet/wallet /raacfs/raadmin/config/ra_wallet/wallet_old

        3. 新しいRAウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/config/ra_wallet/wallet

        4. コピーした信頼できる証明書をウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet --trusted_cert 
--cert /tmp/<different_name_trusted_cert>

        5. ウォレットを自動ログインに更新します。

          orapki wallet create -–wallet /raacfs/raadmin/config/ra_wallet/wallet
      --auto_login

        6. すべての資格証明をその新しいRAウォレットにリカバリします。古いウォレット内の資格証明ごとに、次のことを実行します:

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet 
--createCredential <alias> <user>  <pw>

    3. レプリケーション・ウォレットで証明書がサポートされていることを確認します。

      ls -lart  /raacfs/raadmin/replication/orapki

      これは、RACLIで推奨され証明書がサポートされている、レプリケーション・ウォレット標準です。

      • レプリケーション・ウォレットが存在する場合は、次のことを実行します:

        orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert -cert /tmp/<different_name_trusted_cert>

      • レプリケーション・ウォレットが存在しない場合は、次のことを実行します:

        1. 現在のレプリケーション・ウォレット内の資格証明をリストします。

          mkstore -–wrl /raacfs/raadmin/replication -–listCredential

        2. 新しいレプリケーション・ウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/replication/orapki

        3. コピーした信頼できる証明書を新しいレプリケーション・ウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        4. 自動ログインでウォレットを更新します。

          orapki wallet create -–wallet /raacfs/raadmin/replication/orapki --auto_login

        5. すべての資格証明を新しいレプリケーション・ウォレットにリカバリします

           mkstore -–wrl /raacfs/raadmin/replication/orapki --createCredential <tns_alias> <repl_user> <repl_user_pw>

  3. レプリケーション・サーバー・パラメータを更新します。

    1. レプリケーション・サーバーを一時停止します。

       dbms_ra.pause_replication_server()

    2. レプリケーション・パラメータを更新します。

      • wallet_pathは、新しいレプリケーション・ウォレットの場所である必要があります。

      • wallet_aliasは、ステップ1においてtnsnames.ora内で更新した別名である必要があります 

      dbms_ra.update_replication_server() 
wallet_path => 'file:/raacfs/raadmin/replication/orapki/’ 
wallet_alias => ‘TNS_ALIAS’

    3. レプリケーション・サーバーを再開します

       dbms_ra.resume_replication_server()

ケース4: 双方向レプリケーション、ダウンストリームでTLS有効

アップストリーム・リカバリ・アプライアンス(RA1)に、ダウンストリーム・リカバリ・アプライアンス(RA2)との双方向レプリケーションがあります。

  • アップストリーム・リカバリ・アプライアンスは、TLS有効またはTLSのみのモードにできます。

  • ダウンストリーム・リカバリ・アプライアンスは、TLS有効またはTLSのみになっています。

このステップを2回実行します。1回はダウンストリームとしてRA1を使用し、もう1回はダウンストリームとしてRA2を使用します。

  1. tnsnames.oraを新しいTCPS情報で更新します。

    1. ダウンストリーム・リカバリ・アプライアンス上

      cat /u01/app/oracle/product/19.0.0.0/dbhome_1/network/admin/tnsnames.ora

    2. アップストリーム・リカバリ・アプライアンスで、ダウンストリーム・リカバリ・アプライアンスからのTCPS情報で新しいエントリを追加するか既存のエントリを更新します。たとえば: 

      (ADDRESS = (PROTOCOL = TCPS)(HOST = <FULL_SCAN_NAME>)(PORT = 2484)

  2. pem拡張子が付いた信頼できる証明書(<NAME>.pemなど)を更新します。

    1. その信頼できる証明書をダウンストリーム・リカバリ・アプライアンスからアップストリーム・リカバリ・アプライアンスのtmpディレクトリにコピーします。

      ノート:

      アップストリーム・リカバリ・アプライアンスがTLS有効の場合は別の場所または別の名前を使用して、アップストリーム・リカバリ・アプライアンス上の証明書が上書きされないようにします。 
      scp DS_RA:<trusted_cert> US_RA:/tmp/<different_name_trusted_cert>

    2. RAウォレットのパスワードを準備します。

      ノート:

      RAウォレットとレプリケーション・ウォレットに同じパスワードを使用します。 
      mkstore --wrl /raacfs/raadmin/config/awallet/wallet/ --viewEntry oracle.security.client.password<NUMBER>

      • アップストリーム・リカバリ・アプライアンスもTLS有効である場合、RAウォレットではすでにその証明書がサポートされています。 

        orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        レプリケーションが双方向の場合は、同じ操作を実行しますが、ローカルのリカバリ・アプライアンスをダウンストリーム・リカバリ・アプライアンスとして扱います。

      • アップストリーム・リカバリ・アプライアンスがTLS有効でない場合は、それらの証明書をサポートするためにRAウォレットを移行する必要があります。

        1. 現在の資格証明をすべてリストします。

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet -–listCredential

        2. ウォレットをバックアップします。

          mv /raacfs/raadmin/config/ra_wallet/wallet /raacfs/raadmin/config/ra_wallet/wallet_old

        3. 新しいRAウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/config/ra_wallet/wallet

        4. コピーした信頼できる証明書をウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet --trusted_cert 
--cert /tmp/<different_name_trusted_cert>

        5. ウォレットを自動ログインに更新します。

          orapki wallet create -–wallet /raacfs/raadmin/config/ra_wallet/wallet
      --auto_login

        6. すべての資格証明をその新しいRAウォレットにリカバリします。古いウォレット内の資格証明ごとに、次のことを実行します:

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet 
--createCredential <alias> <user>  <pw>

    3. レプリケーション・ウォレットで証明書がサポートされていることを確認します。

      ls -lart  /raacfs/raadmin/replication/orapki

      これは、RACLIで推奨され証明書がサポートされている、レプリケーション・ウォレット標準です。

      • レプリケーション・ウォレットが存在する場合は、次のことを実行します:

        orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert -cert /tmp/<different_name_trusted_cert>

      • レプリケーション・ウォレットが存在しない場合は、次のことを実行します:

        1. 現在のレプリケーション・ウォレット内の資格証明をリストします。

          mkstore -–wrl /raacfs/raadmin/replication -–listCredential

        2. 新しいレプリケーション・ウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/replication/orapki

        3. コピーした信頼できる証明書を新しいレプリケーション・ウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        4. 自動ログインでウォレットを更新します。

          orapki wallet create -–wallet /raacfs/raadmin/replication/orapki --auto_login

        5. すべての資格証明を新しいレプリケーション・ウォレットにリカバリします

           mkstore -–wrl /raacfs/raadmin/replication/orapki --createCredential <tns_alias> <repl_user> <repl_user_pw>

  3. レプリケーション・サーバー・パラメータを更新します。

    1. レプリケーション・サーバーを一時停止します。

       dbms_ra.pause_replication_server()

    2. レプリケーション・パラメータを更新します。

      • wallet_pathは、新しいレプリケーション・ウォレットの場所である必要があります。

      • wallet_aliasは、ステップ1においてtnsnames.ora内で更新した別名である必要があります 

      dbms_ra.update_replication_server() 
wallet_path => 'file:/raacfs/raadmin/replication/orapki/’ 
wallet_alias => ‘TNS_ALIAS’

    3. レプリケーション・サーバーを再開します

       dbms_ra.resume_replication_server()

ケース5: 双方向レプリケーション、アップストリームでTLS無効

アップストリーム・リカバリ・アプライアンス(RA1)に、ダウンストリーム・リカバリ・アプライアンス(RA2)との双方向レプリケーションがあります。

  • アップストリーム・リカバリ・アプライアンスはTLS無効になっています。

  • ダウンストリーム・リカバリ・アプライアンスは、TLS有効またはTLSのみになっています。

ダウンストリームとしてRA2を使用して、このステップを実行します。

  1. tnsnames.oraを新しいTCPS情報で更新します。

    1. ダウンストリーム・リカバリ・アプライアンス上

      cat /u01/app/oracle/product/19.0.0.0/dbhome_1/network/admin/tnsnames.ora

    2. アップストリーム・リカバリ・アプライアンスで、ダウンストリーム・リカバリ・アプライアンスからのTCPS情報で新しいエントリを追加するか既存のエントリを更新します。たとえば: 

      (ADDRESS = (PROTOCOL = TCPS)(HOST = <FULL_SCAN_NAME>)(PORT = 2484)

  2. pem拡張子が付いた信頼できる証明書(<NAME>.pemなど)を更新します。

    1. その信頼できる証明書をダウンストリーム・リカバリ・アプライアンスからアップストリーム・リカバリ・アプライアンスのtmpディレクトリにコピーします。

      ノート:

      アップストリーム・リカバリ・アプライアンスがTLS有効の場合は別の場所または別の名前を使用して、アップストリーム・リカバリ・アプライアンス上の証明書が上書きされないようにします。 
      scp DS_RA:<trusted_cert> US_RA:/tmp/<different_name_trusted_cert>

    2. RAウォレットのパスワードを準備します。

      ノート:

      RAウォレットとレプリケーション・ウォレットに同じパスワードを使用します。 
      mkstore --wrl /raacfs/raadmin/config/awallet/wallet/ --viewEntry oracle.security.client.password<NUMBER>

      • アップストリーム・リカバリ・アプライアンスもTLS有効である場合、RAウォレットではすでにその証明書がサポートされています。 

        orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        レプリケーションが双方向の場合は、同じ操作を実行しますが、ローカルのリカバリ・アプライアンスをダウンストリーム・リカバリ・アプライアンスとして扱います。

      • アップストリーム・リカバリ・アプライアンスがTLS有効でない場合は、それらの証明書をサポートするためにRAウォレットを移行する必要があります。

        1. 現在の資格証明をすべてリストします。

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet -–listCredential

        2. ウォレットをバックアップします。

          mv /raacfs/raadmin/config/ra_wallet/wallet /raacfs/raadmin/config/ra_wallet/wallet_old

        3. 新しいRAウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/config/ra_wallet/wallet

        4. コピーした信頼できる証明書をウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/config/ra_wallet/wallet --trusted_cert 
--cert /tmp/<different_name_trusted_cert>

        5. ウォレットを自動ログインに更新します。

          orapki wallet create -–wallet /raacfs/raadmin/config/ra_wallet/wallet
      --auto_login

        6. すべての資格証明をその新しいRAウォレットにリカバリします。古いウォレット内の資格証明ごとに、次のことを実行します:

          mkstore -–wrl /raacfs/raadmin/config/ra_wallet/wallet 
--createCredential <alias> <user>  <pw>

    3. レプリケーション・ウォレットで証明書がサポートされていることを確認します。

      ls -lart  /raacfs/raadmin/replication/orapki

      これは、RACLIで推奨され証明書がサポートされている、レプリケーション・ウォレット標準です。

      • レプリケーション・ウォレットが存在する場合は、次のことを実行します:

        orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert -cert /tmp/<different_name_trusted_cert>

      • レプリケーション・ウォレットが存在しない場合は、次のことを実行します:

        1. 現在のレプリケーション・ウォレット内の資格証明をリストします。

          mkstore -–wrl /raacfs/raadmin/replication -–listCredential

        2. 新しいレプリケーション・ウォレットを作成します。

          orapki wallet create --wallet /raacfs/raadmin/replication/orapki

        3. コピーした信頼できる証明書を新しいレプリケーション・ウォレットにインポートします。

          orapki wallet add --wallet /raacfs/raadmin/replication/orapki 
--trusted_cert --cert /tmp/<different_name_trusted_cert>

        4. 自動ログインでウォレットを更新します。

          orapki wallet create -–wallet /raacfs/raadmin/replication/orapki --auto_login

        5. すべての資格証明を新しいレプリケーション・ウォレットにリカバリします

           mkstore -–wrl /raacfs/raadmin/replication/orapki --createCredential <tns_alias> <repl_user> <repl_user_pw>

  3. レプリケーション・サーバー・パラメータを更新します。

    1. レプリケーション・サーバーを一時停止します。

       dbms_ra.pause_replication_server()

    2. レプリケーション・パラメータを更新します。

      • wallet_pathは、新しいレプリケーション・ウォレットの場所である必要があります。

      • wallet_aliasは、ステップ1においてtnsnames.ora内で更新した別名である必要があります 

      dbms_ra.update_replication_server() 
wallet_path => 'file:/raacfs/raadmin/replication/orapki/’ 
wallet_alias => ‘TNS_ALIAS’

    3. レプリケーション・サーバーを再開します

       dbms_ra.resume_replication_server()

ケース6: 双方向レプリケーション、アップストリームとダウンストリームでTLS無効

アップストリーム・リカバリ・アプライアンス(RA1)に、ダウンストリーム・リカバリ・アプライアンス(RA2)との双方向レプリケーションがあります。

  • アップストリーム・リカバリ・アプライアンスはTLS無効になっています。

  • ダウンストリーム・リカバリ・アプライアンスはTLS無効になっています。

処置は必要ありません。