1. バックアップおよびリカバリ・ユーザーズ・ガイド
  2. RMANのバックアップの管理
  3. リカバリ・カタログの管理

13 リカバリ・カタログの管理

RMANリカバリ・カタログの管理には、カタログの作成、カタログへのデータベースの登録、仮想プライベート・カタログの作成などのタスクが含まれます。

この章では、RMANリカバリ・カタログを管理する方法について説明します。 この章のトピックは、次のとおりです:

関連項目:

13.1 RMANリカバリ・カタログの概要

この項では、リカバリ・カタログの管理に関連する基本的な概念について説明します。

13.1.1 RMANリカバリ・カタログの目的

リカバリ・カタログとは、1つ以上のOracle Databaseに関するメタデータを格納するためにRMANで使用されるデータベース・スキーマのことです。通常、このカタログは専用のデータベースに格納します。

リカバリ・カタログには、次のメリットがあります。

  • リカバリ・カタログによって、各ターゲット・データベースの制御ファイルに格納されているRMANリポジトリに対して冗長性が作成されます。リカバリ・カタログは、セカンダリ・メタデータ・リポジトリとして機能します。ターゲット制御ファイルおよびすべてのバックアップが消失した場合でも、RMANメタデータはリカバリ・カタログ内に存在します。

  • リカバリ・カタログによって、すべてのターゲット・データベースのメタデータが集中化されます。メタデータを1つの場所に格納することによって、レポート・タスクおよび管理タスクの実行が簡単になります。

  • リカバリ・カタログには、制御ファイルより長期のメタデータ履歴を格納できます。この機能は、制御ファイルの履歴より前の時点にリカバリする必要がある場合に有効です。リカバリ・カタログ・データベースを使用することによって管理はより複雑になりますが、より長期のバックアップ履歴を使用できるというメリットがあります。

一部のRMAN機能は、リカバリ・カタログを使用する場合にのみ機能します。たとえば、リカバリ・カタログにはRMANスクリプトを格納することができます。ストアド・スクリプトの主なメリットは、ターゲット・データベースおよびリカバリ・カタログに接続可能なRMANクライアントで使用できることです。コマンド・ファイルは、それらが格納されているファイル・システムにRMANクライアントがアクセスできる場合にのみ使用できます。

Data Guard環境でRMANを使用する場合は、リカバリ・カタログが必要です。すべてのプライマリ・データベースおよびスタンバイ・データベースのバックアップ・メタデータを格納すると、カタログによって、バックアップ・タスクを1つのスタンバイ・データベースにオフロードし、その環境内のその他のデータベースにバックアップをリストアできます。

13.1.2 RMANリカバリ・カタログの基本的な概念

リカバリ・カタログには、登録されている各ターゲット・データベースのRMAN操作に関するメタデータが含まれています。RMANは、リカバリ・カタログに接続されると、カタログから排他的にそのメタデータを取得します。

このカタログには、次のタイプのメタデータが含まれています。

  • データファイルとアーカイブREDOログのバックアップ・セットおよびバックアップ・ピース

  • データファイルのコピー

  • アーカイブREDOログおよびそのコピー

  • データベース構造(表領域およびデータファイル)

  • ストアド・スクリプト(ユーザーが作成した一連の名前付きRMANコマンド)

  • RMAN構成の永続設定

13.1.2.1 RMANリカバリ・カタログへのデータベースの登録について

RMANで使用するために、リカバリ・カタログにデータベースを記載するプロセスを登録と呼びます。

すべてのターゲット・データベースを環境内の単一のリカバリ・カタログに登録することをお薦めします。たとえば、データベースprod1、prod2およびprod3を、データベースcatdbのrcoが所有する1つのカタログに登録できます。

関連項目:

リカバリ・カタログへのデータベースの登録

13.1.2.2 ベースRMANリカバリ・カタログでのメタデータの集中化について

集中化されたリカバリ・カタログ(ベース・リカバリ・カタログとも呼ばれる)の所有者は、他のデータベース・ユーザーに対してカタログへの制限付きアクセス権限を付与および取り消すことができます。

制限付きユーザーは、それぞれ仮想プライベート・カタログと呼ばれる独自のメタデータへの完全な読取り/書込み権限を持っています。RMANメタデータは、仮想プライベート・カタログ所有者のスキーマに格納されます。ベース・リカバリ・カタログの所有者は、各仮想プライベート・カタログ・ユーザーがアクセスできるオブジェクトを決定します。

リカバリ・カタログは、様々なバージョンのOracle Databaseを使用している環境、または使用してきた環境で使用できます。その結果、様々なバージョンのRMANクライアント、リカバリ・カタログ・データベース、リカバリ・カタログ・スキーマおよびターゲット・データベースが環境内に存在する可能性があります。複数のリカバリ・カタログ・スキーマを1つにマージする方法については、「リカバリ・カタログのインポートおよび移動」を参照してください。

関連項目:

仮想プライベート・カタログの作成および管理

13.1.2.3 RMANリカバリ・カタログの再同期化について

バックアップ、リストア、クロスチェックなどのRMAN操作では、RMANによって常に最初に制御ファイルが更新され、次にメタデータがリカバリ・カタログに伝播されます。マウントされた制御ファイルからリカバリ・カタログへのメタデータのこのフローは、リカバリ・カタログの再同期化と呼ばれます。これによって、RMANが制御ファイルから取得するメタデータが現行のものになります。

関連項目:

リカバリ・カタログの再同期化

13.1.2.4 ストアド・スクリプト

ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRMANコマンドの管理に使用できます。このスクリプトは、ファイル・システムではなくリカバリ・カタログに格納されます。

ローカル・ストアド・スクリプトは、作成時にRMANが接続していたターゲット・データベースに関連付けられます。スクリプトは、関連付けられたターゲット・データベースに接続している場合にのみ実行できます。グローバル・ストアド・スクリプトは、リカバリ・カタログに登録されているすべてのデータベースに対して実行できます。仮想プライベート・カタログ・ユーザーは、グローバル・スクリプトへの読取り専用アクセス権限を持っています。グローバル・スクリプトの作成または更新は、ベース・リカバリ・カタログへの接続中に実行する必要があります。

関連項目:

ストアド・スクリプトの管理

13.1.2.5 Data Guard環境でのリカバリ・カタログ

Data Guard環境内のすべての物理データベース(プライマリ・データベースとスタンバイ・データベースの両方)のRMANメタデータを管理するには、リカバリ・カタログを使用する必要があります。RMANは、Data Guard環境の唯一の正しい情報源としてリカバリ・カタログを使用します。

RMANは、逆再同期化で、リカバリ・カタログを使用してプライマリまたはスタンバイ制御ファイルを更新できます。この場合、メタデータのフローの方向は、制御ファイルからカタログではなく、カタログから制御ファイルになります。RMANは、再同期化が必要なほぼすべての場合に、再同期化を自動的に実行します。そのため、RESYNCコマンドを使用して手動で再同期化する必要がある機会はあまり多くありません。

関連項目:

13.1.3 リカバリ・カタログの管理の基本ステップ

リカバリ・カタログの管理では、カタログを作成してから、そのカタログにターゲット・データベースを登録します。

リカバリ・カタログをRMANで使用できるように設定する基本ステップは次のとおりです。

  1. リカバリ・カタログを作成します。

    このタスクの実行方法については、「リカバリ・カタログの作成」を参照してください。

  2. リカバリ・カタログにターゲット・データベースを登録します。

    このステップによって、RMANはターゲット・データベースに関するメタデータをリカバリ・カタログに格納できます。このタスクについては、「リカバリ・カタログへのデータベースの登録」を参照してください。

  3. 必要に応じて、ターゲット制御ファイルに格納されていないレコードが含まれている古いバックアップをカタログに追加します。

    このタスクの実行方法については、「リカバリ・カタログへのバックアップの追加」を参照してください。

  4. 必要に応じて、特定のユーザー用の仮想プライベート・カタログを作成し、そのユーザーがアクセスできるメタデータを指定します。

    このタスクの実行方法については、「仮想プライベート・カタログの作成および管理」を参照してください。

  5. バックアップおよびリカバリ計画に含めることによって、リカバリ・カタログを保護します。

    カタログをバックアップおよびリカバリする方法および可用性を向上させる方法については、「リカバリ・カタログの保護」を参照してください。

関連項目:

13.2 リカバリ・カタログの作成

リカバリ・カタログの作成は、リカバリ・カタログ・データベースの構成、リカバリ・カタログのスキーマ所有者の作成、およびカタログの作成という複数のフェーズで構成されます。

リカバリ・カタログを作成する手順

  1. リカバリ・カタログ・データベースの構成の説明に従って、リカバリ・カタログを含むデータベースを構成します。

  2. リカバリ・カタログのスキーマ所有者の作成の説明に従って、リカバリ・カタログを所有するデータベース・ユーザーを作成します。

  3. CREATE CATALOGコマンドの実行の説明に従って、リカバリ・カタログを作成します。

13.2.1 リカバリ・カタログ・データベースの構成

RMANでリカバリ・カタログを使用する場合、リカバリ・カタログ・スキーマを保持する必要があります。リカバリ・カタログは、スキーマのデフォルト表領域に格納されます。SYSなどの権限付きユーザーをリカバリ・カタログ所有者にすることはできません。

リカバリ・カタログ・スキーマをインストールするために使用するデータベースおよびそのデータベースのバックアップ方法を決定します。また、カタログ・データベースをARCHIVELOGモード(推奨)で動作させるかどうかを決定します。

注意:

ターゲット・データベースを使用して、リカバリ・カタログのデータベースとしてバックアップしないでください。リカバリ・カタログは、ターゲット・データベースが消失した場合に保護される必要があります。

13.2.1.1 リカバリ・カタログ・スキーマのサイズの計画

カタログ・スキーマによって使用される領域を割り当てる必要があります。リカバリ・カタログ・スキーマのサイズは、カタログによって監視されるデータベースの数によって異なります。

スキーマは、アーカイブREDOログ・ファイルおよび各データベースのバックアップの増加とともに増大します。カタログに格納されているRMANストアド・スクリプトを使用する場合は、これらのスクリプトに対して領域を割り当てる必要があります。

たとえば、trgtデータベースにファイルが100個あり、このデータベースを1日に1回バックアップして、それぞれ1つのバックアップ・ピースを含む50個のバックアップ・セットを作成すると想定します。バックアップ・ピース表内の各行が領域を最大限に使用すると想定すると、1回の日次バックアップによってリカバリ・カタログ内で使用される領域は170KB未満です。この日次バックアップを1年間行うと、この期間中に使用される合計記憶域は約62MBです。これとほぼ同じ量の記憶域がアーカイブ・ログに使用されると想定されます。したがって、最悪の場合はメタデータの格納に1年間で約120MBが必要になります。バックアップ・ピースの行領域の一部のみを使用する通常の状況の場合、現実的な値は年間15MBです。

リカバリ・カタログに複数のデータベースの登録を予定している場合、前述の計算に従って各データベースに必要な領域を足し、リカバリ・カタログ・スキーマのデフォルト表領域の合計サイズを算出してください。

13.2.1.2 リカバリ・カタログ・データベースのディスク領域の割当て

リカバリ・カタログを既存のデータベース内に作成する場合、リカバリ・カタログ・スキーマ用のデフォルト表領域を保持できる十分な空き領域を追加します。

リカバリ・カタログを格納するための新しいデータベースを作成する場合、リカバリ・カタログ・スキーマ自体の領域に加えて、次に示すリカバリ・カタログ・データベース内の他のファイル用の領域も考慮します。

  • SYSTEM表領域およびSYSAUX表領域

  • 一時表領域

  • UNDO表領域

  • オンラインREDOログ・ファイル

リカバリ・カタログ・データベース内の領域の大部分は、SYSTEM表領域、一時表領域、UNDO表領域などの表領域をサポートするために使用されます。表13-1に、一般的な領域要件を示します。

表13-1 1年間での一般的なリカバリ・カタログ領域要件

領域タイプ 必要な領域

SYSTEM表領域

90 MB

一時表領域

5 MB

ロールバック表領域またはUNDO表領域

5 MB

リカバリ・カタログ表領域

リカバリ・カタログに登録されたデータベースごとに15MB

オンラインREDOログ

ログごとに1MB(3グループ、各グループに2メンバー)

注意:

リカバリ・カタログとターゲット・データベースが同じディスク上に存在していないことを確認してください。リカバリ・カタログとターゲット・データベースの両方にハード・ディスク障害が発生した場合、リカバリ・プロセスがより困難になります。可能な場合、他の手段を利用し、リカバリ・カタログ・データベースとバックアップ対象のデータベースの共通の致命的な障害箇所を排除してください。

13.2.2 リカバリ・カタログのスキーマ所有者の作成

リカバリ・カタログ・データベースを選択して必要な領域を作成した後、リカバリ・カタログの所有者を作成し、そのユーザーに必要な権限を付与します。

後続の項に示す手順では、次の状況を想定しています。

  • CATDBリカバリ・カタログ・データベース内のTOOLSという表領域にリカバリ・カタログが格納されています。RMANの予約語を表領域名として使用する場合、その語を引用符で囲み、大文字を使用する必要があります。

  • TEMPという表領域が、リカバリ・カタログ・データベース内に存在します。

リカバリ・カタログ・データベース内にリカバリ・カタログ・スキーマを作成する手順

  1. SQL*Plusを起動し、リカバリ・カタログを含むデータベースに管理者権限で接続します。この例では、データベースはcatdbです。
  2. リカバリ・カタログのユーザーおよびスキーマを作成します。たとえば、次のSQL文を入力できます(passwordはユーザー定義のパスワードに置き換えます)。
    CREATE USER rco IDENTIFIED BY password
  TEMPORARY TABLESPACE temp 
  DEFAULT TABLESPACE tools 
  QUOTA UNLIMITED ON tools;

    注意:

    安全なパスワードを作成してください。

  3. スキーマ所有者にRECOVERY_CATALOG_OWNERロールを付与します。このロールによって、リカバリ・カタログのメンテナンスおよび問合せに必要なすべての権限がユーザーに付与されます。
    GRANT RECOVERY_CATALOG_OWNER TO rco;
  4. (オプション) –vpdオプションを指定してdbmsrmanvpc.sqlスクリプトを実行して、リカバリ・カタログのVPDモデルを有効にします。
    次のコマンドは、ユーザーrcoが所有するリカバリ・カタログのVPDモデルを有効にします。
    SQL> @/$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco;

関連項目:

13.2.3 CREATE CATALOGコマンドの実行

カタログ所有者の作成後、RMANのCREATE CATALOGコマンドを使用してカタログ表を作成します。このコマンドを実行すると、カタログ所有者のデフォルト表領域内にカタログが作成されます。

リカバリ・カタログを作成する手順

注意:

Oracle Database 12cリリース1 (12.1.0.2)以降、リカバリ・カタログ・データベースではOracle DatabaseのEnterprise Editionを使用する必要があります。
  1. リカバリ・カタログ・データベースのOracleパーティション化を有効にします。
  2. RMANを起動し、カタログを格納するデータベースに接続します。データベースには、リカバリ・カタログ所有者として接続します。
  3. CREATE CATALOGコマンドを実行してカタログを作成します。カタログの作成には数分かかります。カタログ表領域がこのユーザーのデフォルト表領域の場合、次のコマンドを実行できます。
    RMAN> CREATE CATALOG;

    CREATE CATALOGコマンドでカタログの表領域名を指定できます。次に例を示します。 

    RMAN> CREATE CATALOG TABLESPACE cat_tbs;

    注意:

    リカバリ・カタログの表領域名がRMANの予約語である場合は、その予約語を大文字にして引用符で囲む必要があります。次に例を示します。 

    CREATE CATALOG TABLESPACE 'CATALOG';
  4. 結果を確認するには、SQL*Plusを使用し、リカバリ・カタログを問い合せて作成された表を表示します。
    SQL> SELECT TABLE_NAME FROM USER_TABLES;

関連項目:

13.3 リカバリ・カタログへのデータベースの登録

ターゲット・データベースをリカバリ・カタログに登録すると、データベースのレコードがリカバリ・カタログ内に維持されます。

13.3.1 リカバリ・カタログへのデータベースの登録

リカバリ・カタログにターゲット・データベースを記載するプロセスを登録と呼びます。

ターゲット・データベースがリカバリ・カタログに登録されていない場合、RMANは、カタログを使用して操作に関するメタデータをそのデータベースに格納できません。登録されていないデータベースでも、RMAN操作を実行することはできます。RMANは、そのメタデータを常にターゲット・データベースの制御ファイルに格納するためです。

Data Guard環境でリカバリ・カタログを使用していない場合は、REGISTERコマンドを使用して各データベースを登録します。各データベースには、一意のDBIDが必要です。RMANのDUPLICATEコマンドまたはSQLのCREATE DATABASE文を使用すると、データベースに一意のDBIDが自動的に割り当てられます。その他の方法でデータベースを作成すると、コピーされたデータベースのDBIDとソース・データベースのDBIDが同じになる場合があります。ソース・データベースとコピー・データベースを同じカタログに登録できるように、DBNEWIDユーティリティを使用してDBIDを変更できます。

UNREGISTERコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。

13.3.1.1 スタンバイ・データベースの登録

Data Guard環境では、プライマリ・データベースとスタンバイ・データベースは同じDBIDおよびデータベース名を共有します。Data Guard環境のデータベースをリカバリ・カタログに登録できるようにするには、各データベースに異なるDB_UNIQUE_NAME値が必要です。

データベースのDB_UNIQUE_NAMEパラメータは、その初期化パラメータ・ファイルに設定されています。Data Guard環境でRMANを使用する場合は、プライマリ・データベースに対してのみREGISTER DATABASEコマンドを使用できます。

次の方法を使用すると、スタンバイ・データベースをリカバリ・カタログに登録できます。

  • TARGETとしてスタンバイ・データベースに接続すると、RMANによってデータベースがリカバリ・カタログに自動的に登録されます。

  • リカバリ・カタログで認識されないスタンバイ・データベースに対してCONFIGURE DB_UNIQUE_NAMEコマンドを実行する場合、RMANは、対応するプライマリ・データベースが登録されていれば、このスタンバイ・データベースを自動的に登録します。

関連項目:

13.3.2 REGISTER DATABASEコマンドを使用したデータベースの登録

ターゲット・データベースでリカバリ・カタログを使用するには、まずそのターゲット・データベースをリカバリ・カタログに登録します。Data Guard環境でカタログを使用する場合は、この方法でプライマリ・データベースのみを登録できます。

次の手順を実行します。

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。リカバリ・カタログ・データベースはオープンされている必要があります。

    たとえば、ネット・サービス名catdbを使用してカタログ・データベースにユーザーrco(カタログ・スキーマ所有者)として接続するには、次のコマンドを発行します。 

    % rman TARGET / CATALOG rco@catdb;
  2. ターゲット・データベースをマウントしていない場合、マウントまたはオープンします。
    STARTUP MOUNT;
  3. 接続しているリカバリ・カタログに、ターゲット・データベースを登録します。
    REGISTER DATABASE;

    RMANは、カタログ表内に、ターゲット・データベースに関する情報を格納する行を作成し、ターゲット・データベースに関連するすべてのデータを制御ファイルからカタログにコピーし、カタログと制御ファイルを同期化します。

  4. REPORT SCHEMAを実行し、正常に登録されたことを確認します。
    REPORT SCHEMA;

Report of database schema for database with db_unique_name TRGT

List of Permanent Datafiles===========================
File Size(MB)   Tablespace       RB segs Datafile Name
---- ---------- ---------------- ------- -------------------
1        307200 SYSTEM             NO    /oracle/oradata/trgt/system01.dbf
2         20480 UNDOTBS            YES   /oracle/oradata/trgt/undotbs01.dbf
3         10240 CWMLITE            NO    /oracle/oradata/trgt/cwmlite01.dbf
4         10240 DRSYS              NO    /oracle/oradata/trgt/drsys01.dbf
5         10240 EXAMPLE            NO    /oracle/oradata/trgt/example01.dbf
6         10240 INDX               NO    /oracle/oradata/trgt/indx01.dbf
7         10240 TOOLS              NO    /oracle/oradata/trgt/tools01.dbf
8         10240 USERS              NO    /oracle/oradata/trgt/users01.dbf

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    200      TEMP                 32767       /oracle/oradata/trgt/tbs_tmp.dbf

13.4 リカバリ・カタログへのバックアップの追加

データファイルのコピー、バックアップ・ピースまたはアーカイブ・ログがディスクに存在する場合、CATALOGコマンドを使用して、それらをリカバリ・カタログに追加できます。リカバリ・カタログを使用する場合、制御ファイルからエージ・アウトされたバックアップをカタログに追加すると、リストア操作中に、その古いバックアップが使用されます。

次のコマンドは、この方法を示しています。

CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf', 
                   '/disk1/arch_logs/archive1_732.dbf';
CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';

また、CATALOG START WITHコマンドを使用して、1つのディレクトリ内の複数のバックアップ・ファイルをカタログに追加できます。次に例を示します。 

CATALOG START WITH '/disk1/backups/';

RMANによって、RMANリポジトリに追加されるファイルが表示され、それらのバックアップが追加される前に確認するように求められます。CATALOG START WITHで接頭辞を指定する場合は注意が必要です。RMANは、ディスク上で、指定された接頭辞が付いたすべてのパスのすべてのファイルをスキャンします。接頭辞は、通常のディレクトリ名ではありません。不適切な接頭辞を使用すると、不適切なファイル・セットがカタログに追加される場合があります。

たとえば、/disk1/backups、/disk1/backups-year2003、/disk1/backupsets、/disk1/backupsets/testなどの一連のディレクトリにバックアップ・ファイルが含まれているとします。次のコマンドを実行すると、これらのすべてのディレクトリ内のすべてのファイルがカタログに追加されます。/disk1/backupsが、これらのすべてのディレクトリへのパスの接頭辞であるためです。 

CATALOG START WITH '/disk1/backups';

/disk1/backupsディレクトリ内のバックアップのみをカタログに追加するには、次のコマンドが適切です。 

CATALOG START WITH '/disk1/backups/';

関連項目:

13.5 仮想プライベート・カタログの作成および管理

RMANには、仮想プライベート・カタログの作成および管理のために複数のコマンドが用意されています。

13.5.1 仮想プライベート・カタログの概要

デフォルトでは、RMANのリカバリ・カタログの全ユーザーは、カタログのすべてのメタデータを読取り、選択、挿入、更新および削除する完全な権限を持ちます。たとえば、2つの関連のないデータベースの管理者が同じリカバリ・カタログを共有している場合、各管理者は、誤ってまたは意図的に、もう一方の管理者のデータベース用のカタログ・データを破壊することができます。多くの企業では、同じ担当者が多くの異なるデータベースを管理し、そのリカバリ・カタログも管理するため、この状況が許容されています。ただし、その他の企業では、様々なデータベースの管理者の間、およびDBAとリカバリ・カタログの管理者の間に、明確な責務の分離が存在しており、このような企業では、各データベース管理者が、担当のデータベースに属するバックアップ・メタデータのみを変更するように制限すると同時に、単一の中央管理されたRMANリカバリ・カタログによるメリットも保つ必要がある場合があります。 この目的は、仮想プライベート・カタログを実装することによって達成できます。

Oracle Database 11g以降のすべてのRMANリカバリ・カタログは、仮想プライベート・カタログをサポートしていますが、仮想プライベート・カタログは、明示的に作成しないと使用されません。1つのリカバリ・カタログに対して作成できる仮想プライベート・カタログの数に、制限はありません。各仮想プライベート・カタログは、データベース・スキーマのユーザーによって所有されます。このユーザーは、リカバリ・カタログを所有するユーザーとは異なります。

仮想プライベート・カタログ・ユーザーを設定後、リカバリ・カタログの管理者は、各仮想プライベート・カタログに対して、リカバリ・カタログに現在登録されている1つ以上のデータベースにそのカタログを使用する権限を付与します。リカバリ・カタログの管理者は、仮想プライベート・カタログの使用中に新しいデータベースを登録する権限を付与することもできます。

注意:

各仮想プライベート・カタログは、すべてのグローバル・ストアド・スクリプト、および仮想プライベート・カタログが権限を持つデータベースに属する非グローバル・ストアド・スクリプトにアクセスできます。 仮想プライベート・カタログは、権限を持たないデータベースに属する非グローバル・ストアド・スクリプトにはアクセスできません。また、グローバル・ストアド・スクリプトを作成することはできません。

13.5.2 仮想プライベート・カタログ用のVPDモデルの使用について

RMANは、仮想プライベート・データベース(VPD)機能を使用して、仮想プライベート・カタログを実装します。

VPD機能は、RMANのベース・リカバリ・カタログ作成時には、デフォルトでは有効化されていません。ベース・カタログ・スキーマのアップグレード後に$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sqlスクリプトを実行して、ベース・リカバリ・カタログのVPDモデルを明示的に有効化する必要があります。

dbmsrmanvpc.sqlスクリプトの形式は次のとおりです。
$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql [[-vpd | -novpd | -scan ] base_catalog_schema_name[...]] | -all

RMANのベース・カタログ・スキーマ名は、dbmsrmanvpc.sqlを実行するときにコマンドライン・パラメータとして提供されます。スクリプトの1度の実行で、ベース・カタログ・スキーマ名を10件まで指定できます。

表13-2は、dbmsrmanvpc.sqlスクリプトを実行するときに使用できるオプションを説明しています。コマンドライン・オプションのいずれかを使用するか、カタログ・スキーマ名を指定する必要があります。

表13-2 dbmsrmanvpc.sqlのオプション

dbmsrmanvpc.sqlのオプション名 説明

-vpd

VPDで保護されたカタログをサポートするために必要な権限を付与します。

-novpd

ベース・リカバリ・カタログ・スキーマをクリーン・アップし、権限付与を取り消し、データベース・オブジェクトを削除して、VPD機能を無効化します。

このオプションは、ベース・リカバリ・カタログに登録されている既存のVPCユーザーがいない場合にのみ使用できます。

-scan

RMANベース・カタログの所有者スキーマのスキャンを実行し、VPCユーザーに付与されているロールとステータスをレポートします。

-all

RMANベース・カタログ・スキーマを自動的に検出してアップグレードします。

例13-1 VPCユーザー・スキーマのVPDモデルの有効化

SQL*Plusに接続して次のコマンドを使用して、RMANベース・カタログrman_catのすべての仮想プライベート・カタログのVPDモデルを有効にします。 

SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rman_cat

13.5.3 仮想プライベート・カタログの作成

仮想プライベート・カタログの作成は、複数のステップで構成されるプロセスです。最初に、仮想プライベート・カタログを所有するデータベース・ユーザーを作成し、次に仮想プライベート・カタログを作成します。

注意:

リカバリ・カタログが仮想プライベート・カタログの場合、これに接続しているRMANクライアントは、パッチ・レベル10.1.0.6または10.2.0.3である必要があります。Oracle9iのRMANクライアントは、仮想プライベート・カタログに接続できません。このバージョン制限は、Oracle Database 11gのベース・リカバリ・カタログへのRMANクライアント接続には影響しません。基本カタログに仮想プライベート・カタログのユーザーがいる場合も同様です。

データベースprod1、prod2およびprod3がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログを所有するデータベース・ユーザーはrcoです。データベース・ユーザーvpc1を作成し、このユーザーにprod1およびprod2のみへのアクセス権限を付与します。デフォルトでは、仮想プライベート・カタログ所有者にベース・リカバリ・カタログへのアクセス権限はありません。

仮想プライベート・カタログの作成前に、ベースRMANリカバリ・カタログを作成する必要があります。

仮想プライベート・カタログを作成する手順

  1. SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースに接続します。
  2. 仮想プライベート・カタログを所有するユーザーを作成します。

    たとえば、データベース・ユーザーvpc1に仮想プロバイダ・カタログを所有させる場合、次のコマンドを実行します(passwordをユーザー定義パスワードに置換します)。 

    SQL> CREATE USER vpc1 IDENTIFIED BY password
  2  DEFAULT TABLESPACE vpcusers
  3  QUOTA UNLIMITED ON vpcusers;

    注意:

    安全なパスワードを作成してください。詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。

  3. 仮想プライベート・カタログを所有するユーザーにCREATE SESSION権限を付与してから、SQL*Plusを終了します。

    次の例では、ユーザーvpc1に権限を付与します。 

    SQL> GRANT CREATE SESSION TO vpc1;
SQL> EXIT;
  4. RMANを起動し、(仮想プライベート・カタログ所有者ではなく)ベース・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。

    次の例では、rcoとしてベース・リカバリ・カタログに接続します。 

    % rman
RMAN> CONNECT CATALOG rco@catdb;

recovery catalog database Password: password
connected to recovery catalog database
  5. 仮想プライベート・カタログ所有者に目的の権限を付与します。

    次の例では、prod1およびprod2(prod3は対象外)に関するメタデータへのアクセス権限をユーザーvpc1に付与します。 

    RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1;
RMAN> GRANT CATALOG FOR DATABASE prod2 TO vpc1;

    データベース名ではなくDBIDを使用することもできます。仮想プライベート・カタログ・ユーザーには、リカバリ・カタログに登録されている他のデータベースに関するメタデータへのアクセス権限はありません。

    次の例では、PDBのhr_pdbのメタデータに対するアクセス権限をユーザーvpc1に付与します。 

    GRANT CATALOG FOR PLUGGABLE DATABASE hr_pdb TO vpc1;

    新しいターゲット・データベースをリカバリ・カタログに登録する機能をユーザーに付与することもできます。次に例を示します。

    RMAN> GRANT REGISTER DATABASE TO vpc1;

関連項目:

RMANのバージョン互換性の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.5.4 データベースの仮想プライベート・カタログへの登録

仮想プライベート・カタログ内のターゲット・データベース用にバックアップ・メタデータを保存するには、データベースを仮想プライベート・カタログに登録する必要があります。

仮想プライベート・カタログを作成してから、ターゲット・データベースを登録します。

データベースを仮想プライベート・カタログに登録してバックアップ・メタデータを格納する手順

  1. RMANを起動し、(ベース・リカバリ・カタログ所有者ではなく)仮想プライベート・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。TARGETとして登録するデータベースに接続します。
    %rman
RMAN> CONNECT TARGET /
RMAN> CONNECT CATALOG vpc1@catdb;
  2. 仮想プライベート・カタログにメタデータを格納する必要のあるデータベースを登録します。

    次の例では、データベースを仮想プライベート・カタログ所有者vpc1に登録します。 

    RMAN> REGISTER DATABASE;
  3. BACKUPコマンドに必要な句を指定してデータベースをバックアップします。

    バックアップに関連するメタデータが、仮想プライベート・カタログに格納されます。

13.5.5 仮想プライベート・カタログ所有者からの権限の取消し

仮想プライベート・カタログの作成後に、必要に応じてカタログ・アクセス権限を取り消すことができます。

2つのデータベースprod1およびprod2がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログの所有者として、vpc1ユーザーにprod1へのアクセス権限を付与しています。また、このユーザーには、仮想プライベート・カタログにデータベースを登録する権限も付与しています。ここで、vpc1から権限を取り消します。

仮想プライベート・カタログ所有者から権限を取り消す手順

  1. RMANを起動し、(仮想プライベート・カタログ所有者ではなく)リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。

    次の例では、rcoとしてリカバリ・カタログに接続します。 

    % rman
RMAN> CONNECT CATALOG rco@catdb;
  2. 指定した権限を仮想プライベート・カタログ所有者から取り消します。

    次のコマンドによって、prod1に関するメタデータへのアクセス権限が仮想プライベート・カタログ所有者vpc1から取り消されます。 

    REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;

    データベース名ではなくDBIDを指定することもできます。カタログvpc1は、付与されているその他のすべてのカタログ権限を保持します。

    次のコマンドによって、PDBのhr_pdbに関するメタデータへのアクセス権限が仮想プライベート・カタログ所有者vpc1から取り消されます。 

    REVOKE CATALOG FOR PLUGGABLE DATABASE hr_pdb FROM vpc1;

    新しいターゲット・データベースをリカバリ・カタログに登録する権限を取り消すこともできます。次に例を示します。

    REVOKE REGISTER DATABASE FROM vpc1;

13.5.6 仮想プライベート・カタログのアップグレード

この項では、UPGRADE CATALOGコマンドを使用して仮想プライベート・カタログをアップグレードする方法について説明します。

RMANは、仮想プライベート・データベース(VPD)機能を使用して、仮想プライベート・カタログを実装します。Oracle Database 12cリリース1 (12.1.0.2)より前のバージョンを使用してリカバリ・カタログおよび仮想プライベート・カタログを作成した場合、またはデータベースがOracle Database 12cリリース2 (12.2)以上にアップグレードされていない場合は、これらの仮想プライベート・カタログをアップグレードする必要があります。RMANでは、仮想プライベート・カタログをアップグレードするためのスクリプトが$ORACLE_HOME/rdbms/adminディレクトリに用意されています。

仮想プライベート・カタログをアップグレードする手順

  1. SQL*Plusを使用し、SYSDBA権限を持つSYSユーザーとしてリカバリ・カタログ・データベースに接続します。
  2. dbmsrmansys.sqlスクリプトを実行して、RECOVERY_CATALOG_OWNERロールに必要なその他の権限を付与します。
    SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql
  3. dbmsmanvpc.sqlスクリプトを実行して、仮想プライベート・カタログ・スキーマをVPDモデルにアップグレードします。

    ベース・リカバリ・カタログ・スキーマ名を、このスクリプトの入力パラメータとして指定する必要があります。最大10個のスキーマ名を指定できます。-allオプションを使用して、ベース・リカバリ・カタログを自動的に検出し、関連する仮想プライベート・カタログ・スキーマをすべてアップグレードすることもできます。

    次のコマンドでは、rcoが所有するベース・リカバリ・カタログの仮想プライベート・カタログ・スキーマをアップグレードします。 

    SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco
  4. RMANをベース・リカバリ・カタログに接続し、ベース・リカバリ・カタログをアップグレードしてからRMANを終了します。

    ベース・リカバリ・カタログを所有するデータベース・ユーザーがrcoであるとします。次のコマンドでは、ベース・リカバリ・カタログをアップグレードします。アップグレードを確定するため、UPGRADE CATALOGコマンドは2回入力する必要があります。 

    $ rman CATALOG rco@catdb
recovery catalog database password: 
RMAN> UPGRADE CATALOG;
RMAN> UPGRADE CATALOG;
RMAN> EXIT;

関連項目:

dbmsrmanvpc.sqlスクリプトとそのオプションの詳細は、仮想プライベート・カタログ用のVPDモデルの使用についてを参照してください。

13.6 リカバリ・カタログの保護

バックアップおよびリカバリ計画には、リカバリ・カタログ・データベースも含める必要があります。リカバリ・カタログをバックアップしないと、ディスク障害が発生してリカバリ・カタログ・データベースが破損した場合、カタログ内のメタデータが消失する場合があります。リカバリ・カタログの内容がない場合は、その他のデータベースのリカバリがより困難になる可能性があります。

13.6.1 リカバリ・カタログのバックアップ

1つのリカバリ・カタログには、複数のターゲット・データベースに関するメタデータを格納できます。したがって、リカバリ・カタログが消失すると、重大な問題が発生する可能性があります。リカバリ・カタログは、頻繁にバックアップしてください。

この項では、リカバリ・カタログを保護する計画を作成するための一般的なガイドラインについて説明します。

13.6.1.1 リカバリ・カタログの頻繁なバックアップ

リカバリ・カタログ・データベースは他のデータベースと同様のデータベースであり、バックアップおよびリカバリ計画に含める必要があります。リカバリ・カタログは、データベースの他の部分と同様にバックアップして保護してください。リカバリ・カタログ・データベースのバックアップは、全体的なバックアップおよびリカバリの一環として計画します。

リカバリ・カタログのバックアップは、ターゲット・データベースのバックアップと同じ頻度で行います。たとえば、ターゲット・データベース全体のバックアップを週1回行う場合、ターゲット・データベースのバックアップ後にリカバリ・カタログをバックアップします。リカバリ・カタログのこのバックアップは、障害リカバリに役立ちます。制御ファイルの自動バックアップを使用してリカバリ・カタログ・データベースをリストアする必要がある場合も、リストアしたリカバリ・カタログ・データベース内の完全なバックアップ・レコードを使用すると、ターゲット・データベースをリストアできます。

13.6.1.2 適切な物理バックアップ方法の選択

リカバリ・カタログ・データベースのバックアップは、RMANを使用して実行できます。

図13-1に示すように、RMANのリポジトリがカタログ・データベースの制御ファイルになるように、NOCATALOGオプションを指定してRMANを起動します。

図13-1 リカバリ・カタログのバックアップのリポジトリとしての制御ファイルの使用

図13-1の説明が続きます
「図13-1 リカバリ・カタログのバックアップのリポジトリとしての制御ファイルの使用」の説明

RMANを使用したリカバリ・カタログ・データベースのバックアップを計画する場合、次のガイドラインに従います。

  • 必要に応じてPoint-in-Timeリカバリを実行できるように、リカバリ・カタログ・データベースをARCHIVELOGモードで実行します。

  • 保存方針として、REDUNDANCY値を1より大きい値に設定します。

  • データベースを2つの異なるメディア(ディスクとテープなど)にバックアップします。

  • BACKUP DATABASE PLUS ARCHIVELOGを、使用可能な場合はメディア・マネージャに、メディア・マネージャが使用不可の場合はディスクのみに定期的に実行します。

  • 別のリカバリ・カタログをバックアップのリポジトリに使用しないでください。

  • 制御ファイルの自動バックアップ機能をONに設定します。

この方法では、制御ファイルの自動バックアップ機能によって、この機能が使用可能なかぎり確実にリカバリ・カタログ・データベースがリカバリされます。

関連項目:

制御ファイルの自動バックアップを使用したリカバリの詳細は、障害リカバリの実行を参照してください。

13.6.1.3 ターゲット・データベースからのリカバリ・カタログの分離

リカバリ・カタログは、そのカタログが保護するデータとは別の場所に格納されている場合にのみ有効です。そのため、データベースのRMANリポジトリを含むリカバリ・カタログは、ターゲット・データベースと同じデータベースには格納しないでください。また、カタログ・データベースはターゲット・データベースと同じディスクに格納しないでください。

データの分離をお薦めする理由を説明するために、データベースprod1のカタログをprod1に格納したとします。prod1にメディア全体の障害が発生したときに、prod1のリカバリ・カタログもprod1に格納されていた場合、データベースが消失すると、リカバリ・カタログも同様に消失します。この場合の対応策は1つのみです。リカバリ・カタログに格納されている情報を使用せずに、prod1の制御ファイルの自動バックアップをリストアして使用して、データベースのリストアおよびリカバリを実行する必要があります。

13.6.1.4 論理バックアップ用のリカバリ・カタログ・データのエクスポート

データ・ポンプ・エクスポート・ユーティリティを使用してRMANリカバリ・カタログの論理バックアップを作成しておくと、物理バックアップの有効な補助バックアップとなります。

リカバリ・カタログ・データベースが破損した場合、データ・ポンプ・インポートを使用して、エクスポートされたリカバリ・カタログ・データを別のデータベースに再インポートすることで、カタログを迅速に再構築できます。

13.6.2 リカバリ・カタログのリカバリ

リカバリ・カタログ・データベースのリストアおよびリカバリは、RMANを使用して他のデータベースをリストアおよびリカバリする場合とほぼ同様です。

リカバリ・カタログ・データベースの制御ファイルおよびサーバー・パラメータ・ファイルを自動バックアップからリストアし、その後、データベースの残りの部分のリストアおよび完全リカバリを実行できます。複数のリカバリ・カタログを使用している場合、別のリカバリ・カタログを使用して、このリカバリ・カタログ・データベースのバックアップに関するメタデータを記録することもできます。

通常のOracleのリカバリ手順によるリカバリ・カタログ・データベースのリカバリが実行不可能である場合は、カタログを再作成する必要があります。最悪の場合の例を次に示します。

  • リカバリ・カタログ・データベースを一度もバックアップしていない。

  • リカバリ・カタログ・データベースをバックアップしているが、データファイルのバックアップまたはアーカイブ・ログが使用不可であるためリカバリできない。

欠落しているリカバリ・カタログの内容を部分的に再作成するには、次の方法があります。

  • RESYNC CATALOGコマンドを使用して、ターゲット・データベースの制御ファイルまたは制御ファイルのコピーからのRMANリポジトリ情報でリカバリ・カタログを更新します。制御ファイルからエージ・アウトされた制御ファイル・レコードに含まれているメタデータは消失します。

  • CATALOG START WITHコマンドを発行して、使用可能なバックアップをカタログに再度追加します。

この最悪の状況が発生する可能性を最小限に抑えるには、バックアップ計画に少なくともリカバリ・カタログのバックアップを含める必要があります。この方法については、「リカバリ・カタログのバックアップ」を参照してください。

関連項目:

13.7 ストアド・スクリプトの管理

スクリプトを作成してリカバリ・カタログに格納できます。

関連項目:

ストアド・スクリプト

13.7.1 ストアド・スクリプト

ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRMANコマンドの管理に使用できます。このスクリプトは、ファイル・システムではなくリカバリ・カタログに格納されます。

ストアド・スクリプトには、ローカルとグローバルの2種類があります。ローカル・スクリプトは、作成時にRMANが接続していたターゲット・データベースに関連付けられます。このスクリプトは、関連付けられたターゲット・データベースに接続している場合にのみ実行できます。グローバル・ストアド・スクリプトは、RMANクライアントがリカバリ・カタログおよびターゲット・データベースに接続している場合、リカバリ・カタログに登録されたすべてのデータベースに対して実行できます。

CREATE SCRIPTコマンドの大カッコ内で使用できるコマンドは、RUNブロック内でサポートされているコマンドと同じです。RUNコマンド内で有効なコマンドは、ストアド・スクリプトで使用できます。RUN、@および@@コマンドは、ストアド・スクリプト内で有効ではありません。

スクリプト名を指定する場合、ストアド・スクリプト名を引用符で囲むことはできますが、必須ではありません。ただし、名前が数値で始まる場合やRMANの予約語である場合、その名前をストアド・スクリプト名として使用するには、引用符で囲む必要があります。ストアド・スクリプトには、英字以外の文字で始まる名前、またはRMANの予約語と同じ名前を付けないことをお薦めします。

グローバル・ストアド・スクリプトとローカル・ストアド・スクリプトが混同されないように、ネーミング規則を使用することをお薦めします。EXECUTE SCRIPT、DELETE SCRIPTおよびPRINT SCRIPTコマンドで引数として渡されたスクリプト名が、接続しているターゲット・インスタンス用に定義されたスクリプトの名前ではない場合、RMANは、指定した名前が付いたグローバル・スクリプトを検索します。たとえば、リカバリ・カタログにglobal_backupという名前のグローバル・スクリプトが存在し、ターゲット・データベース用に定義されたglobal_backupというローカル・ストアド・スクリプトが存在しない場合に次のコマンドを実行すると、このグローバル・スクリプトは削除されます。 

DELETE SCRIPT global_backup;

ストアド・スクリプト(グローバル・スクリプトの場合も)に関連するコマンドを使用するには、リカバリ・カタログとターゲット・データベース・インスタンスの両方に接続する必要があります。

13.7.2 ストアド・スクリプトの作成

CREATE SCRIPTコマンドを使用すると、ストアド・スクリプトを作成できます。

GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在していない必要があります。GLOBALを指定しない場合は、同じターゲット・データベースに対して同じ名前のローカル・スクリプトが存在していない必要があります。また、 REPLACE SCRIPTを使用すると、新しいスクリプトの作成または既存のスクリプトの更新を行うこともできます。

ストアド・スクリプトを作成する手順

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. CREATE SCRIPTコマンドを実行します。

    次に、ローカル・スクリプトを作成する例を示します。

    CREATE SCRIPT full_backup 
{     
  BACKUP DATABASE PLUS ARCHIVELOG;
  DELETE OBSOLETE;
}

    グローバル・スクリプトの場合、次のとおり、同様の構文を実行します。

    CREATE GLOBAL SCRIPT global_full_backup 
{     
  BACKUP DATABASE PLUS ARCHIVELOG;
  DELETE OBSOLETE;
}

    必要に応じて、COMMENTを使用して説明を追加できます。 

    CREATE GLOBAL SCRIPT global_full_backup 
COMMENT 'use only with ARCHIVELOG mode databases'
{     
  BACKUP DATABASE PLUS ARCHIVELOG;
  DELETE OBSOLETE;
}

    テキスト・ファイルから内容を読み取ってスクリプトを作成することもできます。このファイルは、左中カッコ({)で始まり、次に有効な一連のコマンドが含まれているRUNブロックを含み、最後に右中カッコ(})で終わる必要があります。そうでない場合、キーボードからコマンドを入力した場合と同様の構文エラーが発生します。 

    CREATE SCRIPT full_backup 
  FROM FILE '/tmp/my_script_file.txt';
  3. 出力を確認します。

    エラーが表示されていない場合、RMANは、スクリプトを正常に作成し、リカバリ・カタログに格納しています。

関連項目:

RMANの予約語のリストは、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.7.3 ストアド・スクリプトの置換え

ストアド・スクリプトを更新するには、REPLACE SCRIPTコマンドを使用します。

ローカル・スクリプトを置き換える場合は、スクリプトの作成時に接続していたターゲット・データベースに接続する必要があります。スクリプトが存在しない場合、RMANによってスクリプトが作成されます。

ストアド・スクリプトを置き換える手順

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. REPLACE SCRIPTを実行します。

    次の例では、スクリプトfull_backupを新しい内容で更新します。 

    REPLACE SCRIPT full_backup 
{
  BACKUP DATABASE PLUS ARCHIVELOG;
}

    GLOBALキーワードを次のように指定することによって、グローバル・スクリプトを更新できます。 

    REPLACE GLOBAL SCRIPT global_full_backup 
COMMENT 'A script for full backup to be used with any database'
{
  BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
}

    CREATE SCRIPTと同様に、ローカルまたはグローバル・ストアド・スクリプトをテキスト・ファイルから更新できます。その場合、次の形式のコマンドを使用します。 

    REPLACE GLOBAL SCRIPT global_full_backup 
  FROM FILE '/tmp/my_script_file.txt';

関連項目:

REPLACE SCRIPTコマンドの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.7.4 ストアド・スクリプトの実行

ストアド・スクリプトを実行するには、EXECUTE SCRIPTコマンドを使用します。

GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在している必要があります。存在していない場合、RMANはエラーRMAN-06004を戻します。 GLOBALを指定しなかった場合は、RMANによって、現行のターゲット・データベースに対して定義されているローカル・ストアド・スクリプトが検索されます。その名前のローカル・スクリプトが見つからなかった場合は、同じ名前のグローバル・スクリプトが検索され、見つかった場合はそのスクリプトが実行されます。

ストアド・スクリプトを実行する手順

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
  2. 必要に応じて、SHOWを使用して構成済のチャネルを確認します。

    スクリプトは、実行時に構成されていた自動チャネルを使用します。構成済のチャネルを変更する必要がある場合、スクリプトにALLOCATE CHANNELを指定します。RUNブロックが使用されているため、スクリプト内のあるRMANコマンドが正常に実行されなかった場合、スクリプト内の後続のRMANコマンドは実行されません。

  3. EXECUTE SCRIPTを実行します。このコマンドにはRUNブロックが必要です。次に例を示します。
    RUN 
{ 
  EXECUTE SCRIPT full_backup; 
}

    このコマンドによって、指定した名前が付いたローカル・スクリプトがある場合は、ローカル・スクリプトが起動されます。該当するローカル・スクリプトが存在しないが、指定した名前が付いたグローバル・スクリプトが存在する場合、RMANはそのグローバル・スクリプトを実行します。

    EXECUTE GLOBAL SCRIPTを使用して、ローカル・スクリプトとグローバル・スクリプトの名前が同じである場合に起動するスクリプトを制御することもできます。global_full_backupというローカル・スクリプトが存在しない場合、次の2つのコマンドによって実行される操作は同じになります。 

    RUN 
{
  EXECUTE GLOBAL SCRIPT global_full_backup;
}

RUN
{ 
  EXECUTE SCRIPT global_full_backup; 
}

関連項目:

EXECUTE SCRIPTコマンドの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.7.5 動的ストアド・スクリプトの作成および実行

CREATE SCRIPTコマンドでは置換変数を指定できます。

コマンドラインでRMANを起動する場合、USING句によって、コマンド・ファイル内の置換変数で使用される1つ以上の値が指定されます。SQL*Plusの場合と同様に、&1は最初の値を配置する場所を示し、&2は2番目の値を配置する場所を示します。それ以降も同様です。

動的ストアド・スクリプトを作成および使用する手順

  1. 動的に更新する必要がある値用の置換変数が指定されているCREATE SCRIPT文を含むコマンド・ファイルを作成します。

    次の例では、テープ・セットの名前、FORMAT指定内の文字列およびリストア・ポイントの名前の置換変数が使用されています。 

    CREATE SCRIPT quarterly { 
  ALLOCATE CHANNEL c1
    DEVICE TYPE sbt
    PARMS 'ENV=(OB_MEDIA_FAMILY=&1)';
  BACKUP
    TAG &2
    FORMAT '/disk2/bck/&1%U.bck'
    KEEP FOREVER
    RESTORE POINT &3
    DATABASE;
}
  2. RMANをターゲット・データベース(マウントまたはオープンされている必要があります)およびリカバリ・カタログに接続して、リカバリ・カタログ・スクリプトの初期値を指定します。

    たとえば、次のコマンドを入力します。

    % rman TARGET / CATALOG rco@catdb USING arc_backup bck0906 FY06Q3

    リカバリ・カタログは、KEEP FOREVERには必要ですが、その他のKEEPオプションには必要ありません。

  3. 最初のステップで作成したコマンド・ファイルを実行して、ストアド・スクリプトを作成します。

    たとえば、/tmp/catscript.rmanコマンド・ファイルを次のように実行します。 

    RMAN> @/tmp/catscript.rman

    このステップでは、ストアド・スクリプトは作成はされますが、実行はされません。

  4. 四半期ごとに、ストアド・スクリプトを実行して、置換変数の値を渡します。

    次の例では、quarterlyというリカバリ・カタログ・スクリプトを実行します。この例では、メディア・ファミリ(テープのセット)の名前としてarc_backup、FORMAT文字列の一部としてbck1206、リストア・ポイントの名前としてFY06Q4を指定します。 

    RUN
{ 
  EXECUTE SCRIPT quarterly 
    USING arc_backup
          bck1206
          FY06Q4;
}

関連項目:

長期格納用のデータベース・バックアップの作成

13.7.6 ストアド・スクリプトの出力

ストアド・スクリプトを表示またはファイルに出力するには、PRINT SCRIPTコマンドを使用します。

ストアド・スクリプトを出力する手順

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
  2. PRINT SCRIPTコマンドを次のように実行します。
    PRINT SCRIPT full_backup;

    スクリプトの内容をファイルに送信するには、次の形式のコマンドを使用します。

    PRINT SCRIPT full_backup 
  TO FILE '/tmp/my_script_file.txt';

    グローバル・スクリプトの場合、次の構文では同じ操作が実行されます。

    PRINT GLOBAL SCRIPT global_full_backup;
PRINT GLOBAL SCRIPT global_full_backup 
  TO FILE '/tmp/my_script_file.txt';

関連項目:

PRINT SCRIPTコマンドの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.7.7 ストアド・スクリプト名の表示

リカバリ・カタログに定義されたスクリプトの名前を表示するには、LIST ... SCRIPT NAMESコマンドを使用します。

RMANがターゲット・インスタンスに接続せずにリカバリ・カタログに接続している場合に使用できるコマンドは、LIST GLOBAL SCRIPT NAMESおよびLIST ALL SCRIPT NAMESのみです。その他の形式のLIST ... SCRIPT NAMESコマンドでは、リカバリ・カタログ接続が必要です。

ストアド・スクリプト名を表示する手順

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
  2. LIST ... SCRIPT NAMESコマンドを実行します。

    たとえば、現在接続しているターゲット・データベースに対して実行可能なすべてのグローバル・スクリプトおよびローカル・スクリプトの名前を表示するには、次のコマンドを実行します。

    LIST SCRIPT NAMES;

    次の例では、グローバル・スクリプトの名前のみを表示します。 

    LIST GLOBAL SCRIPT NAMES;

    現行のリカバリ・カタログに格納されたすべてのスクリプト(リカバリ・カタログに登録されたすべてのターゲット・データベースのグローバル・スクリプトとローカル・スクリプトを含む)の名前を表示するには、次の形式のコマンドを使用します。

    LIST ALL SCRIPT NAMES;

    表示された各スクリプトに関して、出力では、定義されたターゲット・データベース(または各スクリプトがグローバルであるかどうか)が示されます。

関連項目:

LIST SCRIPT NAMESコマンドの構文および出力形式については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.7.8 ストアド・スクリプトの削除

リカバリ・カタログからストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPTコマンドを使用します。

ストアド・スクリプトを削除する手順

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
  2. DELETE SCRIPTコマンドを入力します。

    GLOBALを指定せずにDELETE SCRIPTを使用し、指定した名前のストアド・スクリプトがそのターゲット・データベースに存在しない場合、指定した名前が付いたグローバル・ストアド・スクリプトが検索され、該当するスクリプトが削除されます。たとえば、次のコマンドを入力するとします。 

    DELETE SCRIPT 'global_full_backup';

    この場合、RMANは、接続したターゲット・データベース用に定義されたglobal_full_backupスクリプトを検索します。該当するスクリプトが検出されない場合、グローバル・スクリプト内でglobal_full_backupという名前のスクリプトを検索し、該当するスクリプトを削除します。

    グローバル・ストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPTを使用します。 

    DELETE GLOBAL SCRIPT 'global_full_backup';

関連項目:

DELETE SCRIPTコマンドの構文については、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.7.9 RMANの起動時のストアド・スクリプトの実行

RMANクライアントの起動時にリカバリ・カタログ内のストアド・スクリプトを実行するには、RMANクライアントの起動時にSCRIPT引数を指定します。

たとえば、次のコマンドを入力してスクリプト/tmp/fbkp.cmdを実行できます。 

% rman TARGET / CATALOG rco@catdb SCRIPT '/tmp/fbkp.cmd';

RMANクライアントの起動時には、(ストアド・スクリプトを含む)リカバリ・カタログおよび(スクリプトの実行先の)ターゲット・データベースに接続する必要があります。

ローカル・スクリプトとグローバル・ストアド・スクリプトが同じ名前で定義されている場合、RMANは常にローカル・スクリプトを実行します。

関連項目:

RMANクライアントのコマンドライン構文の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.8 リカバリ・カタログのメンテナンス

リカバリ・カタログのメンテナンスは、リカバリ・カタログの再同期化、更新およびアップグレードなどのタスクで構成されます。

この項では、様々な管理タスクおよびメンテナンス・タスクについて説明します。

13.8.1 リカバリ・カタログのメンテナンス

リカバリ・カタログを作成してターゲット・データベースを登録した後、このカタログをメンテナンスする必要があります。

たとえば、RMANメンテナンス・コマンド(RMANバックアップおよびリポジトリ・レコードのメンテナンスを参照)を実行して、バックアップ・レコードの更新および不要なバックアップの削除を行う必要があります。このタイプのメンテナンスは、リカバリ・カタログでRMANを使用するかどうかに関係なく実行する必要があります。リカバリ・カタログ・スキーマの更新などのその他のタイプのメンテナンスは、リカバリ・カタログでのRMANの使用に固有です。

Data Guard環境でリカバリ・カタログを使用する場合は、カタログに記録されるバックアップおよびデータベース・ファイルに、特別な考慮事項が適用されます。RMANでバックアップにアクセスできるタイミング、およびアクセス可能なバックアップに対するRMANメンテナンス・コマンドの動作については、「Data Guard環境でのRMANによるファイル管理について」を参照してください。

13.8.2 リカバリ・カタログの再同期化

RMANは、再同期化を実行する際に、リカバリ・カタログと、ターゲット・データベースの現行の制御ファイルまたはバックアップ制御ファイルを比較し、欠落したメタデータまたは変更されたメタデータを追加してカタログを更新します。

ほとんどのRMANコマンドは、ターゲット制御ファイルがマウントされ、カタログが使用可能になると、再同期化を自動的に実行します。Data Guard環境では、RMANは逆再同期化を実行して、カタログのメタデータでデータベース制御ファイルを更新できます。

13.8.2.1 リカバリ・カタログの再同期化

リカバリ・カタログを再同期化すると、RMANが制御ファイルから取得するメタデータが常に最新に保たれます。再同期化には、完全再同期化と部分再同期化があります。

部分再同期化では、RMANはターゲット・データベースの現行の制御ファイルを読み取って、新しいバックアップ、新しいアーカイブREDOログなどに関する変更されたメタデータを更新します。RMANは、データベースの物理スキーマに関するメタデータは再同期化しません。

完全再同期化では、RMANは、データベース・スキーマのレコードを含め、変更されたすべてのレコードを更新します。RMANは、データベースに構造変更(データベース・ファイルの追加または削除、新しいインカネーションの作成など)を行った後またはRMANの永続的な構成を変更した後に完全再同期化を実行します。

RMANは、完全再同期化の実行時に、一時的なバックアップ制御ファイルであるスナップショット制御ファイルを作成します。データベースでは、あるスナップショット制御ファイルにアクセスするRMANセッションが一度に1つのみに制限されます。RMANは、ターゲット・データベース・ホスト上のオペレーティング・システム固有の場所にスナップショット制御ファイルを作成します。スナップショット制御ファイルの名前および場所は、「スナップショット制御ファイルの場所の構成」の説明に従って指定できます。

このスナップショット制御ファイルによって、RMANは制御ファイルの一貫性ビューを持つことができます。制御ファイルは短期の使用を目的としているため、カタログには登録されません。RMANは、制御ファイルのチェックポイントをリカバリ・カタログに記録して、そのカタログが記録された時点を示します。

関連項目:

RESYNCコマンドの詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.8.2.1.1 Data Guard環境でのRMANリカバリ・カタログの再同期化について

RMANは、データベースにTARGETとして接続すると、リカバリ・カタログをそのデータベースとのみ自動的に再同期化します。つまり、RMANは、Data Guard環境内の1つのデータベースにTARGETとして接続しても、Data Guard環境内のすべてのデータベースは自動的に再同期化しません。

RESYNC CATALOG FROM DB_UNIQUE_NAMEコマンドを使用すると、リカバリ・カタログをData Guard環境内のデータベースと手動で再同期化できます。

手動での再同期化の例では、RMANが本番データベースprodにTARGETとして接続していること、およびCONFIGUREを使用してdgprod3用の構成を作成していることを想定しています。RESYNC CATALOG FROM DB_UNIQUE_NAME dgprod3を実行すると、RMANは、リカバリ・カタログをdgprod3制御ファイルと再同期化します。この場合、RMANは、通常の再同期化(メタデータのフローがdgprod3制御ファイルからカタログの方向)と逆再同期化の両方が実行されます。逆再同期化では、RMANは、リカバリ・カタログの永続的な構成を使用して、dgprod3制御ファイルを更新します。

関連項目:

『Oracle Data Guard概要および管理』

13.8.2.2 リカバリ・カタログを再同期化するタイミングの決定

RMANがターゲット・データベースおよびリカバリ・カタログに接続しているときにRMANコマンドを実行すると、RMANは自動的にリカバリ・カタログを再同期化します。

そのため、RESYNC CATALOGコマンドを手動で実行する必要がある機会はあまり多くありません。次の項では、カタログの再同期化を手動で実行する必要がある場合について説明します。

13.8.2.2.1 リカバリ・カタログが使用不可の場合の再同期化

部分再同期化を実行するRMANコマンドの発行時にリカバリ・カタログが使用不可であった場合、後でカタログ・データベースをオープンして、RESYNC CATALOGコマンドを使用して手動で再同期化します。

たとえば、ターゲット・データベースがニューヨークに存在し、リカバリ・カタログが日本に存在するとします。地理的に離れたデータベースの可用性に依存しないようにするため、CATALOGモードのターゲット・データベースの日次バックアップは行わないことにします。このような場合、実行可能な頻度でカタログに接続し、RESYNC CATALOGコマンドを実行します。

13.8.2.2.2 バックアップ頻度が低い場合のARCHIVELOGモードでの再同期化

ターゲット・データベースがARCHIVELOGモードで実行されていると想定します。また、次の操作を実行すると想定します。

  • データベースを低い頻度でバックアップします(たとえば、REDOログが100個アーカイブされるごとにデータベースをアーカイブします)。

  • 毎日多数のログ・スイッチが発生します(たとえば、スイッチが1000回発生するごとにカタログを再同期化します)。

この場合、REDOログ・スイッチの発生時またはREDOログのアーカイブ時にリカバリ・カタログが自動的に更新されないため、リカバリ・カタログを定期的に手動で再同期化する必要があります。データベースでは、REDOログ・スイッチおよびアーカイブREDOログに関するメタデータは制御ファイルにのみ格納されます。定期的に再同期化を実行して、この情報をリカバリ・カタログに伝播する必要があります。

リカバリ・カタログの再同期化の頻度は、データベースがREDOログをアーカイブする頻度によって異なります。 この操作のコストは、制御ファイル内の、最後の再同期化以降に挿入または変更されたレコードの数に比例します。挿入または変更されたレコードがない場合、再同期化のコストは非常に低くなります。多くのレコードが挿入または変更された場合、再同期化にかかる時間が長くなります。

13.8.2.2.3 スタンバイ・データベースの構成後の再同期化

スタンバイ・データベースにTARGETとして接続されていない場合でも、このデータベースに対してRMAN構成の作成または変更を行うことができます。

このタスクは、CONFIGURE DB_UNIQUE_NAMEまたはCONFIGURE ... FOR DB_UNIQUE_NAMEコマンドを使用して実行します。「リカバリ・カタログの手動での再同期化」で説明されているように、スタンバイ・データベースを手動で再同期化して、スタンバイ・データベースの制御ファイルを更新できます。

13.8.2.2.4 制御ファイル・レコードがエージ・アウトされる前のリカバリ・カタログの再同期化

リカバリ・カタログ内のメタデータは、常に最新の状態にしておく必要があります。リカバリ・カタログはターゲット制御ファイルからメタデータを取得するため、カタログ内のデータが最新の状態かどうかは、制御ファイル内のデータが最新の状態かどうかによって決まります。制御ファイル内のバックアップ・メタデータが、新しいレコードで上書きされる前にカタログに記録されていることを確認する必要があります。

CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが制御ファイルに保持される最小日数を指定します。この日数後は、レコードは上書き対象になります。このため、これらのレコードが消去される前に、リカバリ・カタログを制御ファイルのレコードと再同期化する必要があります。

CONTROL_FILE_RECORD_KEEP_TIME設定より短い間隔で、次の処理のいずれかを実行します。

  • バックアップを実行することによって、リカバリ・カタログの再同期化を暗黙的に実行します。

  • RESYNC CATALOGコマンドを使用して、リカバリ・カタログを手動で再同期化します。

CONTROL_FILE_RECORD_KEEP_TIMEがバックアップまたは再同期化の間隔より長くなるようにします。そうしないと、制御ファイルがリカバリ・カタログに伝播される前に再利用される場合があります。通常、予定の間隔に1週間を追加することをお薦めします。

注意:

CONTROL_FILE_RECORD_KEEP_TIMEは0に設定しないでください。そうすると、制御ファイル内のバックアップ・レコードが、RMANによってカタログに追加される前に上書きされる場合があります。

制御ファイルのサイズが大きくなりすぎることは問題です。ターゲット・データベースの制御ファイルのサイズは、次のものの数に応じて大きくなります。

  • 実行するバックアップ操作

  • データベースが生成するアーカイブREDOログ

  • 前述の情報が制御ファイルに保持される日数

制御ファイルのサイズが大きくなり、ブロック数またはレコード数が上限に達して制御ファイルのサイズがそれ以上大きくならない場合、最も古いレコードは、CONTROL_FILE_RECORD_KEEP_TIMEの設定値に達していなくても上書きされる場合があります。この場合、データベースはアラート・ログにメッセージを書き込みます。この状況が頻繁に発生する場合、CONTROL_FILE_RECORD_KEEP_TIMEの値を減らし、再同期化の頻度を高くします。

関連項目:

13.8.2.3 リカバリ・カタログの手動での再同期化

ターゲット・データベースの制御ファイルを使用してリカバリ・カタログの完全再同期化を強制実行するには、RESYNC CATALOGを使用します。

Data Guard環境で特定のデータベースを再同期化するか、またはすべてのデータベースを再同期化するかに応じて、RESYNC CATALOG FROM DB_UNIQUE_NAMEまたはALLを使用してデータベースの一意の名前を指定できます。DB_UNIQUE_NAME ALLを使用するには、パスワード・ファイル認証を使用してSYSユーザーとしてターゲット・データベースに接続する必要があります。通常、この操作は、スタンバイ・データベースに対するCONFIGUREコマンドを実行した後、そのスタンバイ・データベースに接続していない場合に実行します。

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
  2. ターゲット・データベースをマウントまたはオープンします。
    STARTUP MOUNT;
  3. リカバリ・カタログを再同期化します。

    RMANプロンプトで、RESYNC CATALOGコマンドを次のように実行します。 

    RESYNC CATALOG;

    次の例では、standby1の制御ファイルを再同期化します。 

    RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;

    次の例では、SYSユーザーとしてターゲット・データベースに接続してパスワード・ファイル認証を使用する場合、Data Guard環境ですべてのデータベースの制御ファイルを再同期化します。 

    RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;

    関連項目:

13.8.3 DB_UNIQUE_NAMEを変更した後のリカバリ・カタログの更新

Data Guard環境でデータベースのDB_UNIQUE_NAMEを変更する必要がある場合があります。この場合は、CHANGE DB_UNIQUE_NAMEコマンドを実行して、リカバリ・カタログに格納されている古いDB_UNIQUE_NAMEに関するメタデータを新しいDB_UNIQUE_NAMEに関連付けることができます。

CHANGE DB_UNIQUE_NAMEコマンドによって、データベース自体のDB_UNIQUE_NAMEが実際に変更されることはありません。かわりに、一意の名前が変更された(または変更される)データベースに関するカタログ・メタデータが更新されます。

次の手順では、プライマリ・データベースのDB_UNIQUE_NAMEがprodnyであること、およびスタンバイ・データベースのDB_UNIQUE_NAMEをprodsf1からprodsf2に変更したことを想定しています。プライマリ・データベースのDB_UNIQUE_NAMEを変更した後に、同じ手順を使用できます。ただし、ステップ1で、プライマリ・データベースではなく、スタンバイ・データベースにRMANをTARGETとして接続する点は異なります。

DB_UNIQUE_NAMEを変更した後にリカバリ・カタログを更新する手順

  1. RMANをTARGETとしてプライマリ・データベースに接続し、リカバリ・カタログにも接続します。たとえば、次のコマンドを入力します。
    % rman
RMAN> CONNECT CATALOG rco@catdb

recovery catalog database Password: password
connected to recovery catalog database

RMAN> CONNECT TARGET sbu@prodny

target database Password: password
connected to target database: PRODNY (DBID=39525561)
  2. リカバリ・カタログで認識されるDB_UNQUE_NAME値を表示します。

    次のLISTコマンドを実行します。 

    RMAN> LIST DB_UNIQUE_NAME OF DATABASE;
  3. RMANメタデータ内のDB_UNIQUE_NAMEを変更します。

    次の例では、データベースの一意の名前をスタンバイ・データベースprodsf1からprodsf2に変更します。 

    RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;

13.8.4 リカバリ・カタログからのターゲット・データベースの登録の解除

UNREGISTER DATABASEコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。

データベースがリカバリ・カタログから登録解除されると、RMANのすべてのリポジトリ・レコードが消失します。データベースは再度登録できますが、このデータベースのリカバリ・カタログ・レコードは、再登録時の制御ファイルの内容に基づきます。ターゲット・データベースの制御ファイル内のCONTROLFILE_RECORD_KEEP_TIME設定より古いレコードは消失します。また、制御ファイルに格納されていないストアド・スクリプトも消失します。

13.8.4.1 Data Guard環境外のターゲット・データベースの登録の解除

UNREGISTER DATABASEコマンドを使用して、ターゲット・データベースの登録を解除します。

この例では、リカバリ・カタログを使用せずにプライマリ・データベースとスタンバイ・データベースのメタデータを格納すると想定しています。

データベースの登録を解除する手順

  1. RMANを起動し、登録を解除するデータベースにTARGETとして接続します。リカバリ・カタログにも接続します。

    ターゲット・データベースに接続する必要はありませんが、接続しない場合は、UNREGISTERコマンドでターゲット・データベースの名前を指定する必要があります。リカバリ・カタログで複数のデータベースに同じ名前がある場合は、コマンドを囲むようにRUNブロックを作成し、SET DBIDを使用してデータベースのDBIDを設定する必要があります。

  2. 起動時に、RMANによって表示されたDBIDを書き留めます。

    たとえば、RMANは、オープンしているターゲット・データベースに接続した場合、次の形式の行を出力します。

    connected to target database: PROD (DBID=39525561)
  3. 念のため、LIST BACKUP SUMMARYおよびLIST COPY SUMMARYを使用して、リカバリ・カタログに記録されているすべてのバックアップを表示すると役に立つ場合があります。この場合、後でデータベースを再登録するときに、制御ファイルで認識されないバックアップをカタログに再度追加できます。
  4. データベースのすべてのバックアップを実際に削除する場合は、DELETE文を実行して、既存のすべてのバックアップを削除します。データベースをリカバリ・カタログから削除し、制御ファイルを使用してこのデータベースのRMANメタデータを格納する場合は、すべてのバックアップは削除しないでください。

    次のコマンドは、バックアップの削除方法を示しています。

    DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
DELETE COPY;

    RMANによって、削除されるバックアップが表示され、それらの削除前に確認するように求められます。

  5. UNREGISTER DATABASEコマンドを実行します。次に例を示します。
    UNREGISTER DATABASE;

    RMANにデータベース名およびDBIDが表示され、確認するように求められます。

    database name is "RDBMS" and DBID is 931696259
 
Do you really want to unregister the database (enter YES or NO)? yes

    プロセスが完了すると、RMANは次のメッセージを出力します。

    database unregistered from the recovery catalog
13.8.4.2 スタンバイ・データベースの登録の解除

UNREGISTERコマンドでは、Data Guard環境での使用のためにDB_UNIQUE_NAME句がサポートされています。この句を使用すると、特定のデータベースのメタデータを削除できます。

リカバリ・カタログによって、バックアップは特定のデータベースに関連付けられます。データベースの登録を解除すると、RMANは、これらのバックアップ・ファイルのデータベース名をNULLに更新します。そのため、バックアップは記録されていますが、バックアップの所有者は存在しなくなります。CHANGE ... RESET DB_UNIQUE_NAMEコマンドを実行すると、現在所有者が存在しないバックアップの所有権を別のデータベースに関連付けることができます。UNREGISTERコマンドにINCLUDING BACKUPSを指定した場合、RMANは、登録を解除されたデータベースのバックアップ・メタデータも削除します。

この例では、プライマリ・データベースlnx3に、関連付けられたスタンバイ・データベースstandby1があると想定しています。このスタンバイ・データベースの登録を解除します。

スタンバイ・データベースの登録を解除する手順

  1. RMANを起動し、TARGETとしてプライマリ・データベースに接続します。また、リカバリ・カタログにもRMANを接続します。

    たとえば、次のコマンドを入力します。

    % rman
RMAN> CONNECT TARGET "sbu@lnx3 AS SYSBACKUP";

target database Password: password
connected to target database: LNX3 (DBID=781317675)

RMAN> CONNECT CATALOG rco@catdb;
  2. データベースの一意の名前を表示します。

    たとえば、LIST DB_UNIQUE_NAMEコマンドを次のように実行します。 

    RMAN> LIST DB_UNIQUE_NAME OF DATABASE;

List of Databases
DB Key  DB Name DB ID             Database Role   Db_unique_name
------- ------- ----------------- --------------- ------------------
1       LNX3    781317675         STANDBY         STANDBY1
1       LNX3    781317675         PRIMARY         LNX3
  3. UNREGISTER DB_UNIQUE_NAMEコマンドを実行します。

    たとえば、データベースstandbyの登録を解除するには、UNREGISTERコマンドを次のように実行します。 

    RMAN> UNREGISTER DB_UNIQUE_NAME standby1;

    RMANにデータベース名およびDBIDが表示され、確認するように求められます。

    database db_unique_name is "standby1", db_name is "LNX3" and DBID is 781317675
 
Do you really want to unregister the database (enter YES or NO)? yes

    プロセスが完了すると、RMANは次のメッセージを出力します。

    database with db_unique_name standby1 unregistered from the recovery catalog
13.8.4.3 リカバリ・アプライアンス環境でのターゲット・データベースの登録の解除

Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)環境では、UNREGISTER DATABASEコマンドを使用してリカバリ・アプライアンス・カタログから保護されたデータベースを登録解除することはできません。かわりに、DBMS_RA.DELETE_DBプロシージャを使用します。

リカバリ・アプライアンス・リカバリ・カタログからターゲット・データベースの登録を解除するには、次の手順を実行します。

  1. 登録解除する保護されたデータベースのDB_NAMEを取得します。
  2. (オプション)この保護されたデータベースに関連付けられたすべてのバックアップを削除するには、次のステップを実行します。

    • SYSDBAまたはSYSBACKUP権限を持つユーザーとして保護されたデータベースに接続します。

    • 次のコマンドを使用して、すべてのバックアップを削除します。

      DELETE BACKUP DEVICE TYPE sbt;
DELETE BACKUP DEVICE TYPE DISK;
DELETE COPY;

      RMANによって、削除されるバックアップが表示され、それらの削除前に確認するように求められます。

  3. SQL*Plusを起動し、RASYS (リカバリ・アプライアンス・カタログ所有者)としてリカバリ・アプライアンス・メタデータ・データベースに接続します。
  4. DBMS_RA.DELETE_DBプロシージャを使用してリカバリ・アプライアンスから保護されたデータベースを登録解除します。
    begin
      DBMS_RA.DELETE_DB('TEST_DB');
end;
/

    RMANによって、データベースの登録解除操作を確認するよう求められます。

関連項目:

DBMS_RA.DELETE_DBプロシージャの詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。

13.8.5 リカバリ・カタログのデータベース・インカネーションの再設定

RESETLOGSオプションを使用してデータベースをオープンすると、データベースのインカネーションが作成されます。新しいインカネーションのレコードには、V$DATABASE_INCARNATIONビューでアクセスできます。

RESETLOGSオプションでデータベースをオープンすると、新しいデータベース・インカネーション・レコードがリカバリ・カタログ内に自動的に作成されます。また、データベースによって暗黙的かつ自動的にRESET DATABASEコマンドが発行され、このデータベースの新しいインカネーションが現行のインカネーションであることが指定されます。ターゲット・データベースによって実行される後続のすべてのバックアップおよびログのアーカイブは、新しいデータベース・インカネーションに関連付けられます。

RMANで、RESTOREとRECOVER、またはFLASHBACK DATABASEのいずれかを使用してデータベースを現行のRESETLOGS SCNより前のSCNに戻す場合は、常にRESET DATABASE TO INCARNATIONコマンドを実行する必要があります。ただし、RMANではフラッシュバックでRESET DATABASE TO INCARNATIONが暗黙的に実行されるため、次の場合はこのコマンドを明示的に実行する必要はありません。

次の手順では、RESETLOGSを使用してリカバリする場合にデータベース・インカネーションをリセットする方法について説明します。

リカバリ・カタログをメディア・リカバリの古いインカネーションにリセットする手順

  1. 必要なデータベース・インカネーションのインカネーション・キーを確認します。インカネーション・キー値を取得するには、LISTコマンドを発行します。 
    LIST INCARNATION OF DATABASE trgt;

List of Database Incarnations
DB Key  Inc Key   DB Name   DB ID       STATUS     Reset SCN    Reset Time
------- -------   -------   ------      -------    ----------   ----------
1       2         TRGT      1224038686  PARENT     1            02-JUL-12
1       582       TRGT      1224038686  CURRENT    59727        10-JUL-12

    インカネーション・キーは、Inc Key列に表示されます。

  2. データベースを以前のインカネーションに再設定します。たとえば、次のように入力します。
    RESET DATABASE TO INCARNATION 2;
  3. 以前のインカネーションの制御ファイルが使用可能でマウントされている場合、ステップ6にスキップします。そうでない場合、データベースを停止して、NOMOUNTモードで起動します。次に例を示します。
    SHUTDOWN IMMEDIATE
STARTUP NOMOUNT
  4. 以前のインカネーションから制御ファイルをリストアします。タグ付きの制御ファイルの場合、タグを指定します。そうでない場合、次のとおり、SET UNTILコマンドを実行できます。
    RUN 
{
  SET UNTIL 'SYSDATE-45';
  RESTORE CONTROLFILE; # only if current control file is not available
}
  5. リストアされた制御ファイルをマウントします。
    ALTER DATABASE MOUNT;
  6. RESTOREコマンドおよびRECOVERコマンドを実行して以前のインカネーションからデータベース・ファイルをリストアおよびリカバリし、RESETLOGSオプションを指定してデータベースをオープンします。たとえば、次のように入力します。
    RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;

    関連項目:

13.8.6 リカバリ・カタログのアップグレード

この項では、リカバリ・カタログのアップグレードの概要およびアップグレードの実行が必要となるタイミングについて説明します。

13.8.6.1 リカバリ・カタログのアップグレード

Oracle Database 12cリリース1 (12.1.0.2)以上にアップグレードする場合、リカバリ・カタログ・データベースではOracle DatabaseのEnterprise Editionを使用する必要があります。

RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。RMANのバージョンと互換性があるスキーマ・バージョンについては、Oracle Databaseバックアップおよびリカバリ・リファレンスの互換性の表を参照してください。たとえば、Oracle Database 11gのRMANクライアントでリリース10.2のリカバリ・カタログ・スキーマを使用する場合、そのカタログをアップグレードする必要があります。

Oracle Database 10gリリース1バージョンのリカバリ・カタログ・スキーマには、CREATE TYPE権限が必要です。10gR1より前のリリースでリカバリ・カタログの所有者を作成し、CREATE TYPE権限が含まれていないRECOVERY_CATALOG_OWNERロールを付与した場合は、カタログのアップグレードの前に、明示的にこの所有者にCREATE TYPEを付与する必要があります。

RMANクライアントで要求されるバージョンより新しいバージョンのリカバリ・カタログを使用している場合、UPGRADE CATALOGを発行するとエラーが表示されます。 RMANでは、リカバリ・カタログが現行のバージョンでアップグレードが必要ない場合でもUPGRADE CATALOGコマンドを実行できます。このコマンドを実行すると、必要に応じていつでもパッケージを再作成できます。アップグレード中に生成されたエラー・メッセージを、メッセージ・ログで確認してください。

13.8.6.1.1 Data Guard環境でリカバリ・カタログをアップグレードする際の特別な考慮事項

Data Guard環境で、リカバリ・カタログ・スキーマをOracle Database 11g以降にアップグレードすると想定します。RMANは、スタンバイ・データベースに接続する際に、新しいデータベース情報を自動的に登録し、再同期化してファイル名を制御ファイルから取得します。

再同期化中に、RMANは名前をターゲット・データベース名に関連付けます。リカバリ・カタログには、履歴メタデータが含まれているため、制御ファイルで認識されないレコードもあります。たとえば、standby1制御ファイルでは、primary1に作成されたすべてのバックアップについては認識されません。これらの古いレコードのデータベースの一意の名前はNULLです。「リカバリ・カタログのメンテナンス」で説明されているように、CROSSCHECKを使用してこれらのレコードを修正できます。

13.8.6.2 リカバリ・カタログのスキーマ・バージョンの確認

リカバリ・カタログのスキーマ・バージョンは、リカバリ・カタログ自体に格納されます。この情報は、本番システムにバージョンの異なる複数のデータベースが存在し、カタログのスキーマ・バージョンが特定のターゲット・データベース・バージョンで使用可能かどうかを確認する必要がある場合に重要です。

リカバリ・カタログのスキーマ・バージョンを確認する手順

  1. SQL*Plusを起動し、カタログ所有者としてリカバリ・カタログ・データベースに接続します。
  2. RCVER表を問い合せてスキーマ・バージョンを取得します。次に、コマンドと出力の例を示します。
    SELECT *
FROM   rcver;

VERSION
------------
12.01.00.01

RCVER表に複数の行が表示される場合、この表内で最上位のバージョンが、現行のカタログ・スキーマ・バージョンです。この表に格納されるのはメジャー・バージョン番号のみであり、パッチ番号は格納されません。たとえば、rcver表に次の行が表示されたと想定します。 

VERSION
------------
10.02.00
11.02.00
12.01.00.01

これらの行は、カタログがリリース10.2.0の実行可能ファイルによって作成され、リリース11.2.0にアップグレードされ、最後にリリース12.1.0.1にアップグレードされたことを示しています。カタログ・スキーマの現行バージョンは12.1.0.1です。

関連項目:

RMAN環境で適用される互換性規則の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください。

13.8.6.3 UPGRADE CATALOGコマンドの使用

この例では、リカバリ・カタログ・スキーマを現行のバージョンにアップグレードすると想定しています。

注意:

Oracle Database 12cリリース1 (12.1.0.2)以降、リカバリ・カタログ・データベースではOracle DatabaseのEnterprise Editionを使用する必要があります。

リカバリ・カタログをアップグレードする手順

  1. リカバリ・カタログ・データベースのOracleパーティション化を有効にします。

  2. リカバリ・カタログ・データベースでStandard Editionを使用する場合、次のいずれかの方法を使用します。

    • リカバリ・カタログ・データベースをStandard EditionからEnterprise Editionに移行します。

    • リカバリ・カタログをOracle Enterprise Editionデータベースに移動し、IMPORT CATALOGコマンドを使用して、リカバリ・カタログをこのデータベースにインポートします。

  3. SQL*Plusを使用して、SYSDBA権限を持つSYSユーザーとしてリカバリ・カタログ・データベースに接続します。

  4. dbmsrmansys.sqlスクリプトを実行して、RECOVERY_CATALOG_OWNERロールに必要なその他の権限を付与します。 

    SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql

  5. (オプション) –vpdオプションを指定してdbmsrmanvpc.sqlスクリプトを実行して、リカバリ・カタログのVPDモデルを有効にします。

    次のコマンドは、ユーザーrcoが所有するリカバリ・カタログのVPDモデルを有効にします。 

    SQL> @/$ORACLE_HOME/rdbms/admin/dbmsrmanvpc.sql -vpd rco;

  6. SQL*Plusを終了します。

  7. RMANを起動し、リカバリ・カタログ・データベースにRMANを接続します。

  8. UPGRADE CATALOGコマンドを実行します。 

    RMAN> UPGRADE CATALOG;

recovery catalog owner is rman 
enter UPGRADE CATALOG command again to confirm catalog upgrade

  9. 確認のためにUPDATE CATALOGコマンドを再度実行します。 

    RMAN> UPGRADE CATALOG;

recovery catalog upgraded to version 12.01.00.01
DBMS_RCVMAN package upgraded to version 12.01.00.01
DBMS_RCVCAT package upgraded to version 12.01.00.01

    注意:

    このステップを行わないためには、ステップ7のUPGRADE CATALOGコマンドの後にNOPROMPTオプションを追加します。

関連項目:

13.8.7 リカバリ・カタログのインポートおよび移動

RMANでIMPORT CATALOGコマンドを使用して、1つのリカバリ・カタログ・スキーマを別のリカバリ・カタログ・スキーマにマージできます。

このコマンドは、次の場合に有効です。

  • 様々なバージョンのデータベースに対して複数のリカバリ・カタログ・スキーマが存在する場合。バックアップ・メタデータを失わずに、既存のすべてのスキーマを1つにマージする必要があります。

  • リカバリ・カタログをデータベース間で移動する場合。

13.8.7.1 リカバリ・カタログのインポート

IMPORT CATALOGを使用する場合、ソース・カタログ・スキーマが、別のスキーマにインポートするカタログ・スキーマになります。宛先カタログ・スキーマは、ソース・カタログ・スキーマのインポート先のカタログ・スキーマです。

デフォルトでは、RMANは、ソース・リカバリ・カタログに登録されているすべてのターゲット・データベースのメタデータをインポートします。必要に応じて、ソース・カタログ・スキーマからインポートするデータベースのIDのリストを指定できます。

デフォルトでは、RMANは、正常なインポートの後で、インポートしたデータベースをソース・カタログ・スキーマから登録解除します。登録解除が正常に実行されたかどうかを示すために、RMANは、マージされたデータベースの登録解除の前後にメッセージを出力します。NO UNREGISTERオプションを指定して、データベースがソース・カタログから登録解除されないように指定することもできます。

ストアド・スクリプトは、グローバルまたはローカルのいずれかです。グローバル・スクリプトでは、宛先スキーマにすでにスクリプト名が含まれているために、インポート中に名前の競合が発生する可能性があります(ローカル・スクリプトでは発生しません)。この場合、RMANは、グローバル・スクリプト名をCOPY OF script_nameに変更します。たとえば、RMANは、bp_cmdをCOPY OF bp_cmdに変更します。

名前が変更されたグローバル・スクリプトも一意でない場合、RMANは、その名前をCOPY(2) OF script_nameに変更します。このスクリプト名も存在する場合、RMANは、スクリプトの名前をCOPY(3) OF script_nameに変更します。RMANは、スクリプト名が一意になるまでCOPY(n) OFのパターンを繰り返します。

13.8.7.2 リカバリ・アプライアンス環境でのリカバリ・カタログのインポートについて

リカバリ・アプライアンス環境では、リカバリ・アプライアンス上に存在する単一の中央管理されたリカバリ・アプライアンス・カタログは、保護されたすべてのデータベースによって共有されます。このカタログは、リカバリ・アプライアンスにバックアップを送信する保護されたすべてのデータベースによって使用される必要があります。

リカバリ・アプライアンスを使用するデータ保護方針に保護されたデータベースを移動する場合、既存のバックアップおよびバックアップ・メタデータをリカバリ・アプライアンスに移行することを選択できます。バックアップ・メタデータを移行するには、RMANリカバリ・カタログをリカバリ・アプライアンス・カタログにインポートする必要があります。

関連項目:

13.8.7.3 リカバリ・カタログのインポートの前提条件

ターゲット・データベース、リカバリ・カタログ・データベースおよびリカバリ・カタログ・スキーマのデータベース・バージョンは異なっている場合があります。最新のバージョンのリカバリ・カタログ・スキーマで、既存のすべてのリカバリ・カタログを1つのリカバリ・カタログにインポートすることをお薦めします。

カタログのバージョンを確認する方法については、「リカバリ・カタログのスキーマ・バージョンの確認」を参照してください。互換性の表を確認し、使用している環境内で互換性があるスキーマ・バージョンを判別します。

IMPORT CATALOGを使用する場合、ソース・リカバリ・カタログ・スキーマのバージョンは、このコマンドの実行に使用するRMAN実行可能ファイルの現行のバージョンと一致している必要があります。ソース・カタログ・スキーマのバージョンのほうが低い場合は、スキーマをインポートする前に現行のバージョンにアップグレードします。アップグレード方法については、「リカバリ・カタログのアップグレード」を参照してください。ソース・リカバリ・カタログ・スキーマのバージョンのほうが高い場合は、より高いバージョンのRMAN実行可能ファイルを使用してインポートを再試行します。

ソース・カタログ・スキーマと宛先カタログ・スキーマの両方にデータベースを登録することはできません。現在、データベースが両方のカタログ・スキーマに登録されている場合は、インポートを実行する前にソース・カタログ・スキーマからデータベースを登録解除します。

関連項目:

『Oracle Database Recovery Managerリファレンス』

13.8.7.4 リカバリ・カタログのインポート

リカバリ・カタログを別のリカバリ・カタログにインポートする場合、ターゲット・データベースへの接続は必要ありません。RMANは、ソース・カタログおよび宛先カタログにのみ接続する必要があります。

次の例では、データベースsrcdbにユーザー102catが所有する10.2リカバリ・カタログ・スキーマが含まれており、データベースdestdbにユーザー111catが所有する11.1リカバリ・カタログ・スキーマが含まれています。

リカバリ・カタログをインポートする手順

  1. RMANを起動し、CATALOGとして宛先リカバリ・カタログ・スキーマに接続します。次に例を示します。
    % rman
RMAN> CONNECT CATALOG 111cat@destdb;
  2. ソース・カタログの接続文字列を指定して、ソース・リカバリ・カタログ・スキーマをインポートします。

    たとえば、次のコマンドを入力して、データベースsrcdbの102catが所有するカタログをインポートします。 

    IMPORT CATALOG 102cat@srcdb;

    前述の例を少し変更して、ソース・カタログに登録されたターゲット・データベースのサブセットに関するメタデータをインポートすることもできます。DBIDまたはデータベース名によってデータベースを指定できます。次に例を示します。

    IMPORT CATALOG 102cat@srcdb DBID=1423241, 1423242;
IMPORT CATALOG 102cat@srcdb DB_NAME=prod3, prod4;
  3. 必要に応じて、ターゲット・データベースに接続して、メタデータが正常にインポートされたことを確認します。たとえば、次のコマンドは、データベースprod1にTARGETとして接続し、このデータベースのすべてのバックアップを表示します。
    CONNECT TARGET "sbu@prod1 AS SYSBACKUP";
LIST BACKUP;

    sbuは、ターゲット・データベースでSYSBACKUP権限を付与されたユーザーです。

13.8.7.5 リカバリ・カタログの移動

データベース間でリカバリ・カタログを移動する手順は、カタログをインポートする手順に類似しています。

次の例では、ソース・データベースは既存のリカバリ・カタログを含むデータベースで、移動先データベースには移動されたリカバリ・カタログが含まれます。

ソース・データベースから移動先データベースにリカバリ・カタログを移動する手順

  1. 移動先データベースでリカバリ・カタログを作成しますが、新しいカタログにデータベースは登録しません。

    このタスクの実行方法については、「リカバリ・カタログの作成」を参照してください。

  2. 前のステップで作成したカタログにソース・カタログをインポートします。

    このタスクの実行方法については、「リカバリ・カタログのインポート」を参照してください。

13.9 リカバリ・カタログの削除

DROP CATALOGコマンドを使用すると、CREATE CATALOGコマンドによって作成されたオブジェクトが削除されます。リカバリ・カタログを所有するユーザーが、CREATE CATALOGで作成されなかったオブジェクトも所有している場合、これらのオブジェクトはDROP CATALOGコマンドでは削除されません。

リカバリ・カタログ・スキーマのバックアップが存在しない場合にリカバリ・カタログを削除すると、このカタログに登録されているすべてのターゲット・データベースのバックアップが使用できなくなる可能性があります。ただし、すべてのターゲット・データベースの制御ファイルには、そのデータベースの最近のバックアップのレコードが保持されます。

DROP CATALOGコマンドは、複数のターゲット・データベースが登録されたリカバリ・カタログから1つのデータベースを登録解除する場合には使用しないことをお薦めします。リカバリ・カタログを削除すると、そのカタログに登録されたすべてのターゲット・データベースのバックアップのリカバリ・カタログ・レコードが削除されます。

リカバリ・カタログ・スキーマを削除する手順

  1. RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。削除するカタログ・スキーマの所有者として、リカバリ・カタログに接続します。

    次の例では、ユーザーrcoとしてリカバリ・カタログに接続します。 

    % rman TARGET / CATALOG rco@catdb
  2. DROP CATALOGコマンドを実行します。
    DROP CATALOG;

recovery catalog owner is rco
enter DROP CATALOG command again to confirm catalog removal

    注意:

    次の確認のステップをスキップするためには、このステップのDROP CATALOGコマンドにNOPROMPTオプションを追加します。

  3. 確認のためにDROP CATALOGコマンドを再度実行します。
    DROP CATALOG;

    注意:

    リカバリ・カタログを削除しても、制御ファイルにはバックアップに関するレコードが含まれたままです。RMANリポジトリ・レコードを制御ファイルから消去するには、制御ファイルを再作成します。

    関連項目: