1. 保護されたデータベースの構成ガイド
  2. 保護されたデータベースの構成

3 保護されたデータベースの構成

この章では、リカバリ・アプライアンスを使用したバックアップおよびリカバリ操作用に保護されたデータベースを構成する方法について説明します。

リカバリ・アプライアンス用に保護されたデータベースを構成する方法の概要

保護されたデータベースのバックアップの中央リポジトリとしてリカバリ・アプライアンスを使用する場合は、リカバリ・アプライアンスと保護されたデータベースの両方を構成する必要があります。保護されたデーベースを構成するには、Enterprise Manager Cloud Control (Cloud Control)またはRMANを使用できます。

リカバリ・アプライアンスの構成ステップでは、保護されたデータベースに割り当てる保護ポリシーの作成、仮想プライベート・カタログを所有するリカバリ・アプライアンス・ユーザーの作成、リカバリ・アプライアンス・ユーザーへの保護されたデータベースのアクセス権の付与などを行います。これらのステップについては、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

保護されたデータベースの構成では、保護されたデータベースからリカバリ・アプライアンスへのアクセスの有効化、保護されたデータベースのメタデータのリカバリ・アプライアンスへの追加、バックアップおよびリカバリ操作時に使用する設定の指定などを行います。

ノート:

保護されたデータベースにはサーバー・パラメータ・ファイルを使用することをお薦めします。

リカバリ・アプライアンス用に保護されたデータベースを構成するステップ

保護されたデータベースの構成では、リカバリ・アプライアンスを使用して保護されたデータベースをバックアップおよびリカバリするために必要なセットアップ・タスクを実行します。

リカバリ・アプライアンス用に保護されたデータベースを構成するには:

  1. 保護されたデータベースをリカバリ・アプライアンスに登録します。

    登録は1回かぎりのタスクであり、保護されたデータベースでリカバリ・アプライアンスを使用するための初回セットアップ時に実行する必要があります。

    関連項目:

    「リカバリ・アプライアンスへの保護されたデータベースの登録」

  2. 保護されたデータベースのバックアップおよびリカバリ設定を構成します。

    これらの設定は、保護されたデータベースのバックアップおよびリカバリ操作中に使用されます。実行するバックアップまたはリカバリ・タスクに応じて設定を変更することが可能です。

    関連項目:

  3. 「Cloud Controlを使用したテスト・バックアップの実行」の説明に従って、テスト・バックアップを実行し、保護されたデータベースの構成が正常であることを確認します。

関連項目:

リカバリ・アプライアンス・バックアップ・モジュールの概要

リカバリ・アプライアンス・バックアップ・モジュールはOracleが提供するSBTライブラリで、メディア管理ライブラリとして機能します。RMANではリカバリ・アプライアンス・バックアップ・モジュールを使用して、バックアップ・データをネットワーク経由でリカバリ・アプライアンスに転送します。バックアップ・モジュールは、リカバリ・アプライアンスへのバックアップまたはリカバリ操作で使用するRMAN SBTチャネルの割当て/構成を行う際に参照されます。リカバリ・アプライアンスへのバックアップ操作および完全バックアップ・セットのリストア操作はすべてこのバックアップ・モジュールを介して実行されます。

リカバリ・アプライアンス・バックアップ・モジュールのインストール場所

リカバリ・アプライアンス・バックアップ・モジュールは次の場所にインストールする必要があります。

  • RMANを使用してリカバリ・アプライアンスにバックアップされるすべての保護されたデータベースのOracleホーム内

    特定のOracleホームが複数の保護されたデータベースによって使用されている場合、このOracleホームにはバックアップ・モジュールを1回だけインストールする必要があります。

  • レプリケーション環境でバックアップをダウンストリーム・リカバリ・アプライアンスに送信するすべてのアップストリーム・リカバリ・アプライアンス上

    リカバリ・アプライアンス・バックアップ・モジュールのライブラリ(libra.so)は、リカバリ・アプライアンスに事前インストールされています。ただし、レプリケーション・ユーザー資格証明が含まれているOracleウォレットが、アップストリーム・リカバリ・アプライアンスで構成されている必要があります。

関連項目:

リカバリ・アプライアンス・バックアップ・モジュールの構成ファイル

リカバリ・アプライアンス・バックアップ・モジュールの構成ファイルには、保護されたデータベースとリカバリ・アプライアンスとの通信で使用する構成設定が含まれています。リカバリ・アプライアンス・バックアップ・モジュールが保護されたデータベースのホストにインストールされる際に、構成ファイルが自動的に作成されます。

リカバリ・アプライアンス・バックアップ・モジュールの一部の構成パラメータは、リカバリ・アプライアンスで使用するRMAN SBTチャネルを構成または割り当てる際にインラインで設定することもできます(例3-3および例3-4を参照)。

関連項目:

リカバリ・アプライアンス・バックアップ・モジュールのインストール時に指定可能な構成パラメータについては、「リカバリ・アプライアンス・バックアップ・モジュールの構成パラメータ」を参照してください

リカバリ・アプライアンス・バックアップ・モジュールの構成パラメータ

表4-1に、リカバリ・アプライアンス・バックアップ・モジュールのインストール時に使用される構成パラメータを示します。これらのパラメータは、リカバリ・アプライアンスへのバックアップ時とリカバリ・アプライアンスからのリストア時に、保護されたデータベースで使用します。

表3-1 リカバリ・アプライアンス・バックアップ・モジュールのインストーラ・パラメータ

パラメータ名 必須/オプション 説明

dbUser

必須

保護されたデータベースのバックアップへの接続や送受信に必要な権限を持つリカバリ・アプライアンス・ユーザーのユーザー名。

dbPass

必須

dbUserユーザーのパスワード。

host

必須

リカバリ・アプライアンスのSCANホスト名。

port

必須

リカバリ・アプライアンスのメタデータ・データベースのリスナー・ポート番号。

serviceName

必須

リカバリ・アプライアンスのメタデータ・データベースのサービス名。

walletDir

必須

リカバリ・アプライアンスへの接続に使用するリカバリ・アプライアンス・ユーザーの資格証明とプロキシ情報が格納されるOracleウォレットの場所。

ノート: このディレクトリ内にOracleウォレットがすでに存在する場合、リカバリ・アプライアンス・バックアップ・モジュールのインストーラによって既存のウォレットが上書きされます。

proxyHost

オプション

リカバリ・アプライアンスへのHTTP接続に使用するプロキシ・サーバーのホスト名(IPアドレス)およびTCPポート(書式: host:port)。

configFile

オプション

リカバリ・アプライアンス・バックアップ・モジュールの構成パラメータが格納されている構成ファイルの場所。

Linux/UNIXでは、デフォルトの場所は$ORACLE_HOME/dbs/raORACLE_SID.oraです。Windowsでは、デフォルトの場所は$ORACLE_HOME\database\raORACLE_SID.oraです。

libDir

オプション

リカバリ・アプライアンス・バックアップ・モジュールの共有ライブラリの格納場所。このライブラリを使用して、バックアップ・データをネットワーク経由でリカバリ・アプライアンスに転送します。

共有ライブラリは、$ORACLE_HOME/lib (Linux/UNIXの場合)および$ORACLE_HOME\database\lib (Windowsの場合)に格納することをお薦めします。

このパラメータを省略すると、インストーラは共有ライブラリをダウンロードしません。以前にバックアップ・モジュールをインストール済のOracleホームにOracleウォレットと構成ファイルを再生成する場合は、ライブラリをダウンロードする必要はありません。

libPlatform

オプション

リカバリ・アプライアンス・バックアップ・モジュールをインストールする必要がある保護されたデータベースのホストのプラットフォーム名。

通常、リカバリ・アプライアンス・バックアップ・モジュールのインストーラが、実行中のプラットフォームを自動的に判断します。このパラメータを設定する必要があるのは、プラットフォームを特定できないことを示すエラーがインストーラによって表示された場合のみです。

プラットフォーム名として有効な値は、linux64、windows64、solaris_sparc64、solaris_sparcx64、zlinux64、aix_ppc64およびhpux_ia64です。

argFile

オプション

リカバリ・アプライアンス・バックアップ・モジュールのインストール時に読み取る必要のある他のコマンドライン・パラメータの読取り元ファイル。

関連項目:

「リカバリ・アプライアンス・バックアップ・モジュールのインストール」

保護されたデータベースの登録の概要

保護されたデータベースを登録すると、特定のリカバリ・アプライアンスが保護されたデータベースからバックアップを受信できるようになります。これは1回かぎりのタスクであり、保護されたデータベースでリカバリ・アプライアンスを使用するための初回セットアップ時に実行する必要があります。登録のステップは、リカバリ・アプライアンスと保護されたデータベースの両方で実行する必要があります。

保護されたデータベースの登録では、次のタスクを実行します。

  • 保護されたデータベースがリカバリ・アプライアンスにアクセスするために必要な資格証明の構成

    保護されたデータベースの管理者には、リカバリ・アプライアンスとの認証とバックアップおよびリカバリ操作を実行するための資格証明が必要です。そのためには、保護されたデータベースの管理ユーザーをリカバリ・アプライアンス・ユーザーに関連付けます(リカバリ・アプライアンスのメタデータ・データベースを使用)。これらの資格証明は、保護されたデータベース上に作成されるOracleウォレットに格納されます。

  • 保護されたデータベースに適切な保護ポリシーを関連付けることによる、リカバリ・アプライアンスでのリカバリ・ウィンドウ目標の定義と予約済領域の割当て

  • リカバリ・アプライアンス・ユーザーに対する保護されたデータベースへのアクセス権の付与

  • 保護されたデータベースのリカバリ・アプライアンス・カタログへの登録

    保護されたデータベースのバックアップに関するメタデータは、リカバリ・アプライアンス・カタログに格納する必要があります。リカバリ・アプライアンス・カタログには複数の仮想プライベート・カタログがあります。この保護されたデータベースのメタデータを操作する仮想プライベート・カタログの所有者を指定する必要があります。

  • Cloud Controlを使用する場合は、Cloud Controlからリカバリ・アプライアンスへの接続に使用する名前付き資格証明へのアクセス権がEnterprise Manager管理者に付与されている必要があります。保護されたデータベースをリカバリ・アプライアンスにバックアップおよびリカバリ・アプライアンスからリストアするように構成している場合、保護されたデータベースのバックアップやリストア操作を管理するEnterprise Manager管理者がリカバリ・アプライアンスに接続するためには、これらの資格証明へのアクセス権が必要です。

関連項目:

「リカバリ・アプライアンスへの保護されたデータベースの登録」

保護されたデータベースのバックアップ設定の概要

保護されたデータベースをリカバリ・アプライアンスにバックアップする前に、保護されたデータベースのバックアップ設定を構成する必要があります。これらの設定(表3-2を参照)では、保護されたデータベースのバックアップ環境のデフォルトの動作を定義します。各バックアップ設定のデフォルト値はRMANによって割り当てられます。ただし、保護されたデータベースのバックアップ要件に応じて設定を構成することをお薦めします。

表3-2 保護されたデータベースのバックアップ設定

バックアップ設定 説明

制御ファイルの自動バックアップ

バックアップ・レコードが追加されたり制御ファイルのデータベース構造メタデータが変更された場合に、制御ファイルおよびサーバー・パラメータ・ファイルを自動的にバックアップする必要があることを指定します。

ディスク・バックアップの場所

リカバリ・アプライアンスのバックアップを構成する際、バックアップのポーリングが必要な場合は、バックアップのポーリング位置を指定します。

バックアップの最適化

同じファイルがすでにリカバリ・アプライアンスにバックアップされている場合は、ファイルのバックアップをスキップします。

保存ポリシー

リカバリ目標を満たすために保存しておく必要のあるバックアップを指定します。リカバリ・ウィンドウまたは冗長性の値を指定できます。

パラレル・バックアップ計画を使用していて、既存の(リカバリ・アプライアンス以外の)バックアップ計画によって作成された不要なバックアップを削除する必要がある場合に、この設定を指定する必要があります。

アーカイブREDOログの削除ポリシー

アーカイブREDOログを削除できる条件を指定します。このポリシーは、すべてのアーカイブ先(高速リカバリ領域も含む)に適用されます。

関連項目:

保護されたデータベースのリカバリ設定の概要

表3-3に、保護されたデータベースのリカバリ設定を示します。一部の設定(高速リカバリ領域など)の値は、リカバリ・アプライアンス用の保護されたデータベースの構成内容に基づいて割り当てられます。

表3-3 保護されたデータベースのリカバリ設定

リカバリ設定 説明

必要な平均リカバリ時間

平均リカバリ時間(MTTR)は、保護されたデータベースのリカバリの所要時間です。保護されたデータベースで許容可能なMTTRに基づいてバックアップ計画を立てます。

ARCHIVELOGモード

ARCHIVELOGモードでは、一杯になったオンラインREDOログ・ファイルのグループをREDOログ・スイッチの発生直後からアーカイブできます。

必要に応じて、保護されたデータベースに次の追加プロパティを構成します。

  • ログのアーカイブ・ファイル名の書式

    アーカイブREDOログ・ファイルのデフォルトのファイル名の書式を指定します。この値はテキスト文字列と変数で指定します。有効な変数については、『Oracle Databaseリファレンス』を参照してください。

  • アーカイブREDOログの保存先

    高速リカバリ領域をREDOログの保存先として使用するには、「アーカイブREDOログの保存先」をUSE_DB_RECOVERY_FILE_DESTに設定します。

ノート: REDOデータをリカバリ・アプライアンスに送信する場合、ARCHIVELOGモードで保護されたデータベースを実行する必要があります。

関連項目: ARCHIVELOGモードでデータベースを実行する構成の詳細は、『Oracle Database管理者ガイド』を参照してください。

高速リカバリ領域

高速リカバリ領域は、バックアップ関連ファイル(RMANバックアップ、アーカイブREDOログ・ファイル、制御ファイルとオンラインREDOログ・ファイルのコピーなど)を格納するディスクの場所です。高速リカバリ領域を使用すると、バックアップ関連ファイルの管理が自動化され、バックアップ関連ファイルのディスク領域の手動管理が必要最小限になります。

関連項目: 高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

関連項目:

リカバリ・アプライアンスへの保護されたデータベースの登録

保護されたデータベースをリカバリ・アプライアンスに登録するための大まかな手順を次に示します:

保護されたデータベースをCloud Controlを使用してリカバリ・アプライアンスに登録するには:

  1. 保護されたデータベースをリカバリ・アプライアンスに追加します。

    このステップは、『Zero Data Loss Recovery Appliance管理者ガイド』の説明に従って、リカバリ・アプライアンス管理者が実行する必要があります。

    リカバリ・アプライアンス管理者は、保護されたデータベースを追加する際に、保護されたデータベースに関連付ける保護ポリシー、リカバリ・アプライアンス上で保護されたデータベース用に予約済のディスク領域の最小量、および保護されたデータベースのバックアップに必要な権限を持つリカバリ・アプライアンス・ユーザーを定義します。

  2. 「Cloud Controlを使用した保護されたデータベースのホーム・ページへのアクセス」の説明に従って、保護されたデータベースのホーム・ページにアクセスします。

  3. 「可用性」メニューから「バックアップとリカバリ」を選択し、次に「バックアップ設定」を選択します。

    「バックアップ設定」ページが表示されます。

  4. リカバリ・アプライアンス設定セクションで、次の設定を指定します。

    • リカバリ・アプライアンス: 保護されたデータベースを登録するリカバリ・アプライアンスの名前を選択します。保護されたデータベースのバックアップは、このリカバリ・アプライアンスに格納されます。

    • 仮想プライベート・カタログのユーザー: この保護されたデータベースのバックアップを送信するために必要な権限を持つ、リカバリ・アプライアンスの仮想プライベート・カタログ・ユーザー(リカバリ・アプライアンス・ユーザー)を選択します。このユーザーは、リカバリ・アプライアンス管理者が事前に作成しておく必要があります(『Zero Data Loss Recovery Appliance管理者ガイド』を参照)。

      ノート:

      リアルタイムREDOトランスポートの有効化を選択すると、保護されたデータベースのREDOデータを直接リカバリ・アプライアンスへ非同期にトランスポートできます。あるいは、「Cloud Controlを使用した保護されたデータベースのリカバリ設定の構成」の説明に従って保護されたデータベースのリカバリ設定を構成する際に、リアルタイムREDOトランスポートを有効にすることもできます。

  5. 「適用」をクリックして、設定を保存します。

保護されたデータベースがリカバリ・アプライアンスに登録されると、保護されたデータベースのホーム・ページ(図3-1を参照)を使用して、保護されたデータベースの構成、バックアップおよびリカバリ操作を実行できるようになります。

保護されたデータベースをRMANを使用してリカバリ・アプライアンスに登録するには:

リカバリ・アプライアンスでの登録ステップは、DBMS_RAパッケージ内のプロシージャを使用して実行します。保護されたデータベースで実行するステップには、RMANまたはオペレーティング・システム・コマンドを使用します。

  1. 保護されたデータベースをリカバリ・アプライアンスに追加します。

    リカバリ・アプライアンスのメタデータ・データベースに対してSYS 権限を持つリカバリ・アプライアンス管理者が保護されたデータベースを追加します。保護されたデータベースに割り当てる必要のある保護ポリシーをリカバリ・アプライアンス管理者が判断できるように、次の情報を提供する必要があります。

    • 保護されたデータベースのリカバリ・ウィンドウ目標

    • この保護されたデータベースのバックアップを格納するために必要な推定領域

    関連項目:

    『Zero Data Loss Recovery Appliance管理者ガイド』

  2. 保護されたデータベースの認証に使用するリカバリ・アプライアンス・ユーザーに対して、バックアップおよびリカバリ操作の実行に必要な権限を付与します。このリカバリ・アプライアンス・ユーザーは、保護されたデータベースのメタデータが格納される仮想プライベート・カタログの所有者です。

    関連項目:

    『Zero Data Loss Recovery Appliance管理者ガイド』

  3. リカバリ・アプライアンス・バックアップ・モジュールをインストールします。

    これにより、リカバリ・アプライアンスへのアクセスに必要な資格証明を格納するOracleウォレットが作成され、バックアップ・データをリカバリ・アプライアンスに転送する共有ライブラリがインストールされます。

    関連項目:

    「リカバリ・アプライアンス・バックアップ・モジュールのインストール」

  4. 保護されたデータベースをリカバリ・アプライアンス・カタログに登録します。

    1. この保護されたデータベースのバックアップ・メタデータを格納するリカバリ・アプライアンス・カタログの所有者の名前およびパスワードを取得します。これらの資格証明については、リカバリ・アプライアンス管理者に問い合せてください。
    2. 「CLIを使用した保護されたデータベースとリカバリ・アプライアンスへの接続」の説明に従って、保護されたデータベースにTARGETとして接続し、リカバリ・アプライアンス・カタログにCATALOGとして接続します。
    3. REGISTER DATABASEコマンドを使用して保護されたデータベースを登録します。
      REGISTER DATABASE;

database registered in recovery catalog
starting full resync of recover catalog
full resync complete

  5. 登録プロセスが完了したらテスト・バックアップを実行し、構成が正しいことを確認します。

    「コマンドラインを使用したテスト・バックアップの実行」 では、このタスクについて説明します。

外部で構成されたデータベースがCloud Controlで認識されるようにする

この項では、保護されたデータベースの初期構成がEnterprise Manager Cloud Controlで実行されていないが今後はCloud Controlでそれが管理されるようにする場合の、例外的な事例を説明します。Cloud Controlの「バックアップ設定」ページを使用してこれらの特定のデータベースの構成を完了しリカバリ・アプライアンスにバックアップを送信しようとすると、一般的なエラーが発生することがあります。このエラーは、このデータベースがバックアップ設定の外部で構成されたか、仮想プライベート・カタログのユーザー設定を判別できないことを意味しています。

エラーの理由は次のとおりです。

  • Cloud Controlでは、Cloud Controlの外部(コマンドラインなど)で実行された構成は認識されません。
  • Cloud Controlでは、Cloud Control内部で実行されたが異なるCloud Controlユーザーによる構成は認識されません。Cloud Controlでは、Cloud Controlユーザーごとに個別のバックアップ設定が保持されます。あるユーザーが実行した構成に、別のユーザーはアクセスできません。

Cloud Controlの外部で実行されたデータベース構成がCloud Controlで認識されるようにするには:

  1. Cloud Controlで、保護されたデータベースの「ホーム」ページに移動します。
  2. メニュー項目「可用性」→「バックアップとリカバリ」→「リカバリ・カタログ設定」を選択します。
  3. 「リカバリ・カタログを使用」を選択します。
  4. ドロップダウン・リストから、すでに実行した構成プロセス中に保護されたデータベースが登録された、特定のリカバリ・アプライアンスの仮想プライベート・カタログ(VPC)を選択します。

    必要なVPCがリストにある場合は、これでタスクは完了です。ここで終わります。

    必要なVPCがリストにない場合は、次のステップに進みます。

    リカバリ・アプライアンスのVPCに対して実行されたデータソース構成がCloud Controlで認識されるようにします。

  5. Cloud Controlの「ターゲット」メニューで、「データベース」を選択します。
  6. 「データベース」ページで、メニュー項目「可用性」→「リカバリ・カタログ」を選択します。
  7. ベースの「リカバリ・アプライアンス」カタログを選択します。
  8. 「仮想プライベート・カタログの管理」を選択します。
  9. 「Enterprise Managerでの既存の仮想プライベート・カタログの管理」のラジオ・ボタンを選択します。
  10. この処理を続行します。
  11. 「リカバリ・カタログ設定」ページをリフレッシュします。
  12. ドロップダウン・リストから、すでに実行した構成プロセス中に保護されたデータベースが登録された、特定のリカバリ・アプライアンスの仮想プライベート・カタログ(VPC)を選択します。
    必要なVPCがリストに表示され、これでタスクが完了します。

リカバリ・アプライアンス管理者がCloud Controlの「保護されたデータベースの追加」ワークフローを実行すると、Cloud Controlでリカバリ・アプライアンスのVPCが認識されるようになります。この操作がCloud Controlの外部で実行された場合、Cloud Controlで、そのVPCが認識されず、リカバリ・アプライアンスへのバックアップの送信やリカバリ・アプライアンスへのバックアップのスケジュールを実行するためのデータベース側の構成を実行できません。

リカバリ・アプライアンスを選択した後に、「仮想プライベート・カタログのユーザー」選択リストに必要なVPCがリストされない場合、データベースの「バックアップ設定」ページに問題が表示されます。

Cloud Controlを使用した保護されたデータベースのホーム・ページへのアクセス

Cloud Controlの保護されたデータベースのホーム・ページは一元的なインタフェースを提供し、保護されたデータベースの構成、バックアップおよびリカバリ・タスクを管理できます。

保護されたデータベースのホーム・ページにアクセスするには:

  1. リカバリ・アプライアンス用のCloud Controlインタフェースを開き、保護されたデータベースのEnterprise Manager管理者としてログインします。
  2. 「ターゲット」メニューから、「データベース」を選択します。

    データベース・ページが表示されます。権限を有するすべての保護されたデータベースが一覧で表示されます。

  3. 「名前」列で、バックアップおよびリカバリ操作を実行する保護されたデータベースの名前をクリックします。

    選択した保護されたデータベースのホーム・ページが表示されます(図3-1を参照)。このページのメニュー・オプションを使用して、保護されたデータベースの構成、バックアップおよびリカバリ・タスクを実行します。

    図3-1 保護されたデータベースのホーム・ページ

    図3-1の説明が続きます。
    「図3-1 保護されたデータベースのホーム・ページ」の説明

保護されたデータベースのバックアップおよびリカバリ設定の構成(Cloud Control)

保護されたデータベースをリカバリ・アプライアンスにバックアップする前に、保護されたデータベースのバックアップおよびリカバリ設定を構成する必要があります。これらの構成済設定は、後続のバックアップおよびリカバリ操作で使用されます。

ノート:

Cloud Controlを使用して登録できる保護されたデータベースは、Oracle Database 11gリリース2 (11.2)以上です。リリース11.2より前のOracle Databaseでは、コマンドラインを使用してバックアップおよびリカバリ設定を構成してください。

Cloud Controlを使用した保護されたデータベースのバックアップ設定の構成

バックアップ設定では、保護されたデータベースのデフォルトのバックアップ環境を定義します。リアルタイムREDOトランスポートとポーリング位置を構成する設定では、リカバリ・アプライアンスへのバックアップの作成方法を定義します。その他の設定(制御ファイルの自動バックアップやバックアップの最適化など)では、保護されたデータベースのバックアップに関するベスト・プラクティスとパフォーマンス改善を定義します。これらの設定は、要件に基づいて構成できます。

Cloud Controlを使用して保護されたデータベースのバックアップ設定を構成するには:

  1. 「Cloud Controlを使用した保護されたデータベースのホーム・ページへのアクセス」の説明に従って、保護されたデータベースのホーム・ページにアクセスします。
  2. 「可用性」メニューから「バックアップとリカバリ」を選択し、次に「バックアップ設定」を選択します。

    保護されたデータベースの「バックアップ設定」ページが表示されます。図3-2に、「バックアップ設定」ページの「デバイス」タブを示します。「リカバリ・アプライアンス設定」セクションに、「リカバリ・アプライアンスへの保護されたデータベースの登録」で構成したリカバリ・アプライアンスおよびリカバリ・アプライアンス・ユーザーが表示されます。

    図3-2 保護されたデータベースの「バックアップ設定」ページ

    図3-2の説明が続きます
    「図3-2 保護されたデータベースの「バックアップ設定」ページ」の説明
  3. 「デバイス」タブで、次のオプション設定を構成します。

    • 保護されたデータベースのREDOデータをリカバリ・アプライアンスへ非同期に書き込むには、リカバリ・アプライアンス設定セクションでリアルタイムREDOトランスポートの有効化を選択します。

      関連項目:

      「リアルタイムREDOトランスポートについて」

    • 保護されたデータベースのバックアップのポーリングを構成する場合は、「ディスク設定」セクションの「ディスク・バックアップの場所」設定でポーリング位置を指定します。

      この位置をポーリング位置として指定している保護ポリシーが保護されたデータベースに割り当てられている場合、この位置に作成されたディスク・バックアップがリカバリ・アプライアンスによって自動的に取得されます。ポーリング・ポリシーはリカバリ・アプライアンス管理者が作成します。

      関連項目:

    • 保護されたデータベースがRAC上にある場合、オペレーティング・システムのログイン資格証明はすべてのノードで同じである必要があります。
  4. 「ポリシー」タブで、バックアップする必要のあるオブジェクトを定義する設定を構成します。

    このセクションの設定は必ずしも構成する必要はありませんが、制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップは構成することを強くお薦めします。表3-2に、これらの構成設定を示します。

    • 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを構成するには:

      • 「各バックアップとデータベースの構成変更ごとに、制御ファイルおよびサーバー・パラメータ・ファイル(SPFILE)を自動的にバックアップ」を選択します。

      • 「自動バックアップ・ディスクの場所」フィールドに、制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを格納する必要がある既存のディレクトリまたは自動ストレージ管理(ASM)のディスク・グループ名を指定します。場所が指定されていない場合、自動バックアップはローカルの高速リカバリ領域に格納されます。

    • バックアップの最適化を有効にするには、「バックアップ済の、読取り専用およびオフラインのデータファイルなどの未変更ファイルをスキップして、データベース全体のバックアップを最適化します」を選択します。

    • ブロック変更トラッキングを有効にするには、「増分バックアップの高速化のためブロック変更トラッキングを有効化」を選択し、「ブロック変更トラッキング・ファイル」フィールドにブロック変更トラッキング・ファイルの名前を指定します。

    • 「データベース全体のバックアップから除外される表領域」セクションには表領域を追加しないでください。

      ノート:

      リカバリ・アプライアンスにバックアップする場合は、保護されたデータベースの初期全体バックアップにすべての表領域が含まれている必要があります。

    • 「アーカイブREDOログの削除ポリシー」セクションで次のいずれかのオプションを選択し、保護されたデータベースのホストに格納されているローカル・バックアップのREDOログ・ファイルの削除についてRMANでどのように処理すべきかを指定します。

      • なし

        高速リカバリ領域にあるアーカイブREDOログが1回以上バックアップされているか、バックアップ保存ポリシーに基づいて不要になっている場合、これらのファイルは削除できます。

      • 指定回数バックアップされたアーカイブREDOログ・ファイルを削除

        「バックアップ」フィールドに指定された回数バックアップされたアーカイブREDOログ・ファイルを削除します。

    ノート:

    「保存ポリシー」セクションでは値を指定する必要はありません。保存ポリシーは、保護されたデータベースをリカバリ・アプライアンスに登録した際に関連付けられる保護ポリシーから継承されるため、「保存ポリシー」セクション内の設定はリカバリ・アプライアンスへのバックアップには使用されません。

  5. 「適用」をクリックしてバックアップ設定を保存します。

関連項目:

「保護されたデータベースのバックアップ設定の概要」

Cloud Controlを使用した保護されたデータベースのリカバリ設定の構成

リカバリ設定では、保護されたデータベースのデフォルトのリカバリ環境を定義します。リカバリ・アプライアンスの必須設定は、ログのアーカイブ・ファイル名の書式のみです。他のリカバリ設定は必要に応じて構成してください。

Cloud Controlを使用して保護されたデータベースのリカバリ設定を構成するには:

  1. 「Cloud Controlを使用した保護されたデータベースのホーム・ページへのアクセス」の説明に従って、保護されたデータベースのホーム・ページにアクセスします。
  2. 「可用性」メニューから「バックアップとリカバリ」を選択し、次に「リカバリ設定」を選択します。

    保護されたデータベースの「リカバリ設定」ページが表示されます(図3-3を参照)。

    図3-3 保護されたデータベースのリカバリ設定

    図3-3の説明が続きます
    「図3-3 保護されたデータベースのリカバリ設定」の説明
  3. 「インスタンス・リカバリ」セクションで、「平均リカバリ時間の指定(FAST_START_MTTR_TARGET)」を指定します。
  4. 「メディア・リカバリ」セクションで、次のステップを実行します。

    • (オプション)「ARCHIVELOGモード」を選択します。

    • (オプション)「ログのアーカイブ・ファイル名の書式」フィールドに、アーカイブREDOログ・ファイルの名前に使用する書式を指定します。

    • 「アーカイブREDOログの保存先」フィールドにアーカイブREDOログ・ファイルの格納先を入力するか、USE_DB_RECOVERY_FILE_DESTを指定してREDOログ・ファイルを必ずローカルの高速リカバリ領域に格納するように指示します。

      この保護されたデータベースの「バックアップ設定」でリアルタイムREDOトランスポートの有効化を選択している場合、アーカイブREDOログの保存先は自動的に設定されます。

  5. 保護されたデータベースのローカルの高速リカバリ領域を構成するには、「高速リカバリ」セクションで次のように指定します。

    • 「高速リカバリ領域の場所」フィールドに、バックアップ関連ファイルを格納するファイルシステムまたはASMの場所を指定します。保護されたデータベースの高速リカバリ領域を構成することをお薦めします。保護されたデータベースのローカル・バックアップは高速リカバリ領域に格納されます。

    • 「高速リカバリ領域サイズ」フィールドに、高速リカバリ領域に割り当てられるディスク領域の割当て制限を指定します。これは、この保護されたデータベース用のリカバリ領域で使用可能な記憶域の最大サイズです。高速リカバリ領域を構成する場合は、必ずサイズを指定する必要があります。

  6. 「適用」をクリックしてリカバリ設定を保存します。

関連項目:

Cloud Controlを使用した保護されたデータベースのバックアップ構成のクリア

保護されたデータベースのバックアップ構成をクリアし、既存のリカバリ・アプライアンス設定を削除できます。バックアップ構成をクリアすると、現在構成されているリカバリ・アプライアンスと仮想プライベート・カタログ・ユーザー、構成されている任意のRMANチャネル、およびリアルタイムREDOトランスポート構成が削除されます。

Cloud Controlを使用して保護されたデータベースのバックアップ構成をクリアするには:

  1. 「Cloud Controlを使用した保護されたデータベースのホーム・ページへのアクセス」の説明に従って、保護されたデータベースのホーム・ページにアクセスします。
  2. 「可用性」メニューから「バックアップとリカバリ」を選択し、次に「バックアップ設定」を選択します。

    保護されたデータベースの「バックアップ設定」ページが表示されます(図3-2を参照)。

  3. 「リカバリ・アプライアンス設定」セクションで、「構成のクリア」をクリックします。

    ノート:

    保護されたデータベースにリアルタイムREDOトランスポートが構成されていた場合、Cloud Controlでこの保護されたデータベースの「REDO送信」列の正確な状態を維持するよう手動でREDOログ・スイッチに強制する必要があります。

保護されたデータベースのバックアップおよびリカバリ設定の構成(コマンドライン)

通常のRMANコマンドを使用して、保護されたデータベースのバックアップおよびリカバリ設定を構成できます。これらの構成済設定は、後続のバックアップおよびリカバリ操作で使用されます。

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

コマンドラインを使用した保護されたデータベースのバックアップ設定の構成

保護されたデータベースのバックアップ設定のデフォルト値はRMANによって割り当てられます。CONFIGUREコマンドを使用すると、保護されたデータベースのバックアップ要件に応じて、これらの設定を変更できます。

コマンドラインを使用して保護されたデータベースのバックアップ設定を構成するには:

  1. 「CLIを使用した保護されたデータベースとリカバリ・アプライアンスへの接続」の説明に従って、RMANを使用して保護されたデータベースにTARGETとして接続します。

    次のコマンドでは、RMANを起動し、オペレーティング・システム認証を使用して保護されたデータベースにターゲットとして接続します。

    % rman target /
  2. CONFIGUREコマンドを使用して、必要なバックアップ設定を構成します。

    構成可能なバックアップ設定は次のとおりです。

    • 高速リカバリ領域

    • リカバリ・アプライアンスのメディア・マネージャ

      リカバリ・アプライアンス・バックアップ・モジュールを指すRMAN SBTチャネルを構成します。

    • バックアップの最適化

  3. (オプション)保護されたデータベースのREDOトランスポート・サービスを設定するには、「リアルタイムREDOトランスポートの構成」の説明に従って、リアルタイムREDOトランスポートを構成します。

関連項目:

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

リアルタイムREDOトランスポートを構成すると、保護されたデータベースのREDOデータはリカバリ・アプライアンスに直接トランスポートされて格納されます。これにより、連続するアーカイブ・ログ・バックアップ間に存在する潜在的なデータ損失の期間が最小限に抑えられます。

保護されたデータベースのリアルタイムREDOトランスポートを構成するステップは1回かぎりです。設定すると、保護されたデータベースのREDOデータはリカバリ・アプライアンスへ非同期にトランスポートされます。

ノート:

  • REDOトランスポートに使用するユーザーは、リカバリ・アプライアンスにバックアップを送信するために構成したのと同じユーザーである必要があります。

  • 保護されたデータベースのリアルタイムREDOトランスポート構成をクリアする場合、保護されたデータベースの正確な状態を維持するよう手動でREDOログ・スイッチに強制する必要があります。ログ・スイッチはリモート・サーバー・プロセス(RFS)を強制して、REDOデータのリカバリ・アプライアンスへの送信を停止します。

リアルタイムREDOトランスポートが機能するには、受信側データベースで物理ユーザーが作成されている必要があります。送信側インスタンスで、redo_transport_userを、REDOを受信するユーザーに設定します。

DataGuard以外の環境で、またはリカバリ・アプライアンスに対してREDOを送信するソース・データベースのみが存在する場合は、単にリカバリ・アプライアンス側でのredo_transport_userパラメータを、バックアップとREDOを受信する権限がありリカバリ・アプライアンス・データベース上の物理ユーザーである定義されているVPCユーザーに設定します。

DataGuard環境では、プライマリ・データベースによってスタンバイ・データベースにREDOが送信されているため、スタンバイ・データベースに、init.oraのredo_transport_userパラメータで指定されているのと同じ名前の物理ユーザーが存在する必要があります。

ノート:

redo_transport_userパラメータは、デフォルトでSYSアカウントに設定され、すべてのデータベースに存在します。そのため、プライマリ・データベース1つとスタンバイ・データベース1つのみの場合は、プライマリ・データベースでredo_transport_userを設定する必要はありません。SYSアカウントが使用されます。

リカバリ・アプライアンス環境も1つ以上あるData Guard環境では、VPCユーザーがSYS (またはスーパーユーザー権限)である必要はなく、redo_transport_userが、リカバリ・アプライアンス側で作成され定義されたVPCユーザーに設定されている必要があります。(これは、概念的にはdbms_ra.grant_db_accessに似ています。)プライマリ・データベースでは、リカバリ・アプライアンスへのログインにVPCユーザーが使用されているため、フィジカル・スタンバイ・データベースへのログインにもVPCユーザーが使用されています。ただし、デフォルトでは、VPCユーザーはフィジカル・スタンバイ・データベースに存在しません。これは、プライマリ・データベースに存在しないということでもあります。したがって、リアルタイムREDOをリカバリ・アプライアンスに対して構成する前に、まずプライマリ・データベースでVPCユーザーを作成して構成し、その情報がフィジカル・スタンバイ・データベースに適用されるようにする必要があります。また、ORAPWDファイル(リカバリ・アプライアンスで使用されるウォレットとは異なる)をプライマリからフィジカル・スタンバイにコピーする必要があります。これらの計画手順が完了したら、リカバリ・アプライアンスに対するREDOトランスポートの設定を続行できます。これらの手順の1つは、redo_transport_userパラメータをVPCユーザーに設定することです。これで、プライマリからスタンバイ、およびプライマリからリカバリ・アプライアンスへのREDOトランスポートでは、両方とも、ターゲット環境(スタンバイおよびリカバリ・アプライアンス)へのログインにそのVPCユーザーが使用されるようになります。

保護されたデータベースのリアルタイムREDOトランスポートを有効にするには:

  1. 保護されたデータベース・ユーザーがリカバリ・アプライアンスにバックアップを送信する際に使用する、リカバリ・アプライアンス・ユーザーが構成されていることを確認します。この同じユーザーが、REDOトランスポートにも使用されます。

    リカバリ・アプライアンス(およびREDOトランスポート)ユーザーの資格情報を含む、保護されたデータベースに、Oracleウォレットが作成されたことも確認します。このプロセスは、「保護されたデータベースでのOracleウォレットの作成」を参照してください。

    関連項目:

    リカバリ・アプライアンス・ユーザーが使用する仮想プライベート・カタログのアカウントの詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください

  2. 保護されたデータベースが次の条件を満たしていることを確認します。

    • ARCHIVELOGモードが有効になっていること

    • DB_UNIQUE_NAMEパラメータが設定されていること

  3. 保護されたデータベースに、初期化パラメータREMOTE_LOGIN_PASSWORDFILEおよびLOG_ARCHIVE_FORMATが設定されていることを確認します。
    REMOTE_LOGIN_PASSWORDFILE=exclusive
LOG_ARCHIVE_FORMAT='log_%d_%t_%s_%r.arc'

    REMOTE_LOGIN_PASSWORDFILEの設定値は、exclusiveかsharedのどちらかです。

  4. SQL*Plusを起動し、SYSDBAまたはSYSBACKUP権限を持つユーザーとして保護されたデータベースに接続します。

    次のコマンドでは、オペレーティング・システム認証を使用して、保護されたデータベースにSYSDBA権限で接続します。 

    % sqlplus / as sysdba
  5. LOG_ARCHIVE_CONFIG初期化パラメータをDG_CONFIGリストが含まれるように設定します。また、保護されたデータベースのDB_UNIQUE_NAMEも設定します。

    SYSDBA権限を持つユーザーとして保護されたデータベースに接続した場合、次のSQLコマンドを実行すると、db_unique_nameがhr_ptdbで、db_nameがhr_ptdbのDB_UNIQUE_NAMEパラメータおよび LOG_ARCHIVE_CONFIGパラメータが保護されたデータベースに設定されます。 

    ALTER SYSTEM SET DB_UNIQUE_NAME=hr_ptdb SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(zdlra2,hr_ptdb)' SCOPE=BOTH;

    リカバリ・アプライアンス・データベースのDB_NAMEおよびDB_UNIQUE_NAMEはzdlra2です。

    関連項目:

    DG_CONFIGリストの設定の詳細は、『Oracle Data Guard概要および管理』を参照してください。

  6. リカバリ・アプライアンス上のREDOステージング領域を指すようにアーカイブ・ログの保存先を構成します。

    アーカイブ・ログの保存先を構成するには、LOG_ARCHIVE_DEST_nパラメータ(nは1から31までの任意の数)の1つを設定します。REDOデータの格納先を指定するSERVICE属性を含める必要があります。この属性は、保護されたデータベースからのREDOストリームを格納するリカバリ・アプライアンス・データベースのネット・サービス名に設定します。

    次の例では、ネット・サービス名がbostonのリカバリ・アプライアンスにREDOデータを非同期にトランスポートするよう、保護されたデータベースを構成します。 

    ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=boston 
VALID_FOR=(ALL_LOGFILES, ALL_ROLES) ASYNC DB_UNIQUE_NAME=zdlra2' SCOPE=BOTH;

    関連項目:

    LOG_ARCHIVE_DEST_nパラメータの設定の詳細は、『Oracle Databaseリファレンス』を参照してください。

  7. ステップ6で構成したアーカイブREDOログの保存先でロギングを有効にするには、LOG_ARCHIVE_DEST_STATE_nパラメータ(nは、ステップ6で指定したLOG_ARCHIVE_DEST_nパラメータで使用されている値と一致)を設定します。

    次のコマンドでは、LOG_ARCHIVE_DEST_3パラメータを使用して設定した保存先でアーカイブREDOロギングを有効にします。 

    ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3='ENABLE' SCOPE=BOTH;

    関連項目:

    LOG_ARCHIVE_DEST_STATE_nパラメータの設定の詳細は、『Oracle Databaseリファレンス』を参照してください。

  8. この保護されたデータベース用に作成されたリカバリ・アプライアンス・ユーザーにREDOトランスポートを設定します(ステップ1を参照)。

    次の例では、REDOトランスポート・ユーザーをravpc1に設定します。 

    ALTER SYSTEM SET REDO_TRANSPORT_USER=ravpc1 SCOPE=BOTH;
  9. 保護されたデータベースを停止し、再起動します。
    SHUTDOWN IMMEDIATE;
STARTUP;

    保護されたデータベースでサーバー・パラメータ・ファイルのかわりにパラメータ・ファイルが使用されている場合、保護されたデータベースを起動する前に、ステップ5から8で設定したパラメータをパラメータ・ファイルに追加してください。

関連項目:

保護されたデータベースでのOracleウォレットの作成

Oracleウォレットには、保護されたデータベースがリカバリ・アプライアンスとの認証に使用するリカバリ・アプライアンス・ユーザーの資格証明が格納されます。これらの同じ資格証明は、構成されていればバックアップとREDOの送信にも使用されます。リカバリ・アプライアンス・バックアップ・モジュールをインストールすると、Oracleウォレットは自動的に作成されます。ウォレットと必須エントリの追加は、手動で行うこともできます。

ノート:

保護されたデータベースのsqlnet.oraファイルには、Oracleウォレットの場所が含まれている必要があります。ウォレットの場所は通常、リカバリ・アプライアンス・バックアップ・モジュールのインストール時に、このファイルに自動的に追加されます。

ノート:

エンタープライズ・ユーザー・セキュリティ(EUS) WALLET_ROOT形式を使用するデータベースは、保護されたデータベースの構成ではサポートされていません。WALLET_LOCATIONのみがサポートされています。

複数のZDLRAの場合、単一のウォレットを一元的な場所に格納し、各ZDLRA参照上にsqlnet.oraファイルを用意してウォレットの場所を一元管理します。

ウォレットを複数のZDLRA用の一元化された場所に格納できない場合は、すべてのインスタンスにコピーする必要があります。最初のインスタンスにウォレットおよびマスター・キーを作成し、そのウォレットを他のインスタンスにコピーします。さらに、データベース・ウォレットを分離するために環境変数ORACLE_UNQNAMEを設定します。その後、UNIX / Linuxの場合、sqlnet.oraから次のように動的に参照できます。 

WALLET_LOCATION =
  (SOURCE=(METHOD=FILE)
    (METHOD_DATA =
       (DIRECTORY=/etc/oracle/wallets/$ORACLE_UNQNAME/)))

Windowsベースのシステムでは、次のようにデータベースを動的に参照できます。

WALLET_LOCATION =
    (SOURCE =
      (METHOD = FILE)
      (METHOD_DATA =
        (DIRECTORY = E:\oracle\%ORACLE_UNQNAME%)))

Windowsに加えて、データベースORACLE_UNQNAME=<dbname>のWindowsレジストリ・キーを設定します。ただし、このレジストリ・キーはWindows上の1つのデータベースに対してしか設定できないため、このアプローチは現在、Windowsサーバー上でデータベースが1つしか実行されていない環境に制限されます。

例3-1 保護されたデータベースでのOracleウォレットの作成

次のコマンドでは、ravpc1という名前のリカバリ・アプライアンスのユーザーの資格証明を格納するOracleウォレットを作成します。 

$ mkstore                         \
  -wrl $ORACLE_HOME/oracle/wallet \
  -createALO                      \
  -createCredential zdlra01ingest-scan.acme.com:1521/zdlra01:dedicated ravpc1

ravpc1ユーザーのパスワードを要求された場合は入力します。ここで、zdlra01はリカバリ・アプライアンス・データベースのネット・サービス名です。mkstoreコマンドを実行する前に、ディレクトリ$ORACLE_HOME/oracle/walletが作成されている必要があります。

例3-2 複数のユーザー資格証明が含まれるOracleウォレットの作成

次のコマンドでは、保護されたデータベースのOracleウォレットに2組の資格証明を作成します。このシナリオの場合、ra_userは、通常のバックアップおよびリカバリ操作(さらに、有効な場合はリアルタイムREDO)の際にリカバリ・アプライアンスによっても使用され、データ同期の際にData Guardスタンバイ・データベースによっても使用されます。リカバリ・アプライアンスのサービス名はzdlra2で、Data Guard設定のプライマリ・データベースのサービス名はchicagoです。 

$ mkstore                                             \
  -wrl $ORACLE_HOME/oracle/wallet                     \
  -createALO                                          \
  -createCredential chicagoingest-scan.acme.com:1521/chicago:dedicated ra_user            \
  -createCredential zdlra02ingest-scan.acme.com:1521/zdlra02:dedicated ra_user

プロンプト表示されたら、ra_userのパスワードを入力します。mkstoreコマンドを実行する前に、ディレクトリ$ORACLE_HOME/oracle/walletが作成されている必要があります。

コマンドラインを使用した保護されたデータベースのリカバリ設定の構成

RMANによって割り当てられた、保護されたデータベースのリカバリ設定のデフォルト値を変更するには、CONFIGUREコマンドを使用します。

コマンドラインを使用して保護されたデータベースのリカバリ設定を構成するには:

  1. RMANを使用して、保護されたデータベースにTARGETとして接続します。

    次のコマンドでは、RMANを起動し、オペレーティング・システム認証を使用して保護されたデータベースにターゲットとして接続します。

    % rman target /
  2. 「保護されたデータベースのリカバリ設定の概要」の説明に従って、CONFIGUREコマンドを使用して必要なリカバリ設定を構成します。

関連項目:

Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド

リカバリ・アプライアンスのバックアップおよびリカバリ操作でのRMANチャネルの使用方法

リカバリ・アプライアンスとの間でバックアップをやり取りするには、リカバリ・アプライアンス・バックアップ・モジュールに対応するRMAN SBT (テープへのシステム・バックアップ)チャネルを使用する必要があります。

保護されたデータベースの操作にRMANチャネルを使用する場合、次の方法を使用できます。

関連項目:

リカバリ・アプライアンスで使用するRMAN SBTチャネルの構成

リカバリ・アプライアンスで使用するRMAN SBTチャネルを構成するには、RMAN CONFIGUREコマンドを使用します。保護されたデータベースにチャネルを構成すると、その保護されたデータベースでのバックアップ、リストアおよびメンテナンスのすべての操作に適用可能な永続設定が作成されます。構成済の設定は、特定の操作でALLOCATEコマンドを使用して明示的に削除、変更またはオーバーライドされるまで有効なままです。

例3-3では、リカバリ・アプライアンスで使用するRMAN SBTチャネルを構成します。これを構成した後は、リカバリ・アプライアンス・バックアップ・モジュールに対応するSBTチャネルをバックアップまたはリカバリ操作ごとに明示的に割り当てる必要はありません。

例3-3 リカバリ・アプライアンスで使用するRMANチャネルの構成

この例では、リカバリ・アプライアンス・バックアップ・モジュールを指しているSBT_LIBRARYパラメータを使用して、RMAN SBTチャネルを構成します。共有ライブラリlibra.soの完全パスが指定されています。RA_WALLETパラメータは、この保護されたデータベースとリカバリ・アプライアンスとの認証に使用する資格証明が格納されているOracleウォレットの場所を表します。ra-scanはリカバリ・アプライアンスのSCANで、zdlra5はリカバリ・アプライアンスのメタデータ・データベースのサービス名です。 

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' 
PARMS 'SBT_LIBRARY=/u01/app/oracle/product/11.2.0.4.0/dbhome_1/lib/libra.so,
ENV=(RA_WALLET=location=file:/u01/app/oracle/product/11.2.0.4.0/dbhome_1/dbs/zdlra 
credential_alias=ra-scan:1521/zdlra5:dedicated)' FORMAT '%U_%d';
リカバリ・アプライアンスで使用するRMAN SBTチャネルの割当て

リカバリ・アプライアンスへのバックアップまたはリカバリ・アプライアンスからのリカバリに使用するRMAN SBTチャネルを割り当てるには、RMAN ALLOCATEコマンドを使用します。特定の操作では、操作前にRMAN SBTチャネルを明示的に割り当てることにより、CONFIGUREコマンドで設定済の永続構成をオーバーライドできます。ALLOCATEコマンドとその他のコマンドをRUNブロックで囲みます。

例3-4では、リカバリ・アプライアンスで使用するRMAN SBTチャネルを割り当ててから、アーカイブREDOログを含む保護されたデータベースの全体バックアップを作成します。

例3-4 リカバリ・アプライアンスで使用するRMANチャネルの割当て

この例では、リカバリ・アプライアンス・バックアップ・モジュールの完全パスを指定するSBT_LIBRARYパラメータを使用して、RMAN SBTチャネルを割り当てます。ENV設定では、リカバリ・アプライアンス・バックアップ・モジュールで使用する構成パラメータを指定します。ra-scanはリカバリ・アプライアンスのSCANで、zdlra5はリカバリ・アプライアンスのメタデータ・データベースのサービス名です。 

RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt_tape 
PARMS='SBT_LIBRARY=/u01/app/oracle/product/12.1.0.2/dbhome_1/lib/libra.so,
ENV=(RA_WALLET=location=file:/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs 
credential_alias=ra-scan:1521/zdlra5:dedicated)' FORMAT '%U_%d';
BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
}

暗号化されたSBTの構成

LIBRA.SOモジュールでは、レガシー・モード(RA21.1)と暗号化SBTオプション(RA23.1)の両方がサポートされています。どちらのモードでも外部パスワード・ストアは同じ方法で作成されますが、RMAN SBTチャネルは異なる方法で構成されます。

この情報はRA 23.1以降に適用されます。

  1. 安全性の高い外部パスワード・ストア(mkstore)を作成します。次のコマンドでは、ravpc1という名前のリカバリ・アプライアンスのユーザーの資格証明を格納するOracleウォレットを作成します。 

    $ mkstore                         \
  -wrl $ORACLE_HOME/oracle/wallet \
  -createALO                      \
  -createCredential zdlra01ingest-scan.acme.com:1521/zdlra01:dedicated ravpc1

    参照: 保護されたデータベースでのOracleウォレットの作成

  2. リカバリ・アプライアンス・バックアップ・モジュールを指しているSBT_LIBRARYパラメータを使用して、RMAN SBTチャネルを構成します。共有ライブラリlibra.soの完全パスが指定されています。RA_WALLETパラメータは、この保護されたデータベースとリカバリ・アプライアンスとの認証に使用する資格証明が格納されているOracleウォレットの場所を表します。ra-scanはリカバリ・アプライアンスのSCANで、zdlra5はリカバリ・アプライアンスのメタデータ・データベースのサービス名です。 

    CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' 
PARMS 'SBT_LIBRARY=/u01/app/oracle/product/19.0.0.0/dbhome_1/lib/libra.so,
ENV=(RA_FORMAT=true,
RA_WALLET=location=file:/u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/zdlracredential_alias=ra-scan:1521/zdlra5:dedicated)' 
FORMAT '%U_%d';

  3. この他に、RMAN圧縮およびRMAN暗号化を構成する必要があります。これは、1回のみ実行することも、各バックアップ・ジョブの一部として実行することもできます。

    configure compression algorithm  'low';
set encryption on;
configure device type 'sbt_tape' backup type to compressed backupset;

  4. リカバリ・アプライアンス・バックアップ・モジュールの完全パスを指定するSBT_LIBRARYパラメータを使用して、RMAN SBTチャネルを割り当てます。ENV設定では、リカバリ・アプライアンス・バックアップ・モジュールで使用する構成パラメータを指定します。ra-scanはリカバリ・アプライアンスのSCANで、zdlra5はリカバリ・アプライアンスのメタデータ・データベースのサービス名です。 

    set echo on
configure compression algorithm 'low';
set encryption on;
configure device type 'sbt_tape' backup type to compressed backupset;
RUN{ALLOCATE CHANNEL c1 DEVICE TYPE sbt_tape 
PARMS='SBT_LIBRARY=/u01/app/oracle/product/19.0.0.0/dbhome_1/lib/libra.so,
ENV=(RA_FORMAT=true, 
RA_WALLET=location=file:/u01/app/oracle/product/19.0.0.0/dbhome_1/dbs/zdlracredential_alias=ra-scan:1521/zdlra5:dedicated)' 
FORMAT '%U_%d';
BACKUP INCREMENTAL LEVEL 1 FILESPERSET 1 SECTION SIZE 64G DATABASE PLUS ARCHIVELOG NOT BACKED UP FILESPERSET 8;}

  5. 上の内容は、保護されたデータベースによって実行されます。リカバリ・アプライアンス管理者が、これが実行されていることを認識する必要はありません。ただし、リカバリ・アプライアンス管理者は、暗号化されていないデータがアプライアンスに送信されないようにすることができます。これは、CREATE_PROTECTION_POLICYまたはUPDATE_PROTECTION_POLICYを使用して、パラメータSECURE_MODE = YESを指定することで実現されます。 

    SQL> exec dbms_ra.update_protection_policy(
protection_policy_name => ‘GOLD’, 
secure_mode => ‘YES’);

  6. この構成の後に、暗号化されていない(レガシー)バックアップを実行しようとすると、次のようなエラー・メッセージが表示されます:

    RMAN-00571:
===========================================================RMAN-00569: =============== ERROR
MESSAGE STACK FOLLOWS ===============RMAN-00571:
===========================================================RMAN-03009: failure of backup
command on channel_29 channel at 01/19/2023 10:27:06ORA-27192: skgfcls: sbtclose2
returned error - failed to close fileORA-19511: non RMAN, but media
manager or vendor specific failure, error text:KBHS-01404:  See trace file
/u01/app/oracle/diag/rdbms/<dbuniquename>/<sid>/trace/sbtio_204486_140658931245376.log  for
detailsKBHS-00719: Error 'recovery
appliance Error'; ORA-64868: Only RMAN encrypted backups are supported on this Recovery
Appliance.
KBHS-00700: HTTP

  7. また、リアルタイムREDOが有効になっている場合は、LADパラメータをENCRYPTION=enableに設定する必要があります。 

    ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=boston 
VALID_FOR=(ALL_LOGFILES, ALL_ROLES) 
ASYNC DB_UNIQUE_NAME=zdlra2 encryption=enable' SCOPE=BOTH;

    これがないと、リカバリ・アプライアンス管理者にこのメッセージが表示されます。

    2023-01-19T18:25:41.933868+00:00
Recovery Appliance failure on ospid: 221805; 
Errors: ORA-64869: Unencrypted redo is not allowed for database <dbname>.

この情報は、RA 21.1以前に適用されます。

  1. 安全性の高い外部パスワード・ストア(mkstore)を作成します。次のコマンドでは、ravpc1という名前のリカバリ・アプライアンスのユーザーの資格証明を格納するOracleウォレットを作成します。 

    $ mkstore                         \
  -wrl $ORACLE_HOME/oracle/wallet \
  -createALO                      \
  -createCredential zdlra01ingest-scan.acme.com:1521/zdlra01:dedicated ravpc1

    参照: 保護されたデータベースでのOracleウォレットの作成

  2. リカバリ・アプライアンス・バックアップ・モジュールを指しているSBT_LIBRARYパラメータを使用して、RMAN SBTチャネルを構成します。共有ライブラリlibra.soの完全パスが指定されています。RA_WALLETパラメータは、この保護されたデータベースとリカバリ・アプライアンスとの認証に使用する資格証明が格納されているOracleウォレットの場所を表します。ra-scanはリカバリ・アプライアンスのSCANで、zdlra5はリカバリ・アプライアンスのメタデータ・データベースのサービス名です。 

    CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' 
PARMS 'SBT_LIBRARY=/u01/app/oracle/product/11.2.0.4.0/dbhome_1/lib/libra.so,
ENV=(RA_WALLET=location=file:/u01/app/oracle/product/11.2.0.4.0/dbhome_1/dbs/zdlra 
credential_alias=ra-scan:1521/zdlra5:dedicated)' FORMAT '%U_%d';

    参照: リカバリ・アプライアンスで使用するRMAN SBTチャネルの構成

保護されたデータベースの場合のTLS

リカバリ・アプライアンスとクライアント・データベースの間のTransport Layer Security (TLS)では、通信を認証し暗号化する証明書の使用が必要です。

  • 信頼できる証明書は、通常は、申請プロセス(企業レベル)を介して信頼できる認証局(CA)から取得されます。これらの証明書は、通常は、外部システム間で使用されます。これらはCAによって作成されているため、これらの証明書にはローカル・ホスト名が含まれていません。ファイル・タイプは*.pemです。

  • 署名付き証明書は、必要に応じて作成され、ローカル・ホスト名を含んでいます。また、それが本物であることを証明する内容の一部として、場所と組織の情報を含んでいます。これらの証明書は、多くの場合、ローカルまたは内部システム間で使用されます。署名付き証明書は、各リカバリ・アプライアンスに固有です。ファイル・タイプは*.p12です。

両方のタイプの証明書が必須です。

証明書の取得または作成の詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』のTLSの概要を参照してください。

テスト・バックアップおよびリカバリ操作の実行

保護されたデータベースをリカバリ・アプライアンスに登録した後で、テスト・バックアップおよびリカバリ操作を実行することをお薦めします。このテストにより、構成設定が正確であること、およびリカバリ・アプライアンスへのバックアップとリカバリ・アプライアンスからのリカバリが正常に実行されることを確認できます。テスト・バックアップまたはリカバリでなんらかの問題が発生した場合は、設定を修正して保護されたデータベースを再構成できます。

コマンドラインを使用したテスト・バックアップの実行

保護されたデータベースをリカバリ・アプライアンス用に構成した後でテスト・バックアップを試行することにより、リカバリ・アプライアンスへの接続をテストできます。

保護されたデータベースのテスト・バックアップを作成するには:

  1. 「CLIを使用した保護されたデータベースとリカバリ・アプライアンスへの接続」の説明に従って、保護されたデータベースにTARGETとして接続し、リカバリ・アプライアンス・カタログにCATALOGとして接続します。
  2. 「リカバリ・アプライアンスで使用するRMAN SBTチャネルの構成」の説明に従って、リカバリ・アプライアンス用にRMAN SBTチャネルを構成します。

    チャネル数を選択する際の適切なガイドラインとしては、増分バックアップで現在使用しているチャネル数、またはコア数/CPU数に応じてノード当たり2つまたは4つのチャネル数(デフォルト)から始めることをお薦めします。

  3. 次のRMANコマンドを使用して、全体バックアップを実行します。
    BACKUP DEVICE TYPE SBT CUMULATIVE INCREMENTAL LEVEL 1 DATABASE
    PLUS ARCHIVELOG FORMAT %d_%U;

    このBACKUPコマンドは、レベル0のバックアップが存在しない場合に初めて実行されるとき、新しいレベル0のバックアップを作成します。

    ノート:

    リカバリ・アプライアンスでは、バックアップする必要があるログを追跡し、同じアーカイブREDOログを重複してバックアップしないようにしているので、アーカイブREDOログを定期的なバックアップに含めることができます。アーカイブREDOログを含めておくと、ギャップが存在する場合に役立ちます。アーカイブREDOログがないと、ギャップの検出が遅れる可能性があります。

コマンドラインを使用したテスト・リカバリの実行

保護されたデータベースのテスト・バックアップをリカバリ・アプライアンスに作成した後で、テスト・リカバリを実行してこのバックアップを検証できます。

保護されたデータベースのテスト・リカバリを実行するには:

  1. 保護されたデータベースを停止してからNOMOUNTモードで再起動します。
  2. 保護されたデータベースにはTARGETとして、リカバリ・アプライアンス・カタログにはCATALOGとして接続します。
  3. 「リカバリ・アプライアンスで使用するRMAN SBTチャネルの構成」の説明に従って、リカバリ・アプライアンス用にRMAN SBTチャネルを構成します。
  4. 次のRMANコマンドを使用して、前に作成済のテスト・バックアップをリカバリ・アプライアンスからリストアします。VALIDATEオプションを使用すると、本番データベースを妨げずにこれを行うことができます。
    RESTORE VALIDATE DATABASE;

これらのバックアップおよびリカバリ手順が正常に実行されたら、クライアント・データベースではリカバリ・アプライアンスへの定期バックアップをいつでも実行できます。

Cloud Controlを使用したテスト・バックアップの実行

保護されたデータベースを構成した後で、テスト・バックアップを実行して構成が正確であることを確認します。

Cloud Controlを使用してテスト・バックアップを実行するには:

  1. 「Cloud Controlを使用した保護されたデータベースのホーム・ページへのアクセス」の説明に従って、保護されたデータベースのホーム・ページにアクセスします。
  2. 「可用性」メニューから「バックアップとリカバリ」を選択し、次に「バックアップ設定」を選択します。

    「バックアップ設定」ページの「デバイス」タブが表示されます。図3-4に、このページのリカバリ・アプライアンス設定セクションを示します。

    図3-4 「バックアップ設定」ページのリカバリ・アプライアンス設定セクション

    図3-4の説明が続きます
    「図3-4 「バックアップ設定」ページのリカバリ・アプライアンス設定セクション」の説明
  3. リカバリ・アプライアンス設定セクションで、「テスト・バックアップ」をクリックします。

    Cloud Controlによりテスト・バックアップが開始され、「処理中: リカバリ・アプライアンスへのバックアップのテスト」ページが表示されます。

    バックアップが成功した場合は、リカバリ・アプライアンスへのバックアップのテストが成功しました。というメッセージが表示されます。

    バックアップの実行時にエラーが発生すると、リカバリ・アプライアンスへのバックアップのテストが失敗しましたというエラー・メッセージが表示されます。「エラーの詳細を表示」をクリックすると、エラーの原因に関する詳細情報が含まれている「エラーの詳細を表示」ページが表示されます。問題を修正してからテスト・バックアップを実行します。

リカバリ・アプライアンスにバックアップを送信するための複数の保護されたデータベースの構成

リカバリ・アプライアンスにバックアップを送信するように構成されている場合、データベースはリカバリ・アプライアンスによって保護されます。

この手順は、Enterprise Manager (EM)の「バックアップ設定」ページを使用して個々のデータベースで実行できます。ただし、Enterprise Managerコマンドライン・インタフェース(EMCLI)のconfigure_db_haコマンドを使用すると、複数のデータベースを同時に構成しやすくなります。

保護されたデータベースは様々なハードウェア・プラットフォームでホストできるため、各プラットフォームに対応したRMANバックアップ・モジュールが必要です。このモジュールの新しいバージョンが使用可能になり、多数のシステムにインストールする必要がある場合、同じemcli configure_db_haコマンドによって、この複雑なメンテナンス・タスクが大幅に簡略化されます。

これらのシナリオは独立しています。EMで保護されたデータベース管理が処理されると、保護されたデータベースごとにシナリオ#1が1回実行された後、これらのシナリオのバリエーションを使用して定期的なメンテナンスが実行されます。

シナリオ#2では、最新バージョンのRMANリカバリ・アプライアンス・バックアップ・モジュールをEMソフトウェア・ライブラリにアップロードする必要があります。これは必要に応じて手動で、またはスケジュールされたジョブで実行できます。

最新バージョンのRMANリカバリ・アプライアンス・バックアップ・モジュールを使用したEMソフトウェア・ライブラリの更新

この項は、保護されたデータベースによって使用されるRMANリカバリ・アプライアンス・バックアップ・モジュールがEnterprise Manager (EM)で管理されている場合に必須です。これは、EMのソフトウェア・ライブラリに最新のRMANモジュールを提供するためです。

RMANリカバリ・アプライアンス・バックアップ・モジュールは、保護されたデータベースがホストされているサポート対象のオペレーティング・システムごとに異なります。

この項のステップでは、最新バージョンのRMANリカバリ・アプライアンス・バックアップ・モジュールでソフトウェア・ライブラリを更新します。その後、EMは、保護されたデータベースごとに適切なRMANモジュールをソフトウェア・ライブラリからインストールします。

オプション1: ソフトウェア・ライブラリへのRMANモジュールの自動アップロードのためのEMの構成

このオプションでは、Oracle Cloud上のRMANリカバリ・アプライアンス・バックアップ・モジュールの新しいバージョンを検索してEMにダウンロードする、繰返しのジョブをEMで作成します。

このオプションは、RMANリカバリ・アプライアンス・バックアップ・モジュールを検索してダウンロードするために、EMがOracle Cloudに直接アクセスできることを前提としています。「ソフトウェア・ライブラリ内の高可用性ソフトウェアの更新」のジョブをEMでスケジュールします

  1. EMで、「ジョブ・ライブラリ」に移動します。
  2. 「ライブラリ・ジョブの作成」のプルダウンで、「ソフトウェア・ライブラリ内の高可用性ソフトウェアの更新」を選択し、「実行」を選択します。

    図3-5 ライブラリ・ジョブの作成

    図3-5の説明が続きます。
    「図3-5 ライブラリ・ジョブの作成」の説明
  3. ライブラリ・ジョブの名前を指定します。この例では、名前は"updateRA3"です。

    図3-6 「ライブラリ・ジョブの作成」、「一般」タブ

    図3-6の説明が続きます。
    「図3-6 「ライブラリ・ジョブの作成」、「一般」タブ」の説明
  4. 「パラメータ」タブおよび「バックアップ・モジュール・タイプ」のプルダウンで、「リカバリ・アプライアンス」を選択します。

    図3-7 「ライブラリ・ジョブの作成」、「パラメータ」タブ

    図3-7の説明が続きます。
    「図3-7 「ライブラリ・ジョブの作成」、「パラメータ」タブ」の説明
  5. 「スケジュール」タブで、このジョブのスケジュールの適切な詳細を入力します。このジョブは、Oracle Cloudで新しいバックアップ・モジュール・バージョンを定期的にチェックできるように、繰返しのスケジュール(週1回など)で実行することを目的としています。

    図3-8 「ライブラリ・ジョブの作成」、「スケジュール」タブ

    図3-8の説明が続きます。
    「図3-8 「ライブラリ・ジョブの作成」、「スケジュール」タブ」の説明

その後、このジョブがスケジュールされた時間に実行されると、サポートされているすべてのデータベース・プラットフォーム用のRMANリカバリ・アプライアンス・バックアップ・モジュールの最新バージョンが格納される、Oracle Cloud内の指定の場所がスキャンされます。そのバージョンがEMソフトウェア・ライブラリで保持されている最新バージョンと比較されます。Oracle Cloudで検出されたバージョンのほうが新しい場合、サポートされているすべてのプラットフォームのバージョンがソフトウェア・ライブラリにダウンロードされます。古いバージョンのRMANバックアップは、ソフトウェア・ライブラリにアーカイブされます。

emcli config_db_haコマンドを使用すると、EMによって管理されている保護されたデータベースのRMANバックアップ・モジュールがこの新しいバージョンに更新されます。

新しいバックアップ・モジュール・バージョンが検出され、ソフトウェア・ライブラリにダウンロードされた場合のジョブ出力の例を次に示します。

図3-9 新しいソフトウェア・モジュールが見つかった場合のジョブ出力

図3-9の説明が続きます。
「図3-9 新しいソフトウェア・モジュールが見つかった場合のジョブ出力」の説明
オプション2: EMCLIを使用したRMANバックアップ・モジュールのソフトウェア・ライブラリへの手動アップロード

このオプションは、新しいバージョンのRMANリカバリ・アプライアンス・バックアップ・モジュールをEMソフトウェア・ライブラリに配布することが必要になるたびに繰り返される手動のステップです。

このオプションは、EMがOracle Cloudに直接アクセスできない場合のオフライン・モード用です。

  1. (サポートされているすべてのプラットフォーム用の)RMANリカバリ・アプライアンス・バックアップ・モジュールの新しいバージョンを、Oracle Cloudから、EMCLIコマンドが起動されるシステムにアクセス可能な場所に手動でダウンロードします。

    この例では、LinuxおよびAIXプラットフォームの最新のバックアップ・モジュール・バージョンがOracle Cloudから/homeディレクトリにダウンロードされました。

  2. EMCLIを使用して、ソフトウェア・ライブラリに新しいバージョンを取得します。

    emcli configure_db_ha –uploadBackupModule –module_type="ra" –module_location="/home/ra_linux64.zip,/home/ra_aix.zip"

    複数のプラットフォーム用の新しいモジュール・バージョンを同時にソフトウェア・ライブラリにアップロードできます。

    前述の例では、前にOracle Cloudから/homeディレクトリにダウンロードされたLinuxおよびAIXプラットフォームの最新バージョンがソフトウェア・ライブラリで使用可能になっています。

このコマンドの使用方法と、次に説明するconfigure_db_ha動詞のその他の形式は、Cloud Controlコマンドライン・インタフェース・ガイドを参照してください。

シナリオ#1: リカバリ・アプライアンスにバックアップを送信するための複数の保護されたデータベースの構成

Enterprise Managerを使用して、複数の保護されたデータベースの構成を管理します。

リカバリ・アプライアンス管理者が保護されたデータベースを登録した後、バックアップおよびREDOをリカバリ・アプライアンスに送信するためにデータベースをローカルで構成する必要があります。この構成手順は、Enterprise Manage (EM)の「バックアップ設定」ページから個々のデータベースに対して実行できます。ただし、EMユーザー・インタフェースを介して複数のデータベースに対してこの手順を実行するのは実用に向かない場合もあります。

複数のデータベースの登録は、EMコマンドライン・インタフェース(EMCLI)およびconfigure_db_ha -configureRABackupコマンドを使用することでより簡単に実現できます。これは複数のデータベースの構成手順を同時に実行します。

次の例では、個々のデータベースおよび複数のデータベースの初期構成を実行するための、このコマンドの様々な使用方法を示します。

単一インスタンス・データベース

次のemcli configure_db_ha –configureRABackupの例では、バックアップおよびREDOをリカバリ・アプライアンスに送信する単一インスタンス・データベースを構成します。

RMANバックアップ・モジュールがデータベースのOracleホームにすでにインストールされている場合、ソフトウェア・ライブラリから最新のRMANバックアップ・モジュールはインストールされません。このコマンドは、EM名前付きデータベースおよびホスト資格証明を使用します。

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –target_name="Finance" –target_type="oracle_database" –db_cred="DB_USER" –db_host_cred="DB_HOST_USER" –enable_redo_ship

1つのクラスタ・データベース

次のemcli configure_db_ha –configureRABackupの例では、バックアップをリカバリ・アプライアンスに送信する1つのクラスタ・データベースを構成します。

このコマンドでは–enable_redo_shipオプションを使用しないため、REDOログは送信されません。–force_backup_module_installオプションは、最新のRMANバックアップ・モジュールをソフトウェア・ライブラリから各クラスタ・データベース・インスタンスのOracleホームにインストールすることを指定します。このコマンドは、EM名前付きデータベースおよびホスト資格証明を使用します。

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –target_name="Finance" –target_type="rac_database" –force_backup_module_install

単一インスタンスおよびクラスタ・データベース

次のemcli configure_db_ha –configureRABackupの例では、入力ファイル–input_file="/tmp/dblist"を使用して、構成する単一インスタンスおよびクラスタ・データベースを指定します。

–enable_redo_shipオプションを指定すると、バックアップおよびREDOログがリカバリ・アプライアンスに送信されます。–force_backup_module_installオプションは、最新のRMANバックアップ・モジュールをソフトウェア・ライブラリから各データベースのOracleホームにインストールすることを指定します。このコマンドでは、すべてのデータベースで同じEM名前付きデータベースとホスト資格証明が使用されます。

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –input_file="/tmp/dblist" –db_cred="DB_USER" –db_host_cred=" DB_HOST_USER" –enable_redo_ship –force_backup_module_install –staging_directory=”/tmp/stage"

この例で使用されている入力ファイル/tmp/dblistの内容は、単一インスタンス・データベースおよびクラスタ・データベースを指定します 

target.0.target_name=db1
target.0.target_type=oracle_database
target.1.target_name=rac1
target.1.target_type=rac_database
入力ファイルからの複数のデータベース

次のemcli configure_db_ha –configureRABackupの例では、入力ファイル–input_file="/tmp/dblist"を使用して、構成するデータベースを指定します。

–enable_redo_shipオプションを指定すると、バックアップおよびREDOログがリカバリ・アプライアンスに送信されます。RMANバックアップ・モジュールがデータベースのOracleホームにすでにインストールされている場合、ソフトウェア・ライブラリから最新のRMANバックアップ・モジュールはインストールされません。-scheduleオプションは、操作の将来の時間を設定します。このコマンドでは、すべてのデータベースで同じEM名前付きデータベースとホスト資格証明が使用されます。

emcli configure_db_ha –configureRABackup –ra_target_name="Chicago ZDLRA" –ra_user="rauser1" –input_file="/tmp/dblist" –db_cred="DB_USER" –db_host_cred="DB_HOST_USER" –enable_redo_ship -schedule="start_time:2016/06/28 18:31;tz:PST;"

保護されたデータベースの構成のメンテナンス

emcli configure_db_ha -configureRABackupコマンドのバリエーションを必要に応じて同じデータベースに対して再実行して、構成を更新することもできます。

ローカル・データベース構成のすべての側面(ウォレット、バックアップ・モジュール、RMAN構成など)は、コマンドによって起動されるEMデプロイメント・プロシージャによって必要に応じて自動的に更新されます。このようにして、複数のデータベースの構成の継続的なメンテナンスを1つのコマンドで行うことができます。

メンテナンス・シナリオの例を次に示します。

  • VPCユーザー・パスワードの変更後に、保護されたデータベースごとに使用される仮想プライベート・カタログ(VPC)資格証明を更新して、リカバリ・アプライアンスにバックアップを送信します。VPCユーザーに対応するEM名前付き資格証明が更新済(このVPCユーザーを使用するEM操作に必要)であることを前提として、EMデプロイメント・プロシージャによって、すべての保護されたデータベースのウォレットが新しい資格証明で自動的に更新されます。

  • 保護されたデータベースごとのすべてのOracleホームでリカバリ・アプライアンスRMANバックアップ・モジュールを更新します。これは、保護されたデータベース構成全体の一部として、またはスタンドアロン操作として個別に実行できます。データベース構成時に-force_backup_module_installオプションが指定された場合、EMデプロイメント・プロシージャは、各Oracleホームのバックアップ・モジュールをEMソフトウェア・ライブラリに存在する最新バージョンで更新します。

  • リカバリ・アプライアンスへのREDO送信がまだ有効になっていないデータベースで、REDO送信を有効にします。これは、-enable_redo_shipオプションと、REDO送信を有効にするデータベースをリストした入力ファイルを指定してコマンドを再実行することで行うことができます。

完全な構文および入力ファイルの形式については、EMコマンドライン・インタフェースを参照してください。

シナリオ#2: 複数の保護されたデータベースのRMANリカバリ・アプライアンス・バックアップ・モジュールの更新

このシナリオでは、コマンドemcli configure_db_ha -installSoftwareを使用して、複数の保護されたデータベースのRMANリカバリ・アプライアンス・バックアップ・モジュールを更新します。

次の例では、個々のデータベースと複数のデータベースに対するこのコマンドの様々な使用方法を示します。

単一インスタンス・データベースへのRMANバックアップ・モジュールのインストール

次のemcli configure_db_ha –installSoftwareの例では、RMANモジュールが存在しない場合、最新のRMANバックアップ・モジュールが、ソフトウェア・ライブラリから単一インスタンス・データベースのOracleホームにインストールされます。

このコマンドは、EM名前付きデータベースおよびホスト資格証明を使用します。

emcli configure_db_ha –installSoftware –install_backup_module –module_type=“ra" –target_name=“db1" –target_type="oracle_database" –db_host_cred="OMS_HOST_CRED"

クラスタ・データベースへのRMANバックアップ・モジュールのインストール

次のemcli configure_db_ha –installSoftwareの例では、最新のRMANバックアップ・モジュールが、ソフトウェア・ライブラリから1つのクラスタ・データベースの各インスタンスのOracleホームにインストールされます。

–force_backup_module_installオプションは、モジュールがすでにインストールされているかどうかにかかわらず、最新のRMANバックアップ・モジュールをソフトウェア・ライブラリから各データベースのOracleホームにインストールすることを指定します。このコマンドでは、すべてのデータベースで同じEM名前付きデータベースとホスト資格証明が使用されます。

emcli configure_db_ha –installSoftware –install_backup_module –module_type=”ra” –target_name="Finance" –target_type="rac_database" –force_backup_module_install –db_host_cred="DB_HOST_USER"

複数のデータベースへのRMANバックアップ・モジュールのインストール

次のemcli configure_db_ha –installSoftwareの例では、入力ファイルを使用して、最新のRMANバックアップ・モジュールを受信するデータベースを指定します。

–force_backup_module_installオプションは、モジュールがすでにインストールされているかどうかにかかわらず、最新のRMANバックアップ・モジュールをソフトウェア・ライブラリから各データベースのOracleホームにインストールすることを指定します。操作は、将来のスケジュール開始時間です。

emcli configure_db_ha –installSoftware –install_backup_module –module_type=“ra“ –force_backup_module_install –input_file=“/tmp/dblist“ -schedule="start_time:2016/06/28 18:31;tz:PST;

–input_file="/tmp/dblist"の内容は、このコマンドで使用される単一インスタンスおよびクラスタ・データベースを指定します。 

target.0.target_name=db1
target.0.target_type=oracle_database
target.0.db_cred=DB_SYS_CRED
target.0.db_host_cred=HOST__CRED1
target.1.target_name=rac1
target.1.target_type=rac_database
target.1.db_cred=DB_SYS_CRED2
target.1.db_host_cred=HOST_CRED2

入力ファイルでは、各データベースに対して異なるデータベースとホストの名前付き資格証明を指定します。これは、複数のデータベースに1つの入力ファイルを使用することで提供される柔軟性を示しています。