ヘッダーをスキップ
Oracle Databaseバックアップおよびリカバリ・アドバンスト・ユーザーズ・ガイド
10g リリース2(10.2)
B19192-03
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

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

この章では、Recovery Managerのリカバリ・カタログを管理する方法について説明します。リカバリ・カタログには、1つ以上のデータベースの個々のデータベース・スキーマのRecovery Managerリポジトリ・データを格納でき、データベースの制御ファイルと併用できます。

この章の内容は、次のとおりです。

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

リカバリ・カタログを作成するには、リカバリ・カタログを格納するデータベースの構成、リカバリ・カタログ所有者の作成、リカバリ・カタログ自体の作成という3段階の手順を実行する必要があります。

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

Recovery Managerでリカバリ・カタログを使用する場合、リカバリ・カタログ・スキーマを保持する必要があります。リカバリ・カタログは、スキーマのデフォルト表領域に格納されます。SYSはリカバリ・カタログ所有者に設定できないことに注意してください。

リカバリ・カタログ・スキーマのインストールに使用するデータベースを決定し、そのデータベースのバックアップ方法も決定します。


注意:

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

また、カタログ・データベースをARCHIVELOGモードで操作するかどうかを決定します。カタログ・データベースはARCHIVELOGモードで操作することをお薦めします。

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

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

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

通常、バックアップ・ピースの行領域の一部のみが使用されるため、現実的な概算値は年間15MBです。

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

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

リカバリ・カタログを既存のデータベース内に作成する場合、デフォルト表領域を保持するために十分な空き領域をリカバリ・カタログ・スキーマに追加します。リカバリ・カタログを格納するための新しいデータベースを作成する場合、リカバリ・カタログ・スキーマ自体の領域に加えて、次に示すリカバリ・カタログ・データベース内の他のファイル用の領域も考慮する必要があります。

  • SYSTEM表領域

  • 一時表領域

  • ロールバック・セグメント表領域

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

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

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

領域タイプ 領域要件

SYSTEM表領域

90MB

一時表領域

5MB

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

5MB

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

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

オンラインREDOログ

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



注意:

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


リカバリ・カタログ所有者の作成

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

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

  • ユーザーSYS(パスワードoracle)は、catdbリカバリ・カタログ・データベースに対するSYSDBA権限を持っています。

  • catdbリカバリ・カタログ・データベース内のtoolsという表領域にリカバリ・カタログが格納されています。Recovery Managerの予約語を表領域名として使用する場合、その語を引用符で囲み、大文字を使用する必要があります。 (Recovery Managerの予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。)

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

  • データベースは、通常のデータベースと同様に構成されています。たとえば、catalog.sqlおよびcatproc.sqlが正常に実行されています。

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

SQL*Plusを起動し、リカバリ・カタログを含むデータベースに管理者権限で接続します。たとえば、次のように入力します。

CONNECT SYS/oracle@catdb AS SYSDBA

リカバリ・カタログのユーザーおよびスキーマを作成します。たとえば、次のように入力します。

CREATE USER rman IDENTIFIED BY cat
  TEMPORARY TABLESPACE temp
  DEFAULT TABLESPACE tools
  QUOTA UNLIMITED ON tools;

スキーマ所有者にRECOVERY_CATALOG_OWNERロールを付与します。このロールによって、リカバリ・カタログのメンテナンスおよび問合せに必要なすべての権限がユーザーに付与されます。

SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;

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

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

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

カタログを格納するデータベースに、カタログ所有者として接続します。たとえば、次のように入力します。

% rman
RMAN> CONNECT CATALOG rman/cat@catdb

CREATE CATALOGコマンドを実行してカタログを作成します。カタログの作成には数分かかります。カタログ表領域がこのユーザーのデフォルト表領域の場合、次のコマンドを実行できます。

CREATE CATALOG;

CREATE CATALOGコマンドでカタログの表領域名を指定できます。たとえば、次のように入力します。

CREATE CATALOG TABLESPACE cat_ts;

注意:

リカバリ・カタログに使用する表領域名がRecovery Managerの予約語である場合は、その予約語を大文字にして引用符で囲む必要があります。たとえば、次のように入力します。
CREATE CATALOG TABLESPACE 'CATALOG';

結果を確認するには、SQL*Plusを使用し、リカバリ・カタログを問い合せて作成された表を表示します。

SQL> SELECT TABLE_NAME FROM USER_TABLES;

参照:

GRANT文およびCREATE USER文のSQL構文の詳細は、『Oracle Database SQLリファレンス』を参照してください。CREATE CATALOGコマンドの構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

リカバリ・カタログ内のターゲット・データベース・レコードの管理

この項では、リカバリ・カタログでターゲット・データベース・レコードをメンテナンスする方法について説明します。この章の内容は、次のとおりです。

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

ターゲット・データベースでリカバリ・カタログを使用するには、まずそのデータベースをリカバリ・カタログに登録します。次の手順を実行します。

リカバリ・カタログ・データベースがオープンしていることを確認し、Recovery Managerをターゲット・データベースおよびリカバリ・カタログ・データベースに接続します。たとえば、catdbカタログ・データベースにユーザーrman(カタログ・スキーマ所有者)として接続するには、次のコマンドを実行します。

% rman TARGET / CATALOG rman/cat@catdb

ターゲット・データベースをマウントしていない場合、マウントまたはオープンします。

RMAN> STARTUP MOUNT;

接続しているリカバリ・カタログに、ターゲット・データベースを登録します。

RMAN> REGISTER DATABASE;

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

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

RMAN> REPORT SCHEMA;

Report of database schema
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

リカバリ・カタログへの古いファイルの追加

データ・ファイルのコピー、バックアップ・ピースまたはアーカイブ・ログがディスクに存在する場合、CATALOGコマンドを使用して、それらをリカバリ・カタログに追加できます。リカバリ・カタログを使用する場合、古くなったために制御ファイルから削除されたバックアップをカタログに追加すると、リストア操作中に、その古いバックアップが使用されます。たとえば、次のように入力します。

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


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

RMAN> CATALOG START WITH '/disk1/backups/';

Recovery Managerによって、Recovery Managerリポジトリに追加されるファイルがリストされ、それらのバックアップが追加される前に確認するように求められます。


注意:

CATALOG START WITHに接頭辞を指定する場合は注意が必要です。Recovery Managerは、ディスク上で、指定された接頭辞が付いたすべてのパスのすべてのファイルをスキャンします。接頭辞は、通常のディレクトリ名ではありません。不適切な接頭辞を使用すると、不適切なファイル・セットがカタログに追加される場合があります。たとえば、/disk1/backups/disk1/backups-year2003/disk1/backupsets/disk1/backupsets/testなどの一連のディレクトリには、バックアップ・ファイルが含まれています。次のコマンドを実行すると、それらのすべてのディレクトリ内のすべてのファイルがカタログに追加されます。
RMAN> CATALOG START WITH '/disk1/backups';

これは、/disk1/backupsが、これらのすべてのディレクトリへのパスの接頭辞であるためです。/disk1/backupsディレクトリ内のバックアップのみをカタログに追加するには、次のコマンドが適切です。

RMAN> CATALOG START WITH '/disk1/backups/';

リカバリ・カタログへのOracle7データ・ファイルのコピーの追加

通常、カタログに追加できるのは、Oracle8以上のファイルのみです。Oracle7データベースからのデータ・ファイルのコピーも、Oracle7のREDO Applyを使用せずにオープンできる場合はカタログに追加できます。次の状況で作成されたデータ・ファイルのコピーは、この要件を満たしています。

  • データベースが一貫性のある状態で停止されたときに作成されたデータ・ファイルのコピー。このデータベースは、Oracle7より新しいバージョンのOracleに移行される前にオープンされていない必要があります。

  • 表領域がNORMALモードでオフラインにされるか、読取り専用になった後に作成されたデータ・ファイルのコピー。この表領域は、Oracle7より新しいバージョンのOracleに移行される前にオンラインまたは読取り/書込みにされていない必要があります。


    参照:

    • REGISTER構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

    • データベースの移行に関連する問題は、『Oracle Databaseアップグレード・ガイド』を参照してください。


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

重複したDBIDを持たない複数のターゲット・データベースを1つのリカバリ・カタログに登録できます。Recovery Managerは、DBIDを使用して個々のデータベースを識別します。

Recovery ManagerのDUPLICATEコマンドまたはSQLのCREATE DATABASE文を使用する場合、通常、作成されるデータベースには一意のDBIDが割り当てられます。ユーザー管理コピーなどの、その他の方法でデータベースを作成した場合、新しいデータベースのDBIDはコピー元のデータベースと同じものになります。DBNEWIDユーティリティを使用して、コピーされたデータベースのDBIDを変更しないかぎり、両方のデータベースを同じリカバリ・カタログに登録することはできません。

1つのターゲット・データベースを複数のリカバリ・カタログに登録することもできます。


参照:

  • DUPLICATE構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

  • DBNEWIDユーティリティを使用してDBIDを変更する方法については、『Oracle Databaseユーティリティ』を参照してください。

  • データベースの移行に関連する問題は、『Oracle Databaseアップグレード・ガイド』を参照してください。


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

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


注意:

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

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

Recovery Managerを起動し、ターゲット・データベースに接続します。たとえば、次のように入力します。

% rman TARGET / CATALOG rman/cat@catdb

connected to target database: RDBMS (DBID=1237603294)
connected to recovery catalog database

起動時に、Recovery Managerによって表示されたDBIDを書き留めます。リカバリ・カタログに複数のデータベースが登録されている場合、データベースを一意に識別するためにDBIDが必要です。

ターゲット・データベースに接続する必要はありませんが、接続しない場合はUNREGISTERコマンドにターゲット・データベースの名前を指定する必要があります。リカバリ・カタログ内に同じ名前が付いた複数のデータベースが存在する場合、RUNブロックにUNREGISTERコマンドを含め、SET DBIDを使用して、該当するデータベースのDBIDを設定します。

念のため、LIST BACKUP SUMMARYおよびLIST COPY SUMMARYを使用して、リカバリ・カタログに記録されているすべてのバックアップをリストすると役に立つ場合があります。この場合、後でデータベースを再登録するときに、制御ファイルで認識されないバックアップをカタログに再度追加できます。

リカバリ・カタログからデータベースを削除して、このデータベースのRecovery Managerリポジトリの格納を制御ファイルのみで管理するのではなく、データベースのすべてのバックアップを完全に削除することが実際の目的である場合、DELETE文を実行してすべての既存のバックアップを削除します。たとえば、次のように入力します。

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

Recovery Managerによって、削除されるバックアップがリストされ、それらの削除前に確認するように求められます。

UNREGISTER DATABASEコマンドを実行します。たとえば、次のように入力します。

UNREGISTER DATABASE;

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

database name is "RDBMS" and DBID is 931696259

Do you really want to unregister the database (enter YES or NO)? yes

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

database unregistered from the recovery catalog

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

Recovery ManagerコマンドまたはSQL文のALTER DATABASE OPEN RESETLOGSを実行すると、データベースの新しいインカネーションが作成されます。 新しいインカネーションのレコードには、ターゲット・データベースのV$DATABASE_INCARNATIONビューでアクセスできます。

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

一部のリカバリ・タスクでは、リカバリ・カタログ内のデータベースの現行のインカネーションを変更する必要があります。インカネーションの変更方法については、次の手順を参照してください。

リカバリ・カタログを以前のインカネーションに再設定する手順

必要なデータベース・インカネーションのインカネーション・キーを確認します。インカネーション・キー値を取得するには、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-02
1       582       TRGT      1224038686  CURRENT    59727        10-JUL-02

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

データベースを以前のインカネーションに再設定します。たとえば、次のように入力します。

RESET DATABASE TO INCARNATION 2;

以前のインカネーションの制御ファイルが使用可能でマウントされている場合、最後の手順(RESTOREコマンドおよびRECOVERコマンドの実行)にスキップします。たとえば、次のように入力します。

SHUTDOWN IMMEDIATE
STARTUP NOMOUNT

以前のインカネーションから制御ファイルをリストアします。タグ付きの制御ファイルの場合、タグを指定します。そうでない場合、次のとおり、SET UNTILコマンドを実行できます。

RUN
{
  SET UNTIL 'SYSDATE-45';
  RESTORE CONTROLFILE; # only if current control file is not available
}

リストアされた制御ファイルをマウントします。

ALTER DATABASE MOUNT;

RESTOREコマンドおよびRECOVERコマンドを実行して以前のインカネーションからデータベース・ファイルをリストアおよびリカバリし、RESETLOGSオプションを指定してデータベースをオープンします。たとえば、次のように入力します。

RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;

参照:

RESET DATABASE構文とLIST構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

アップグレード後のリカバリ・カタログからのDELETEDレコードの削除

Oracle9i以上では、Recovery Managerは、ファイルの削除時に常にカタログ・レコードを削除し、DELETEDステータスには更新しません。ただし、Oracle9i より前のリリースでは、Recovery Managerは、リカバリ・カタログ・レコードを削除せずに、物理ファイルの削除後にレコードのステータスをDELETEDに更新していました。このため、Oracle9i より前のリリースで作成されたリカバリ・カタログを現行のリリースのリカバリ・カタログにアップグレードするときに、DELETEDステータスを持つレコードが存在する場合があります。 このような特別な場合は、prgrmanc.sqlスクリプトを実行できます。このスクリプトは、オペレーティング・システム固有の場所に格納されています(UNIXの場合、$ORACLE_HOME/rdbms/admin)。

DELETEDステータスを持つすべてのバックアップ・レコードを削除する手順

SQL*Plusセッションを開始し、リカバリ・カタログに接続します。次の例では、rcatデータベースにユーザーrmanとして接続しています。

% sqlplus rman/cat@catdb

prgrmanc.sqlスクリプトを実行します。

SQL> @?/rdbms/admin/prgrmanc.sql

このスクリプトを実行すると、DELETEDステータスを持つすべてのレコードがリカバリ・カタログから削除されます。

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

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

スナップショット制御ファイルを作成します。

リカバリ・カタログをスナップショット制御ファイルと比較します。

欠落したまたは変更された情報を追加してリカバリ・カタログを更新します。

Recovery Managerは、必要に応じて、BACKUPなどの特定のコマンドが実行されたときに自動的に再同期化を実行します。RESYNC CATALOGコマンドを使用して、完全再同期化を手動で実行することもできます。

リカバリ・カタログの再同期化時に更新されるレコードのタイプ

表10-2「再同期化中に更新されるレコード」に、Recovery Managerによって再同期化されるレコードのタイプを示します。

表10-2 再同期化中に更新されるレコード

レコード 説明

ログ履歴

オンラインREDOログ・スイッチの発生時に作成されます。

アーカイブREDOログ

オンライン・ログのアーカイブ、既存のアーカイブREDOログのコピーまたはアーカイブREDOログのバックアップ・セットのリストアによって作成されたアーカイブ・ログに関連したレコードです。Recovery Managerは、この情報を追跡して、検出できるアーカイブ・ログを識別します。

バックアップ履歴

バックアップ・セット、バックアップ・ピース、プロキシ・コピーおよびファイル・コピーに関連したレコードです。RESYNC CATALOGコマンドを使用すると、BACKUPコマンドが実行されたときこれらのレコードが更新されます。

インカネーション履歴

データベース・インカネーションに関連したレコードです。

物理スキーマ

データ・ファイルおよび表領域に関連したレコードです。ターゲット・データベースがオープンされている場合、UNDOセグメント情報も更新されます。

リカバリ・カタログ内の物理スキーマ情報は、ターゲット・データベースに現行の制御ファイルがマウントされている場合にのみ更新されます。

ターゲット・データベースにバックアップ制御ファイル、新しく作成された制御ファイル、または以前に表示された制御ファイルより古い制御ファイルがマウントされている場合、リカバリ・カタログ内の物理スキーマ情報は更新されません。物理スキーマ情報は、RESYNC CATALOG FROM CONTROLFILECOPYコマンドを使用した場合も更新されません。


完全再同期化と部分再同期化

再同期化には、完全再同期化と部分再同期化があります。部分再同期化では、Recovery Managerは現行の制御ファイルを読み取って、新規バックアップ、新規アーカイブ・ログなどに関連する情報のうち、変更されたものを更新します。ただし、Recovery Managerはデータベースの物理スキーマに関連するメタデータ(データ・ファイル、表領域、REDOスレッド、ロールバック・セグメント(データベースがオープンされている場合のみ)およびオンラインREDOログ)は再同期化しません。完全再同期化では、Recovery Managerは、データベース・スキーマのレコードを含め、変更されたすべてのレコードを更新します。


注意:

Recovery Managerは、バックアップ制御ファイルが使用される場合は部分再同期化は実行しますが、完全再同期化は実行しません。バックアップ制御ファイルにはデータベースの物理スキーマに関連する正確な情報が含まれていない場合があるため、完全再同期化を実行すると、リカバリ・カタログが不正確な情報で更新される可能性があります。


注意:

カタログの再同期化は、Oracle Enterprise Managerを使用して実行できます。


参照:

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

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

Recovery Managerは、完全再同期化または部分再同期化が必要とされるほぼすべての場合に、適切な再同期化を自動的に実行します。BACKUPDELETEなどの多くのRecovery Managerコマンドでは、ターゲット・データベースの制御ファイルがマウントされ、リカバリ・カタログ・データベースが使用可能な場合に(スキーマ・メタデータが変更されたかどうかに応じて)完全再同期化または部分再同期化が自動的に実行されます。そのため、RESYNC CATALOGを手動で実行する必要がある機会はあまり多くありません。

次の項では、再同期化を手動で実行する必要がある場合について説明します。

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

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

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

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

次の操作を実行すると想定します。

  • データベースをARCHIVELOGモードで実行します。

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

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

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

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

データベースの物理的な変更後の再同期化

ターゲット・データベースの物理構造を変更した後は、リカバリ・カタログを再同期化します。REDOログのアーカイブ操作の場合と同様に、リカバリ・カタログは、表領域の追加または削除、表領域へのデータ・ファイルの追加、ロールバック・セグメントの追加または削除などの物理スキーマの変更後、自動的には更新されません。

リカバリ・カタログの完全再同期化の強制実行

リカバリ・カタログの完全再同期化を強制実行するには、RESYNC CATALOGを使用します。

Recovery Managerをターゲット・データベースおよびリカバリ・カタログ・データベースに接続し、ターゲット・データベースがマウントまたはオープンされていない場合はマウントまたはオープンします。

STARTUP MOUNT;

RMANプロンプトで、RESYNC CATALOGコマンドを実行します。

RESYNC CATALOG;

参照:

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

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

リカバリ・カタログをメンテナンスする場合、制御ファイルのレコードが再利用される前に確実にリカバリ・カタログに伝播されるように、Recovery ManagerのRESYNC CATALOGコマンドを高い頻度で実行します。

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


注意:

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



参照:

制御ファイル・レコードの上書きを監視する方法については、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。

リカバリ・カタログ使用時の制御ファイルの管理

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

CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが制御ファイルに保持される最小日数を指定します。この日数後は、レコードは上書き対象になります。このため、これらのレコードが消去される前に、リカバリ・カタログを制御ファイルのレコードと再同期化する必要があります。 CONTROL_FILE_RECORD_KEEP_TIMEの設定値より短い間隔で次の操作のいずれかを実行する必要があります(「リカバリ・カタログの再同期化とCONTROL_FILE_RECORD_KEEP_TIME」を参照)。

つまり、リカバリ・カタログ内の情報を常に最新に保つには、CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータの値を考慮した頻度で再同期化を行う必要があります。

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

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


注意:

制御ファイルの最大サイズはポートによって異なります。通常、最大サイズは20,000 Oracleブロックです。詳細は、ご使用のプラットフォーム固有のOracleドキュメントを参照してください。


参照:

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

  • 制御ファイルの管理の詳細は、『Oracle Database管理者ガイド』を参照してください。


リカバリ・カタログでのRecovery Managerストアド・スクリプトの使用

ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRecovery Managerコマンドの管理に使用できます。

制御ファイルと比較したストアド・スクリプトの主なメリットは、ターゲット・データベースおよびリカバリ・カタログに接続可能なすべてのRecovery Managerクライアントで常に使用できることです。これに対して制御ファイルは、そのファイルが格納されているファイル・システムにRecovery Managerクライアントがアクセス可能である場合にのみ使用できます。

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

ストアド・スクリプトを使用するには(グローバル・ストアド・スクリプトの場合も)、リカバリ・カタログとターゲット・インスタンスの両方に接続する必要があることに注意してください。

ストアド・スクリプトの作成: CREATE SCRIPT

Recovery Managerが適切なターゲット・データベースおよびリカバリ・カタログに接続していることを確認します。次に、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;
}

ローカル・スクリプトまたはグローバル・スクリプトは、テキスト・ファイルから内容を読み取って作成することもできます。

CREATE SCRIPT full_backup FROM FILE 'my_script_file.txt';

このファイルでは、{文字で始まり、次に有効な一連のコマンドを含むRUNブロックが含まれ、最後に}文字で終わる必要があります。そうでない場合、キーボードからコマンドを入力した場合と同様の構文エラーが発生します。

ストアド・スクリプトの実行: EXECUTE SCRIPT

ストアド・スクリプトを実行するには、ターゲット・データベースおよびリカバリ・カタログに接続し、EXECUTE SCRIPTを実行します。EXECUTE SCRIPTは、次に示すとおり、RUNブロック内に指定する必要があります。

RUN { EXECUTE SCRIPT full_backup; }

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

RUN { EXECUTE GLOBAL SCRIPT global_full_backup; }
RUN { EXECUTE SCRIPT global_full_backup; }

グローバル・スクリプトは、接続しているターゲット・データベースのみに対して実行されます。複数のデータベースにわたってグローバル・スクリプトを実行するには、Recovery Managerクライアントを各データベースに個別に接続してからスクリプトを実行します。

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


参照:

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

ストアド・スクリプトの表示: PRINT SCRIPT

ストアド・スクリプトを表示またはファイルに出力するには、PRINT SCRIPTコマンドを使用します。ターゲット・データベースおよびリカバリ・カタログに接続したRecovery Managerで、次に示すとおり、PRINT SCRIPTコマンドを実行します。

PRINT SCRIPT full_backup;

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

PRINT SCRIPT full_backup TO FILE 'my_script_file.txt';

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

PRINT GLOBAL SCRIPT global_full_backup;

および

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

参照:

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

ストアド・スクリプトのリスト: LIST SCRIPT NAMES

リカバリ・カタログに定義されたスクリプトの名前を表示するには、LIST SCRIPT NAMESコマンドを使用します。このコマンドでは、現在接続しているターゲット・データベースに対して実行可能な、グローバルとローカル両方のすべてのストアド・スクリプトの名前が表示されます。

LIST SCRIPT NAMES;

LIST SCRIPT NAMESコマンドの実行時にRecovery Managerがターゲット・データベースに接続していない場合、エラーが通知されます。

グローバル・スクリプトの名前のみを表示するには、次の形式のコマンドを使用します。

LIST GLOBAL SCRIPT NAMES;

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

LIST ALL SCRIPT NAMES;

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


注意:

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


参照:

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

ストアド・スクリプトの更新: REPLACE SCRIPT

ストアド・スクリプトを更新するには、ターゲット・データベースおよびリカバリ・カタログに接続し、REPLACE SCRIPTコマンドを実行します。スクリプトが存在しない場合、Recovery Managerによってスクリプトが作成されます。

次のコマンドを実行すると、full_backupストアド・スクリプトが新しい内容で更新されます。

REPLACE SCRIPT full_backup
{
  BACKUP DATABASE PLUS ARCHIVELOG;
}

グローバル・スクリプトの場合、リカバリ・カタログに接続し、次のとおりREPLACE GLOBAL SCRIPTコマンドを実行することで更新できます。

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 'my_script_file.txt';

参照:

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

ストアド・スクリプトの削除: DELETE SCRIPT

ストアド・スクリプトをリカバリ・カタログから削除するには、カタログおよびターゲット・データベースに接続し、DELETE SCRIPTコマンドを実行します。

DELETE SCRIPT 'full_backup';

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

DELETE GLOBAL SCRIPT 'global_full_backup';

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

DELETE SCRIPT 'global_full_backup';

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


参照:

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

Recovery Managerクライアントの起動時のストアド・スクリプトの実行

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

% rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb SCRIPT 'full_backup';

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


参照:

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

ストアド・スクリプト名の制限事項

Recovery Managerによるスクリプト名の変換には、いくつかの制限事項があります。特に、ローカル・スクリプトとグローバル・スクリプトの名前が同じである場合は注意が必要です。

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


    参照:

    『Oracle Databaseバックアップおよびリカバリ・リファレンス』

  • コマンドラインにSCRIPT引数を指定してRecovery Managerを起動すると、ローカル・スクリプトとグローバル・スクリプトが同じ名前で定義されていた場合、Recovery Managerは常にローカル・スクリプトを実行します。

  • EXECUTE SCRIPTDELETE SCRIPTおよびPRINT SCRIPTコマンドでは、引数として渡されたスクリプト名が、接続しているターゲット・インスタンス用に定義されたスクリプトの名前ではない場合、指定した名前が付いたグローバル・スクリプトが検索され、該当する操作が実行されます。 たとえば、リカバリ・カタログに、global_full_backupという名前のグローバル・ストアド・スクリプトが存在するが、ターゲット・データベース用に定義されたglobal_full_backupというローカル・ストアド・スクリプトが存在しない場合、次のコマンドを実行すると、グローバル・スクリプトが削除されます。

    DELETE SCRIPT global_full_backup;
    


グローバル・ストアド・スクリプトとローカル・ストアド・スクリプトの混同による誤操作を回避するために、ネーミング規則を使用することをお薦めします。


参照:

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

リカバリ・カタログのバックアップおよびリカバリ

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

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

この項では、リカバリ・カタログのバックアップを計画する際の、一般的なガイドラインを示します。

リカバリ・カタログの定期的なバックアップ

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

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

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

リカバリ・カタログ・データベースのバックアップは、Recovery Managerを使用して実行できます。図10-1に示すとおり、リカバリ・カタログのリポジトリがカタログ・データベース内の制御ファイルになるように、NOCATALOGオプションを指定してRecovery Managerを起動します。

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

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

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

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

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

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

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

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

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

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


参照:

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

リカバリ・カタログの安全な格納

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

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

リカバリ・カタログ・データベースをバックアップする場合、ターゲット・データベースとカタログ・データベースを分離することが特に重要です。次に、実行してはならない例を示します。たとえば、次の場合を想定します。

  • prod1ターゲット・データベースおよびcatdbカタログ・データベースが異なるホスト上に存在します。

  • catdbには、prod1ターゲット・データベースのリカバリ・カタログ・リポジトリが含まれています。

catdbのバックアップにリカバリ・カタログを使用することにしましたが、カタログの作成場所を決定していません。catdbデータベースのリポジトリを含むカタログをcatdbデータベース内に作成すると、メディア障害によってcatdbが消失した場合、catdbのリストアが困難になり、prod1には、リストアに使用するリカバリ・カタログが存在しない状態のままになります。

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

Oracleのエクスポート・ユーティリティの1つを使用してRecovery Managerリカバリ・カタログの論理バックアップを作成しておくと、物理バックアップの有効な補助バックアップとなります。リカバリ・カタログ・データベースが破損した場合、エクスポートされたリカバリ・カタログ・データを別のデータベースに再インポートすることで、カタログを迅速に再構築できます。

バックアップからのリカバリ・カタログのリストアおよびリカバリ

リカバリ・カタログのリストアおよびリカバリは、リカバリ・カタログをRecovery Managerを使用してバックアップしていた場合は他のデータベースのリストアおよびリカバリとほぼ同様です。

リカバリ・カタログ・データベースの制御ファイルおよびSPFILEを自動バックアップからリストアし、その後、データベースの残りの部分のリストアおよび完全リカバリを実行できます。 必要な手順は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。複数のリカバリ・カタログを使用している場合、別のリカバリ・カタログを使用して、このリカバリ・カタログ・データベースのバックアップに関するメタデータを記録することもできます。

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

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

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

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

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

  • RESYNC CATALOGコマンドを使用して、ターゲット・データベースの制御ファイルまたは制御ファイルのコピーからのRecovery Managerリポジトリ情報でリカバリ・カタログを更新します。古くなったために制御ファイルから削除された制御ファイル・レコードに含まれているメタデータは消失することに注意してください。

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

この最悪の状況が発生する可能性を最小限に抑えるには、バックアップ計画に、少なくともRecovery Managerを使用したリカバリ・カタログのバックアップ(「リカバリ・カタログのバックアップ」を参照)を含める必要があります。


参照:

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

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

  • 古くなったレコードが制御ファイルから削除される手順の詳細は、「リカバリ・カタログ使用時の制御ファイルの管理」を参照してください。


リカバリ・カタログのエクスポートおよびインポート

あるデータベースから別のデータベースにリカバリ・カタログを移動するには、以前のデータベースからカタログをエクスポートし、新しいデータベースにインポートします。カタログをインポートできるのは、サポートされているバージョンのOracleデータベース・サーバーのみです。通常、カタログは、同じリリース以上のデータベースにインポートできます。

エクスポートは、Recovery Managerのリカバリ・カタログの論理バックアップとしても機能します。リカバリ・カタログ・データベースが破損した場合、エクスポートされたリカバリ・カタログ・データを別のデータベースに再インポートすることで、カタログを迅速に再構築できます。

この項の内容は、次のとおりです。

カタログ・データの移動時の考慮事項

リカバリ・カタログは、リカバリ・カタログ・スキーマを含んでいないスキーマのみにインポートします。すでにリカバリ・カタログ・スキーマを所有しているユーザーは、インポートされたリカバリ・カタログ・スキーマを所有できません。たとえば、ユーザーrmancatdbデータベースにリカバリ・カタログを所有している場合、そのカタログをcatdbからエクスポートしてcatdb2データベースにインポートするには、rmancatdb2にリカバリ・カタログを所有していない必要があります。catdb2に新しいリカバリ・カタログ所有者を作成するか、またはcatdb2の現行のユーザーrmanを削除して再作成する必要があります。リカバリ・カタログを既存のリカバリ・カタログにマージすることはできません。

リカバリ・カタログをプライマリ・データベースからエクスポートし、セカンダリ・データベースにインポートする基本的な手順を次に示します。

Oracleのエクスポート・ユーティリティの1つを使用して、プライマリ・データベースからカタログ・データをエクスポートします。「リカバリ・カタログのエクスポート」を参照してください。

セカンダリ・データベースにユーザーを作成し、必要な権限を付与します。「リカバリ・カタログ所有者の作成」を参照してください。

最初の手順で使用したエクスポート・ユーティリティに対応するインポート・ユーティリティを使用して、前述の手順で作成したスキーマにカタログ・データをインポートします。「リカバリ・カタログのインポート」を参照してください。

カタログをセカンダリ・データベースへインポートする前後には、CREATE CATALOGコマンドを実行しないでください。カタログ・データを新しいスキーマにインポートすることで、カタログを効率的にセカンダリ・データベースに作成できます。


注意:

2つの異なるリカバリ・カタログからエクスポートしたデータをインポートして、1つのカタログにマージすることはできません。複数のリカバリ・カタログ・スキーマのマージは、現在は実行不可能です。

リカバリ・カタログのエクスポート

この例では、従来のエクスポート・ユーティリティ(『Oracle Databaseユーティリティ』を参照)を使用して、リカバリ・カタログの論理エクスポートを実行します。 Data Pump Export Utilityに関連する概要および手順は、『Oracle Databaseユーティリティ』を参照してください。

リカバリ・カタログの論理エクスポートを実行する手順

次の手順を実行してから、オペレーティング・システムのコマンドラインでOracleのエクスポート・ユーティリティを実行します。

リカバリ・カタログ所有者として接続します。

OWNERオプションを指定します。

出力ファイルを指定します。

たとえば、catdbデータベースのカタログの所有者がrmanである場合、UNIXのコマンドラインで次のコマンドを発行して、カタログをcat.dmpファイルにエクスポートできます。

% exp rman/cat@catdb FILE=cat.dmp OWNER=rman

出力を調べて、エクスポートが正常に実行されたことを確認します。

Export terminated successfully without warnings.

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

この例では、従来のインポート・ユーティリティ(『Oracle Databaseユーティリティ』を参照)を使用して、リカバリ・カタログの論理エクスポートを実行します。 Data Pump Import Utilityに関連する概要および手順は、『Oracle Databaseユーティリティ』を参照してください。

リカバリ・カタログの論理インポートをコマンドラインから実行する手順

  1. 別のデータベースに新しいユーザーを作成します。リカバリ・カタログ・データベースに新しいユーザーを作成するための推奨SQL構文は、「リカバリ・カタログ所有者の作成」を参照してください。新しいユーザーに必要な権限を付与する必要があります。

    エクスポート・ファイルからカタログ・データをインポートします。次の手順を実行してから、コマンドラインでインポートを実行します。

    リカバリ・カタログの新しい所有者として接続します。

    FROMUSERパラメータを使用して、以前の所有者を指定します。

    TOUSERパラメータを使用して、新しい所有者を指定します。

    インポート・ファイルを指定します。

    たとえば、次のことを想定します。

    • prod1データベースのカタログの以前の所有者はrmanです。

    • 新しいリカバリ・カタログ・データベースcatdb2のユーザーはrman2です。

    • カタログのエクスポートを含むファイルはcat.dmpです。

  2. この場合に使用するコマンドは次のとおりです。

    % imp USERID=rman2/cat2@catdb2 FILE=cat.dmp FROMUSER=rman TOUSER=rman2
    

    インポートしたカタログ・データを使用して、ターゲット・データベースのリストアおよびリカバリを行います。

リカバリ・カタログの可用性の向上

本番システムで、カタログ・データベースの高可用性を維持する必要がある場合があります。たとえば、リカバリ・カタログに100個のターゲット・データベースを登録している場合です。プライマリ・カタログ・データベースが停止した場合に備えて、別のデータベースにセカンダリ・リカバリ・カタログを格納して冗長性を持たせることができます(図10-2を参照)。ターゲット・データベースは、セカンダリ・カタログに登録する必要があります。

この可用性向上の例では、プライマリ・カタログは通常どおりに定期バックアップ中に同期化されますが、セカンダリ・カタログはRESYNC CATALOGコマンドによって定期的に同期化されます。プライマリ・カタログ・データベースが停止した場合や定期メンテナンスが必要な場合、セカンダリ・カタログを再同期化して、新しいプライマリ・カタログとして一時的に使用できます。

図10-2 2つのリカバリ・カタログへの1つのターゲット・データベースの登録

図10-2の説明が続きます。
「図10-2 2つのリカバリ・カタログへの1つのターゲット・データベースの登録」の説明

リカバリ・カタログ・ビューの問合せ

LISTREPORTおよびSHOWコマンドを使用すると、制御ファイルおよびリカバリ・カタログのデータに簡単にアクセスできます。 また、リカバリ・カタログ・ビューから有用な情報を取得することもできます。リカバリ・カタログ・ビューは、カタログ・スキーマ内の、接頭辞RC_が付いたビューです。


参照:

リカバリ・カタログ・ビューの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

Recovery Managerは、ターゲット・データベースの制御ファイルからバックアップおよびリカバリのメタデータを取得し、リカバリ・カタログの表に格納します。リカバリ・カタログ・ビューは、これらの表から導出されます。リカバリ・カタログ・ビューは、ユーザーによる問合せに対して正規化または最適化されていません。

通常、リカバリ・カタログ・ビューは、Recovery Managerのレポート・コマンドほど簡単に使用できません。たとえば、Recovery Managerを起動してターゲット・データベースに接続した場合、LISTREPORTおよびSHOWコマンドを発行するのみでこのターゲット・データベースの情報を取得できます。同じリカバリ・カタログ内に10個の異なるターゲット・データベースを登録している場合、リカバリ・カタログ・ビューの問合せによって、カタログに登録されているすべてのデータベースのすべてのインカネーションの情報が表示されます。多くの場合、ビュー間で複雑な選択や結合を実行して、特定のデータベースおよびインカネーションに関する使用可能な情報を抽出する必要があります。

多くのカタログ・ビューには、対応する動的パフォーマンス・ビュー(V$ビュー)がデータベース・サーバー内に存在します。 たとえば、RC_BACKUP_PIECEV$BACKUP_PIECEに対応しています。リカバリ・カタログ・ビューと、対応するサーバー・ビューの主な違いは、各カタログ・ビューにはカタログに登録されているすべてのデータベースに関する情報が含まれ、データベース・サーバー・ビューにはそのデータベース・サーバーに関する情報のみが含まれることです。 RC_ビューと、対応するV$ビューでは、行を一意に識別するための主キーが異なります。

カタログ・ビュー内のデータベースの行の識別

多くのカタログ・ビューには、DB_KEY列およびDBINC_KEY列が含まれます。 各ターゲット・データベースは、主キー(DB_KEY列の値)またはDBID(32ビットの一意のデータベース識別子)によって一意に識別できます。 ターゲット・データベースの各インカネーションは、DBINC_KEY主キーによって一意に識別されます。ターゲット・データベースの特定のインカネーションに関するデータを問い合せる場合、前述の列を使用してデータベースを指定します。次に、任意の他のカタログ・ビューと結合して(結合できないビューもあります)、必要な情報を取得できます。

カタログ・ビュー内のデータベース・オブジェクトの行の識別

カタログ・ビューとV$ビューとの主な違いは、バックアップ・オブジェクトとリカバリ・オブジェクトに使用される一意の識別子の形式が異なることです。 たとえば、V$ARCHIVED_LOGなどの多くのV$ビューでは、RECID列とSTAMP列によって連結主キーが構成されます。対応するカタログ・ビューでは、導出された値が主キーとして使用され、この値は単一列に格納されます。 たとえば、RC_ARCHIVED_LOGの主キーはAL_KEY列です。 AL_KEY列値は、LISTコマンドの出力に表示される主キーです。

カタログ・ビューへのターゲットDB_KEY値またはDBID値の問合せ

DB_KEY値は、ターゲット・データベースの主キーであり、リカバリ・カタログでのみ使用されます。 DB_KEYを取得する最も簡単な方法は、ターゲット・データベースのDBIDを使用することです。このDBIDは、Recovery Managerをターゲット・データベースに接続するたびに表示されます。DBIDは、すべてのOracleデータベースに指定された一意のシステム定義番号で、Recovery Managerのリカバリ・カタログ内に登録されているデータベースの識別に使用されます。

リカバリ・カタログに登録されたいずれかのターゲット・データベースに関する情報を取得すると想定します。 このデータベースのDBIDは、Recovery Managerをデータベースに接続したときに表示される出力を参照するか、V$RMAN_OUTPUTを問い合せるか、または次に示すとおりV$DATABASEビューを問い合せることによって簡単に確認できます。

SELECT DBID
FROM V$DATABASE;

DBID
---------
598368217

次に、次の問合せを実行して、ターゲット・データベースのDB_KEYを取得できます。ここで、dbid_of_targetは、前述の手順で取得したDBIDです。

SELECT DB_KEY
FROM RC_DATABASE
WHERE DBID = dbid_of_target;

ターゲット・データベースの現行のインカネーションに関する情報を取得するには、ターゲット・データベースのDB_KEY値を指定し、WHERE条件を使用してCURRENT_INCARNATION列値がYESである条件を指定して、RC_DATABASE_INCARNATIONとの結合操作を実行します。 たとえば、DB_KEY値を1に指定して、ターゲット・データベースの現行のインカネーションに設定されたバックアップ・セットに関する情報を取得するには、次のスクリプトを実行します。

SELECT BS_KEY, BACKUP_TYPE, COMPLETION_TIME
  FROM RC_DATABASE_INCARNATION i, RC_BACKUP_SET b
  WHERE i.DB_KEY = 1
  AND i.DB_KEY = b.DB_KEY
  AND i.CURRENT_INCARNATION = 'YES';

データベースの指定にDB_NAME列を使用するのは、同じDB_NAMEが付いた複数のデータベースがリカバリ・カタログに登録されていない場合のみです。Recovery Managerでは、複数のデータベースを同じデータベース名で登録できますが、DBID値は異なる必要があります。 たとえば、DB_NAME値がprod1で、それぞれ異なるDBIDを持つ10個のデータベースを登録できます。 DBIDはメタデータ内での各データベースの一意の識別子であるため、この値を使用してDB_KEYを取得し、次にDB_KEYを使用してデータベースを一意に識別します。

RC_BACKUP_FILESおよびDBMS_RCVMAN.SETDATABASEの使用

ビューRC_BACKUP_FILESに対しては、リカバリ・カタログに登録されているデータベースのすべてのバックアップに関する情報を問い合せることができます。 ただし、RC_BACKUP_FILESを問い合せる前に、次の例に示すように、リカバリ・カタログに登録されているいずれかのデータベースのDBIDを指定して、DBMS_RCVMAN.SETDATABASEをコールする必要があります。

SQL>  CALL DBMS_RCVMAN.SETDATABASE(null,null,null,2283997583,null);

4番目のパラメータは、リカバリ・カタログに登録されているデータベースのDBIDにする必要があります。 その他のパラメータは、すべてNULLにする必要があります。


参照:

  • RC_BACKUP_FILESビューの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
  • データベースのDBIDを確認する方法の詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。


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

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


参照:

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

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

SQL*Plusを起動し、カタログ所有者としてリカバリ・カタログ・データベースに接続します。たとえば、次のように入力します。

% sqlplus rman/cat@catdb

RCVER表を問い合せてスキーマ・バージョンを取得します。次に、コマンドと出力の例を示します。

SELECT *
FROM rcver;

VERSION
------------
09.02.00

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

VERSION
------------
08.01.07
09.00.01
09.02.00

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

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

Recovery Managerクライアントで要求されるバージョンより古いリカバリ・カタログを使用している場合、そのカタログをアップグレードする必要があります。たとえば、リリース8.1のRecovery Managerクライアントでリリース8.0のリカバリ・カタログを使用する場合、そのカタログをアップグレードする必要があります。

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

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

  1. 新しいリカバリ・カタログ・スキーマをインストールするには、リカバリ・カタログ・ユーザーがTYPE権限を持っている必要があります。

    sqlplus> connect sys/oracle@catdb as sysdba;
    sqlplus> grant TYPE to rman;
    

    Recovery Managerを使用してターゲット・データベースおよびリカバリ・カタログ・データベースに接続します。たとえば、次のように入力します。

    % rman TARGET / CATALOG rman/cat@catdb
    
    connected to recovery catalog database
    PL/SQL package rcat.DBMS_RCVCAT version 08.00.04 in RCVCAT database
    is too old
    

    UPGRADE CATALOGコマンドを発行します。

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

    確認のために、再度UPDATE CATALOGコマンドを入力します。

    UPGRADE CATALOG;
    
    recovery catalog upgraded to version 09.02.00
    DBMS_RCVMAN package upgraded to version 09.02.00
    DBMS_RCVCAT package upgraded to version 09.02.00
    

    参照:

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

    • リカバリ・カタログの互換性の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

    • 互換性および移行の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。

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

リカバリ・カタログを保持しない場合、表領域からリカバリ・カタログ・スキーマを削除できます。DROP CATALOGコマンドを使用すると、リカバリ・カタログからすべての情報を削除できます。そのため、リカバリ・カタログ・スキーマのバックアップが存在しない場合、このカタログによって管理されているすべてのターゲット・データベースのバックアップが使用できなくなる場合があります。(ターゲット・データベースの制御ファイルには、最新のバックアップのレコードが残ります。)

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

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

Recovery Managerを使用してターゲット・データベースおよびリカバリ・カタログ・データベースに接続します。

% rman TARGET / CATALOG rman/cat@catdb

確認のために、DROP CATALOGコマンドを2回発行します。

DROP CATALOG;

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

DROP CATALOG;

注意:

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


参照:

DROP CATALOGコマンドの構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。カタログからデータベースを登録解除する方法は、「リカバリ・カタログからのターゲット・データベースの登録の解除」を参照してください。