11g リリース1（11.1）
E05700-03
 目次 |
 索引 |
| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース1（11.1） E05700-03 |
|
この章では、Recovery Managerリカバリ・カタログを管理する方法について説明します。このカタログは、1つ以上のターゲット・データベースのRecovery Managerリポジトリ・データが含まれているデータベース・スキーマです。この章の内容は、次のとおりです。
参照:
この項では、リカバリ・カタログの管理に関連する基本的な概念について説明します。
リカバリ・カタログとは、1つ以上のOracle Databaseに関するメタデータを格納するためにRecovery Managerで使用されるデータベース・スキーマのことです。通常、このカタログは専用のデータベースに格納します。リカバリ・カタログには、次のメリットがあります。
一部のRecovery Manager機能は、リカバリ・カタログを使用する場合にのみ機能します。たとえば、リカバリ・カタログにはRecovery Managerスクリプトを格納することができます。ストアド・スクリプトの主なメリットは、ターゲット・データベースおよびリカバリ・カタログに接続可能なRecovery Managerクライアントで使用できることです。コマンド・ファイルは、それらが格納されているファイル・システムにRecovery Managerクライアントがアクセスできる場合にのみ使用できます。
Data Guard環境でRecovery Managerを使用する場合は、リカバリ・カタログが必要です。すべてのプライマリ・データベースおよびスタンバイ・データベースのバックアップ・メタデータを格納すると、カタログによって、バックアップ・タスクを1つのスタンバイ・データベースにオフロードし、その環境内のその他のデータベースにバックアップをリストアできます。
リカバリ・カタログには、登録されている各ターゲット・データベースのRecovery Manager操作に関するメタデータが含まれています。Recovery Managerは、リカバリ・カタログに接続されると、カタログから排他的にそのメタデータを取得します。このカタログには、次のタイプのメタデータが含まれています。
Recovery Managerで使用するために、リカバリ・カタログにデータベースを記載することを登録と呼びます。すべてのターゲット・データベースを環境内の単一のリカバリ・カタログに登録することをお薦めします。たとえば、データベースprod1、prod2およびprod3を、データベースcatdbのcatownerが所有する1つのカタログに登録できます。
集中化されたリカバリ・カタログ（ベース・リカバリ・カタログとも呼ばれる）の所有者は、他のデータベース・ユーザーに対してカタログへの制限付きアクセス権限を付与および取り消すことができます。制限付きユーザーは、それぞれ仮想プライベート・カタログと呼ばれる独自のメタデータへの完全な読取り/書込み権限を持っています。Recovery Managerメタデータは、仮想プライベート・カタログ所有者のスキーマに格納されます。ベース・リカバリ・カタログの所有者は、各仮想プライベート・カタログ・ユーザーがアクセスできるオブジェクトを決定します。
リカバリ・カタログは、様々なバージョンのOracle Databaseを使用している環境、または使用してきた環境で使用できます。その結果、様々なバージョンのRecovery Managerクライアント、リカバリ・カタログ・データベース、リカバリ・カタログ・スキーマおよびターゲット・データベースが環境内に存在する可能性があります。複数のリカバリ・カタログ・スキーマを1つにマージする方法については、「リカバリ・カタログのインポートおよび移動」を参照してください。
バックアップ、リストア、クロスチェックなどのRecovery Manager操作では、Recovery Managerによって常に最初に制御ファイルが更新され、次にメタデータがリカバリ・カタログに伝播されます。マウントされた制御ファイルからリカバリ・カタログへのメタデータのこのフローは、リカバリ・カタログの再同期化と呼ばれます。これによって、Recovery Managerが制御ファイルから取得するメタデータが現行のものになります。
ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRecovery Managerコマンドの管理に使用できます。このスクリプトは、ファイル・システムではなくリカバリ・カタログに格納されます。
ローカル・ストアド・スクリプトは、作成時にRecovery Managerが接続していたターゲット・データベースに関連付けられます。スクリプトは、関連付けられたターゲット・データベースに接続している場合にのみ実行できます。グローバル・ストアド・スクリプトは、リカバリ・カタログに登録されているすべてのデータベースに対して実行できます。仮想プライベート・カタログ・ユーザーは、グローバル・スクリプトへの読取り専用アクセス権限を持っています。グローバル・スクリプトの作成または更新は、ベース・リカバリ・カタログへの接続中に実行する必要があります。
「Data Guard環境でのRecovery Manager」で説明されているように、Data Guard環境内のすべての物理データベース（プライマリ・データベースとスタンバイ・データベースの両方）のRecovery Managerメタデータを管理するには、リカバリ・カタログを使用する必要があります。Recovery Managerは、Data Guard環境の実情の単一のソースとしてリカバリ・カタログを使用します。
Recovery Managerは、逆再同期化で、リカバリ・カタログを使用してプライマリまたはスタンバイ制御ファイルを更新できます。この場合、メタデータのフローの方向は、制御ファイルからカタログではなく、カタログから制御ファイルになります。Recovery Managerは、再同期化が必要なほぼすべての場合に、再同期化を自動的に実行します。そのため、RESYNCコマンドを使用して手動で再同期化する必要がある機会はあまり多くありません。
リカバリ・カタログをRecovery Managerで使用できるように設定する基本手順は次のとおりです。
このタスクの実行方法については、「リカバリ・カタログの作成」を参照してください。
この手順によって、Recovery Managerはターゲット・データベースに関するメタデータをリカバリ・カタログに格納できます。このタスクについては、「リカバリ・カタログへのデータベースの登録」を参照してください。
このタスクの実行方法については、「リカバリ・カタログへのバックアップの追加」を参照してください。
このタスクの実行方法については、「仮想プライベート・カタログの作成および管理」を参照してください。
カタログをバックアップおよびリカバリする方法および可用性を向上させる方法については、「リカバリ・カタログの保護」を参照してください。
この章の残りでは、リカバリ・カタログの使用開始後、そのリカバリ・カタログを管理する方法について説明します。次のタスクを実行できます。
LISTおよびREPORTコマンドは、リカバリ・カタログを使用しているかどうかに関係なく使用できます。リカバリ・カタログ内の固定ビューによってRecovery Manager操作に関してレポートする方法については、「リカバリ・カタログ・ビューの問合せ」を参照してください。
リカバリ・カタログをメンテナンスしない場合は、「リカバリ・カタログの削除」を参照してください。
この項では、リカバリ・カタログ作成時の各フェーズについて説明します。この項の内容は、次のとおりです。
Recovery Managerでリカバリ・カタログを使用する場合、リカバリ・カタログ・スキーマを保持する必要があります。リカバリ・カタログは、スキーマのデフォルト表領域に格納されます。SYSはリカバリ・カタログ所有者に設定できないことに注意してください。
リカバリ・カタログ・スキーマのインストールに使用するデータベースを決定し、そのデータベースのバックアップ方法も決定します。また、カタログ・データベースをARCHIVELOGモードで操作するかどうかを決定します。カタログ・データベースはARCHIVELOGモードで操作することをお薦めします。
カタログ・スキーマによって使用される領域を割り当てる必要があります。リカバリ・カタログ・スキーマのサイズは、カタログによって監視されるデータベースの数によって異なります。スキーマは、アーカイブREDOログ・ファイルおよび各データベースのバックアップの増加とともに増大します。カタログに格納されているRecovery Managerストアド・スクリプトを使用する場合は、これらのスクリプトに対して領域を割り当てる必要があります。
たとえば、trgtデータベースにファイルが100個あり、このデータベースを1日に1回バックアップして、それぞれ1つのバックアップ・ピースを含む50個のバックアップ・セットを作成すると想定します。バックアップ・ピース表内の各行が領域を最大限に使用すると想定すると、1回の日次バックアップによってリカバリ・カタログ内で使用される領域は170KB未満です。この日次バックアップを1年間行うと、この期間中に使用される合計記憶域は約62MBです。これとほぼ同じ量の記憶域がアーカイブ・ログに使用されると想定されます。したがって、最悪の場合はメタデータの格納に1年間で約120MBが必要になります。バックアップ・ピースの行領域の一部のみを使用する通常の状況の場合、現実的な値は年間15MBです。
リカバリ・カタログに複数のデータベースの登録を予定している場合、前述の計算に従って各データベースに必要な領域を足し、リカバリ・カタログ・スキーマのデフォルト表領域の合計サイズを算出してください。
リカバリ・カタログを既存のデータベース内に作成する場合、デフォルト表領域を保持するために十分な空き領域をリカバリ・カタログ・スキーマに追加します。リカバリ・カタログを格納するための新しいデータベースを作成する場合、リカバリ・カタログ・スキーマ自体の領域に加えて、次に示すリカバリ・カタログ・データベース内の他のファイル用の領域も考慮します。
リカバリ・カタログ・データベース内の領域の大部分は、SYSTEM表領域、一時表領域、UNDO表領域などの表領域をサポートするために使用されます。表12-1に、一般的な領域要件を示します。
| 領域タイプ | 領域要件 |
|---|---|
|
|
90MB |
|
一時表領域 |
5MB |
|
ロールバック表領域またはUNDO表領域 |
5MB |
|
リカバリ・カタログ表領域 |
リカバリ・カタログに登録されたデータベースごとに15MB |
|
オンラインREDOログ |
ログごとに1MB（3グループ、各グループに2メンバー） |
リカバリ・カタログ・データベースを選択して必要な領域を作成した後、リカバリ・カタログの所有者を作成し、そのユーザーに必要な権限を付与します。後続の項に示す手順では、次の状況を想定しています。
SYSは、catdbリカバリ・カタログ・データベースに対するSYSDBA権限を持っています。
catdbリカバリ・カタログ・データベース内のtoolsという表領域にリカバリ・カタログが格納されています。Recovery Managerの予約語を表領域名として使用する場合、その語を引用符で囲み、大文字を使用する必要があります。（Recovery Managerの予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 を参照してください。）
tempという表領域が、リカバリ・カタログ・データベース内に存在します。
catdbです。
CREATE USER rman IDENTIFIED BY password TEMPORARY TABLESPACE temp DEFAULT TABLESPACE tools QUOTA UNLIMITED ON tools;
RECOVERY_CATALOG_OWNERロールを付与します。このロールによって、リカバリ・カタログのメンテナンスおよび問合せに必要なすべての権限がユーザーに付与されます。
GRANT RECOVERY_CATALOG_OWNER TO rman;
カタログ所有者の作成後、Recovery ManagerのCREATE CATALOGコマンドを使用してカタログ表を作成します。このコマンドを実行すると、カタログ所有者のデフォルト表領域内にカタログが作成されます。
CREATE CATALOGコマンドを実行してカタログを作成します。カタログの作成には数分かかります。カタログ表領域がこのユーザーのデフォルト表領域の場合、次のコマンドを実行できます。
RMAN> CREATE CATALOG;
CREATE CATALOGコマンドでカタログの表領域名を指定できます。たとえば、次のように入力します。
RMAN> CREATE CATALOG TABLESPACE cat_tbs;
SQL> SELECT TABLE_NAME FROM USER_TABLES;
この項では、リカバリ・カタログでターゲット・データベース・レコードをメンテナンスする方法について説明します。この章の内容は、次のとおりです。
リカバリ・カタログにターゲット・データベースを記載することを登録と呼びます。ターゲット・データベースがリカバリ・カタログに登録されていない場合、Recovery Managerは、カタログを使用して操作に関するメタデータをそのデータベースに格納できません。登録されていないデータベースでも、Recovery Manager操作を実行することはできます。Recovery Managerは、そのメタデータを常にターゲット・データベースの制御ファイルに格納するためです。
Data Guard環境でリカバリ・カタログを使用していない場合は、REGISTERコマンドを使用して各データベースを登録します。各データベースには、一意のDBIDが必要です。DUPLICATEコマンドまたはSQLのCREATE DATABASE文を使用すると、データベースに一意のDBIDが自動的に割り当てられます。その他の方法でデータベースを作成すると、コピーされたデータベースのDBIDとソース・データベースのDBIDが同じになる場合があります。ソース・データベースとコピー・データベースを同じカタログに登録できるように、DBNEWIDユーティリティを使用してDBIDを変更できます。
UNREGISTERコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。
Data Guard環境では、プライマリ・データベースとスタンバイ・データベースは同じDBIDおよびデータベース名を共有します。Data Guard環境のデータベースをリカバリ・カタログに登録できるようにするには、各データベースに異なるDB_UNIQUE_NAME値が必要です。データベースのDB_UNIQUE_NAMEパラメータは、その初期化パラメータ・ファイルに設定されています。
Data Guard環境でRecovery Managerを使用する場合は、プライマリ・データベースに対してのみREGISTER DATABASEコマンドを使用できます。次の方法を使用すると、スタンバイ・データベースをリカバリ・カタログに登録できます。
TARGETとしてスタンバイ・データベースに接続すると、Recovery Managerによってデータベースがリカバリ・カタログに自動的に登録されます。
CONFIGURE DB_UNIQUE_NAMEコマンドを実行する場合、Recovery Managerは、対応するプライマリ・データベースが登録されているかぎり、このスタンバイ・データベースを自動的に登録します。
参照:
DUPLICATE構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
DBNEWIDユーティリティを使用してDBIDを変更する方法については、『Oracle Databaseユーティリティ』を参照してください。
ターゲット・データベースでリカバリ・カタログを使用するには、まずそのターゲット・データベースをリカバリ・カタログに登録します。Data Guard環境でカタログを使用する場合は、この方法でプライマリ・データベースのみを登録できます。
次の手順を実行します。
たとえば、ネット・サービス名catdbを使用してカタログ・データベースにユーザーrman（カタログ・スキーマ所有者）として接続するには、次のコマンドを実行します。
% rman TARGET / CATALOG rman@catdb
STARTUP MOUNT;
REGISTER DATABASE;
Recovery Managerは、カタログ表内に、ターゲット・データベースに関する情報を格納する行を作成し、ターゲット・データベースに関連するすべてのデータを制御ファイルからカタログにコピーし、カタログと制御ファイルを同期化します。
REPORT SCHEMAを実行し、正常に登録されたことを確認します。
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コマンドを使用して、それらをリカバリ・カタログに追加できます。リカバリ・カタログを使用する場合、制御ファイルからエージ・アウトされたバックアップをカタログに追加すると、リストア操作中に、その古いバックアップが使用されます。次のコマンドは、この方法を示しています。
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/';
Recovery Managerによって、Recovery Managerリポジトリに追加されるファイルが表示され、それらのバックアップが追加される前に確認するように求められます。CATALOG START WITHで接頭辞を指定する場合は注意が必要です。Recovery Managerは、ディスク上で、指定された接頭辞が付いたすべてのパスのすべてのファイルをスキャンします。接頭辞は、通常のディレクトリ名ではありません。不適切な接頭辞を使用すると、不適切なファイル・セットがカタログに追加される場合があります。
たとえば、/disk1/backups、/disk1/backups-year2003、/disk1/backupsets、/disk1/backupsets/testなどの一連のディレクトリにバックアップ・ファイルが含まれているとします。次のコマンドを実行すると、これらのすべてのディレクトリ内のすべてのファイルがカタログに追加されます。/disk1/backupsが、これらのすべてのディレクトリへのパスの接頭辞であるためです。
CATALOG START WITH '/disk1/backups';
/disk1/backupsディレクトリ内のバックアップのみをカタログに追加するには、次のコマンドが適切です。
CATALOG START WITH '/disk1/backups/';
すべてのデータベースの集中Recovery Managerリポジトリとして機能する1つのリカバリ・カタログを作成することをお薦めします。このリカバリ・カタログは、全体としてベース・リカバリ・カタログとも呼ばれます。このベース・カタログに、0（ゼロ）個以上の仮想プライベート・カタログを含めることができます。仮想プライベート・カタログは、ベース・リカバリ・カタログを参照するシノニムおよびビューのセットです。
デフォルトでは、ベース・リカバリ・カタログの所有者のみがそのメタデータへのアクセス権限を持っています。ベース・リカバリ・カタログの所有者は、Recovery ManagerのGRANTコマンドを使用して、リカバリ・カタログへの制限付きアクセス権限を他のデータベース・ユーザーに付与できます。ベース・リカバリ・カタログの所有者は、リカバリ・カタログを共有できるデータベース・ユーザーおよびアクセスできるデータベースを決定します。
カタログ・ユーザーに制限付きアクセス権限を付与する場合は、そのユーザーにそのユーザー独自のRecovery Managerメタデータ（仮想プライベート・カタログ）への完全な読取り/書込み権限を付与します。仮想プライベート・カタログ所有者は、ローカル・ストアド・スクリプトは作成できますが、グローバル・ストアド・スクリプトに対して持っているアクセス権限は読取りアクセス権限のみであることに注意してください。仮想プライベート・カタログを構成するビューおよびシノニムのセットは、仮想プライベート・カタログ所有者のスキーマに格納されます。仮想プライベート・カタログのメカニズムは、リカバリ・カタログ・スキーマ自体に存在します。セキュリティは、Recovery Manager実行可能ファイルではなく、リカバリ・カタログ・データベースによって提供されます。
仮想プライベート・カタログを作成する基本的な手順は次のとおりです。
このタスクについては、「仮想プライベート・カタログ所有者の作成および権限の付与」を参照してください。
このタスクについては、「仮想プライベート・カタログの作成」を参照してください。
仮想プライベート・カタログの作成後に、必要に応じてカタログ・アクセス権限を取り消すことができます。このタスクについては、「仮想プライベート・カタログ所有者からの権限の取消し」を参照してください。仮想プライベート・カタログを削除する方法については、「仮想プライベート・カタログの削除」を参照してください。
リカバリ・カタログが仮想プライベート・カタログの場合、これに接続しているRecovery Managerクライアントは、パッチ・レベル10.1.0.6または10.2.0.3である必要があります。Oracle9i のRecovery Managerクライアントは、仮想プライベート・カタログに接続できません。ベース・カタログに仮想プライベート・カタログ・ユーザーが含まれている場合でも、Oracle Database 11g のベース・リカバリ・カタログへのRecovery Managerクライアントの接続は、このバージョン制限の影響を受けません。
この項では、ベース・リカバリ・カタログは作成済であると想定しています。
データベースprod1、prod2およびprod3がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログを所有するデータベース・ユーザーはcatownerです。データベース・ユーザーvpc1を作成し、このユーザーにprod1およびprod2のみへのアクセス権限を付与します。デフォルトでは、仮想プライベート・カタログ所有者にベース・リカバリ・カタログへのアクセス権限はありません。
たとえば、カタログを所有するデータベース・ユーザーvpc1を作成する場合は、次のコマンドを実行します（passwordはユーザー定義のパスワードに置き換えます）。
SQL> CREATE USER vpc1 IDENTIFIED BY password 2 DEFAULT TABLESPACE vpcusers 3 QUOTA UNLIMITED ON vpcusers;
RECOVERY_CATALOG_OWNERロールを付与し、SQL*Plusを終了します。次の例では、ユーザーvpc1にロールを付与します。
SQL> GRANT recovery_catalog_owner TO vpc1; SQL> EXIT;
次の例では、catownerとしてベース・リカバリ・カタログに接続します。
% rman RMAN> CONNECT CATALOG catowner@catdb; recovery catalog database Password: password connected to recovery catalog database
次の例では、prod1およびprod2（prod3は対象外）に関するメタデータへのアクセス権限をユーザーvpc1に付与します。
RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1; RMAN> GRANT CATALOG FOR DATABASE prod2 TO vpc1;
データベース名ではなくDBIDを使用することもできます。仮想プライベート・カタログ・ユーザーには、リカバリ・カタログに登録されている他のデータベースに関するメタデータへのアクセス権限はありません。
新しいターゲット・データベースをリカバリ・カタログに登録する機能をユーザーに付与することもできます。たとえば、次のように入力します。
RMAN> GRANT REGISTER DATABASE TO vpc1;
この項では、仮想プライベート・カタログ所有者にRECOVERY_CATALOG_OWNERデータベース・ロールが付与されていると想定しています。また、ベース・リカバリ・カタログ所有者がGRANTコマンドを使用して、ベース・リカバリ・カタログ内のメタデータへのアクセス権限を仮想プライベート・カタログ所有者に付与しています。
次の例では、vpc1としてリカバリ・カタログに接続します。
% rman RMAN> CONNECT CATALOG vpc1@catdb;
次のコマンドによって仮想プライベート・カタログが作成されます。
RMAN> CREATE VIRTUAL CATALOG;
SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;
この項では、仮想プライベート・カタログをすでに作成していると想定しています。
2つのデータベースprod1およびprod2がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログの所有者として、vpc1ユーザーにprod1へのアクセス権限を付与しています。また、このユーザーには、仮想プライベート・カタログにデータベースを登録する権限も付与しています。ここで、vpc1から権限を取り消します。
次の例では、catownerとしてリカバリ・カタログに接続します。
% rman RMAN> CONNECT CATALOG catowner@catdb;
次のコマンドによって、prod1に関するメタデータへのアクセス権限が仮想プライベート・カタログ所有者vpc1から取り消されます。
REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
データベース名ではなくDBIDを指定することもできます。vpc1は、付与されているその他のすべてのカタログ権限を保持します。
新しいターゲット・データベースをリカバリ・カタログに登録する権限を取り消すこともできます。たとえば、次のように入力します。
REVOKE REGISTER DATABASE FROM vpc1;
この項では、仮想プライベート・カタログをすでに作成しており、この時点でこれを削除すると想定しています。仮想プライベート・カタログを削除する場合、ベース・リカバリ・カタログ自体は削除しません。ベース・リカバリ・カタログを参照するシノニムおよびビューのみを削除します。
次の例では、ユーザーvpc1としてリカバリ・カタログに接続します。
% rman RMAN> CONNECT CATALOG vpc1@catdb;
Oracle Database 11g 以上のRecovery Manager実行可能ファイルを使用している場合は、DROP CATALOGコマンドを使用して仮想プライベート・カタログを削除します。
RMAN> DROP CATALOG;
Oracle Database 10g 以前のRecovery Manager実行可能ファイルを使用している場合は、DROP CATALOGコマンドは使用できません。かわりに、仮想プライベート・カタログ・ユーザーとしてSQL*Plusをカタログ・データベースに接続してから、次のPL/SQLプロシージャを実行します（base_catalog_ownerは、ベース・リカバリ・カタログを所有するデータベース・ユーザーです）。
SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.DELETE_VIRTUAL_CATALOG;
バックアップおよびリカバリ計画には、リカバリ・カタログ・データベースも含める必要があります。リカバリ・カタログをバックアップしないと、ディスク障害が発生してリカバリ・カタログ・データベースが破損した場合、カタログ内のメタデータが消失する場合があります。リカバリ・カタログの内容がない場合は、その他のデータベースのリカバリがより困難になる可能性があります。
1つのリカバリ・カタログには、複数のターゲット・データベースに関するメタデータを格納できます。したがって、リカバリ・カタログが消失すると、重大な問題が発生する可能性があります。リカバリ・カタログは、頻繁にバックアップしてください。この項では、リカバリ・カタログを保護する計画を作成するための一般的なガイドラインについて説明します。
リカバリ・カタログ・データベースは他のデータベースと同様のデータベースであり、バックアップおよびリカバリ計画に含める必要があります。リカバリ・カタログは、データベースの他の部分と同様にバックアップして保護してください。リカバリ・カタログ・データベースのバックアップは、全体的なバックアップおよびリカバリの一環として計画する必要があります。
リカバリ・カタログのバックアップは、ターゲット・データベースのバックアップと同じ頻度で行います。たとえば、ターゲット・データベース全体のバックアップを週1回行う場合、ターゲット・データベースのバックアップ後にリカバリ・カタログをバックアップします。リカバリ・カタログのこのバックアップは、障害リカバリに役立ちます。制御ファイルの自動バックアップを使用してリカバリ・カタログ・データベースをリストアする必要がある場合も、リストアしたリカバリ・カタログ・データベース内の完全なバックアップ・レコードを使用すると、ターゲット・データベースをリストアできます。
リカバリ・カタログ・データベースのバックアップは、Recovery Managerを使用して実行できます。図12-1に示すように、Recovery Managerのリポジトリがカタログ・データベースの制御ファイルになるように、NOCATALOGオプションを指定してRecovery Managerを起動します。
Recovery Managerを使用したリカバリ・カタログ・データベースのバックアップを計画する場合、次のガイドラインに従います。
ARCHIVELOGモードで実行します。
REDUNDANCY値を1より大きい値に設定します。
BACKUP DATABASE PLUS ARCHIVELOGを、使用可能な場合はメディア・マネージャに、メディア・マネージャが使用不可の場合はディスクのみに定期的に実行します。
ONに設定します。
この方法では、制御ファイルの自動バックアップ機能によって、この機能が使用可能なかぎり確実にリカバリ・カタログ・データベースがリカバリされます。
リカバリ・カタログは、そのカタログが保護するデータとは別の場所に格納されている場合にのみ有効です。そのため、データベースのRecovery Managerリポジトリを含むリカバリ・カタログは、ターゲット・データベースと同じデータベースには格納しないでください。また、カタログ・データベースはターゲット・データベースと同じディスクに格納しないでください。
データの分離をお薦めする理由を説明するために、データベースprod1のカタログをprod1に格納したとします。prod1にメディア全体の障害が発生したときに、prod1のリカバリ・カタログもprod1に格納されていた場合、データベースが消失すると、リカバリ・カタログも同様に消失します。この場合の対応策は1つのみです。リカバリ・カタログに格納されている情報を使用せずに、prod1の制御ファイルの自動バックアップをリストアして使用して、データベースのリストアおよびリカバリを実行する必要があります。
データ・ポンプ・エクスポート・ユーティリティを使用してRecovery Managerリカバリ・カタログの論理バックアップを作成しておくと、物理バックアップの有効な補助バックアップとなります。リカバリ・カタログ・データベースが破損した場合、データ・ポンプ・インポートを使用して、エクスポートされたリカバリ・カタログ・データを別のデータベースに再インポートすることで、カタログを迅速に再構築できます。
リカバリ・カタログ・データベースのリストアおよびリカバリは、Recovery Managerを使用して他のデータベースをリストアおよびリカバリする場合とほぼ同様です。リカバリ・カタログ・データベースの制御ファイルおよびサーバー・パラメータ・ファイルを自動バックアップからリストアし、その後、データベースの残りの部分のリストアおよび完全リカバリを実行できます。複数のリカバリ・カタログを使用している場合、別のリカバリ・カタログを使用して、このリカバリ・カタログ・データベースのバックアップに関するメタデータを記録することもできます。
通常のOracleのリカバリ手順によるリカバリ・カタログ・データベースのリカバリが実行不可能である場合は、カタログを再作成する必要があります。最悪の場合の例を次に示します。
欠落しているリカバリ・カタログの内容を部分的に再作成するには、次の方法があります。
RESYNC CATALOGコマンドを使用して、ターゲット・データベースの制御ファイルまたは制御ファイルのコピーからのRecovery Managerリポジトリ情報でリカバリ・カタログを更新します。制御ファイルからエージ・アウトされた制御ファイル・レコードに含まれているメタデータは消失することに注意してください。
CATALOG START WITH ... コマンドを発行して、使用可能なバックアップをカタログに再度追加します。
この最悪の状況が発生する可能性を最小限に抑えるには、バックアップ計画に少なくともリカバリ・カタログのバックアップを含める必要があります。この方法については、「リカバリ・カタログのバックアップ」を参照してください。
「ストアド・スクリプト」で説明するように、リカバリ・カタログにスクリプトを格納できます。この項では、ストアド・スクリプトを作成および管理する方法について説明します。
ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRecovery Managerコマンドの管理に使用できます。このスクリプトは、ファイル・システムではなくリカバリ・カタログに格納されます。
ストアド・スクリプトには、ローカルとグローバルの2種類があります。ローカル・スクリプトは、作成時にRecovery Managerが接続していたターゲット・データベースに関連付けられます。このスクリプトは、関連付けられたターゲット・データベースに接続している場合にのみ実行できます。グローバル・ストアド・スクリプトは、Recovery Managerクライアントがリカバリ・カタログおよびターゲット・データベースに接続している場合、リカバリ・カタログに登録されたすべてのデータベースに対して実行できます。
CREATE SCRIPTコマンドの大カッコ内で使用できるコマンドは、RUNブロック内でサポートされているコマンドと同じです。RUNコマンド内で有効なコマンドは、ストアド・スクリプトで使用できます。RUN、@および@@コマンドは、ストアド・スクリプト内で有効ではありません。
スクリプト名を指定する場合、ストアド・スクリプト名を引用符で囲むことはできますが、必須ではありません。ただし、名前が数値で始まる場合やRecovery Managerの予約語である場合、その名前をストアド・スクリプト名として使用するには、引用符で囲む必要があります。ストアド・スクリプトには、英字以外の文字で始まる名前、またはRecovery Managerの予約語と同じ名前を付けないことをお薦めします。
グローバル・ストアド・スクリプトとローカル・ストアド・スクリプトが混同されないように、ネーミング規則を使用することをお薦めします。EXECUTE SCRIPT、DELETE SCRIPTおよびPRINT SCRIPTコマンドで引数として渡されたスクリプト名が、接続しているターゲット・インスタンス用に定義されたスクリプトの名前ではない場合、Recovery Managerは、指定した名前が付いたグローバル・スクリプトを検索します。たとえば、リカバリ・カタログにglobal_backupという名前のグローバル・スクリプトが存在し、ターゲット・データベース用に定義されたglobal_backupというローカル・ストアド・スクリプトが存在しない場合に次のコマンドを実行すると、このグローバル・スクリプトは削除されます。
DELETE SCRIPT global_backup;
ストアド・スクリプト（グローバル・スクリプトの場合も）に関連するコマンドを使用するには、リカバリ・カタログとターゲット・データベース・インスタンスの両方に接続する必要があることに注意してください。
CREATE SCRIPTコマンドを使用すると、ストアド・スクリプトを作成できます。GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在していない必要があります。GLOBALを指定しない場合は、同じターゲット・データベースに対して同じ名前のローカル・スクリプトが存在していない必要があります。また、REPLACE SCRIPTを使用すると、新しいスクリプトの作成または既存のスクリプトの更新を行うこともできます。
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';
エラーが表示されていない場合、Recovery Managerは、スクリプトを正常に作成し、リカバリ・カタログに格納しています。
ストアド・スクリプトを更新するには、REPLACE SCRIPTコマンドを使用します。ローカル・スクリプトを置き換える場合は、スクリプトの作成時に接続していたターゲット・データベースに接続する必要があります。スクリプトが存在しない場合、Recovery Managerによってスクリプトが作成されます。
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';
ストアド・スクリプトを実行するには、EXECUTE SCRIPTコマンドを使用します。GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在している必要があります。存在していない場合、Recovery ManagerはエラーRMAN-06004を戻します。GLOBALを指定しない場合、Recovery Managerは、現在のターゲット・データベースに対して定義されたローカル・ストアド・スクリプトを検索します。この名前のローカル・スクリプトが検出されなかった場合、Recovery Managerは、同じ名前でグローバル・スクリプトを検索し、検出された場合は実行します。
SHOWを使用して構成済のチャネルを確認します。スクリプトは、実行時に構成されていた自動チャネルを使用します。構成済のチャネルを変更する必要がある場合、スクリプトにALLOCATE CHANNELを指定します。RUNブロックが使用されているため、スクリプト内のあるRecovery Managerコマンドが正常に実行されなかった場合、スクリプト内の後続のRecovery Managerコマンドは実行されません。
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; }
CREATE SCRIPTコマンドに置換変数を指定できます。コマンドラインでRecovery Managerを起動する場合、USING句によって、コマンド・ファイル内の置換変数で使用される1つ以上の値が指定されます。SQL*Plusの場合と同様に、&1は最初の値を配置する場所を示し、&2は2番目の値を配置する場所を示します。それ以降も同様です。
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; }
たとえば、次のコマンドを入力します。
% rman TARGET / CATALOG rman@catdb USING arc_backup bck0906 FY06Q3
リカバリ・カタログは、KEEP FOREVERには必要ですが、その他のKEEPオプションには必要ありません。
たとえば、/tmp/catscript.rmanコマンド・ファイルを次のように実行します。
RMAN> @/tmp/catscript.rman
この手順では、ストアド・スクリプトは作成はされますが、実行はされないことに注意してください。
次の例では、quarterlyというリカバリ・カタログ・スクリプトを実行します。この例では、メディア・ファミリ（テープのセット）の名前としてarc_backup、FORMAT文字列の一部としてbck1206、リストア・ポイントの名前としてFY06Q4を指定します。
RUN { EXECUTE SCRIPT quarterly USING arc_backup bck1206 FY06Q4; }
ストアド・スクリプトを表示またはファイルに出力するには、PRINT SCRIPTコマンドを使用します。
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';
リカバリ・カタログに定義されたスクリプトの名前を表示するには、LIST ... SCRIPT NAMESコマンドを使用します。Recovery Managerがターゲット・インスタンスに接続せずにリカバリ・カタログに接続している場合に使用できるコマンドは、LIST GLOBAL SCRIPT NAMESおよびLIST ALL SCRIPT NAMESのみです。その他の形式のLIST ... SCRIPT NAMESコマンドでは、リカバリ・カタログ接続が必要です。
LIST ... SCRIPT NAMESコマンドを実行します。たとえば、現在接続しているターゲット・データベースに対して実行可能なすべてのグローバル・スクリプトおよびローカル・スクリプトの名前を表示するには、次のコマンドを実行します。
LIST SCRIPT NAMES;
次の例では、グローバル・スクリプトの名前のみを表示します。
LIST GLOBAL SCRIPT NAMES;
現行のリカバリ・カタログに格納されたすべてのスクリプト（リカバリ・カタログに登録されたすべてのターゲット・データベースのグローバル・スクリプトとローカル・スクリプトを含む）の名前を表示するには、次の形式のコマンドを使用します。
LIST ALL SCRIPT NAMES;
出力では、表示された各スクリプトに定義されたターゲット・データベース（または各スクリプトがグローバルであるかどうか）が示されます。
リカバリ・カタログからストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPTコマンドを使用します。
DELETE SCRIPTコマンドを入力します。GLOBALを指定せずにDELETE SCRIPTを使用し、指定した名前のストアド・スクリプトがそのターゲット・データベースに存在しない場合、指定した名前が付いたグローバル・ストアド・スクリプトが検索され、該当するスクリプトが削除されます。たとえば、次のコマンドを入力するとします。
DELETE SCRIPT 'global_full_backup';
この場合、Recovery Managerは、接続したターゲット・データベース用に定義されたglobal_full_backupスクリプトを検索します。該当するスクリプトが検出されない場合、グローバル・スクリプト内でglobal_full_backupという名前のスクリプトを検索し、該当するスクリプトを削除します。
グローバル・ストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPTを使用します。
DELETE GLOBAL SCRIPT 'global_full_backup';
Recovery Managerクライアントの起動時にリカバリ・カタログ内のストアド・スクリプトを実行するには、Recovery Managerクライアントの起動時にSCRIPT引数を指定します。たとえば、次のコマンドを入力してスクリプト/tmp/fbkp.cmdを実行できます。
% rman TARGET / CATALOG rman@catdb SCRIPT '/tmp/fbkp.cmd';
Recovery Managerクライアントの起動時には、（ストアド・スクリプトを含む）リカバリ・カタログおよび（スクリプトの実行先の）ターゲット・データベースに接続する必要があります。
ローカル・スクリプトとグローバル・ストアド・スクリプトが同じ名前で定義されている場合、Recovery Managerは常にローカル・スクリプトを実行します。
この項では、様々な管理タスクおよびメンテナンス・タスクについて説明します。この項の内容は、次のとおりです。
リカバリ・カタログを作成してターゲット・データベースを登録した後、このカタログをメンテナンスする必要があります。たとえば、Recovery Managerのメンテナンス・コマンド（第11章「Recovery Managerバックアップおよびリポジトリ・レコードのメンテナンス」を参照）を実行して、バックアップ・レコードの更新および不要なバックアップの削除を行う必要があります。このタイプのメンテナンスは、リカバリ・カタログでRecovery Managerを使用するかどうかに関係なく実行する必要があります。リカバリ・カタログ・スキーマの更新などのその他のタイプのメンテナンスは、リカバリ・カタログでのRecovery Managerの使用に固有です。
Data Guard環境でリカバリ・カタログを使用する場合は、カタログに記録されるバックアップおよびデータベース・ファイルに、特別な考慮事項が適用されます。Recovery Managerでバックアップにアクセスできるタイミング、およびアクセス可能なバックアップに対するRecovery Managerメンテナンス・コマンドの動作については、「Data Guard環境でのRecovery Managerによるファイル管理」を参照してください。
Recovery Managerは、再同期化を実行する際に、リカバリ・カタログと、ターゲット・データベースの現行の制御ファイルまたはバックアップ制御ファイルを比較し、欠落したメタデータまたは変更されたメタデータを追加してカタログを更新します。ほとんどのRecovery Managerコマンドは、ターゲット制御ファイルがマウントされ、カタログが使用可能になると、再同期化を自動的に実行します。Data Guard環境では、Recovery Managerは逆再同期化を実行して、カタログのメタデータでデータベース制御ファイルを更新できます。
リカバリ・カタログを再同期化すると、Recovery Managerが制御ファイルから取得するメタデータが常に最新に保たれます。再同期化には、完全再同期化と部分再同期化があります。
部分再同期化では、Recovery Managerはターゲット・データベースの現行の制御ファイルを読み取って、新しいバックアップ、新しいアーカイブREDOログなどに関する変更されたメタデータを更新します。Recovery Managerは、データベースの物理スキーマに関するメタデータは再同期化しません。
完全再同期化では、Recovery Managerは、データベース・スキーマのレコードを含め、変更されたすべてのレコードを更新します。Recovery Managerは、データベースに構造変更（データベース・ファイルの追加または削除、新しいインカネーションの作成など）を行った後またはRecovery Managerの永続的な構成を変更した後に完全再同期化を実行します。
Recovery Managerは、完全再同期化の実行時に、一時的なバックアップ制御ファイルであるスナップショット制御ファイルを作成します。データベースでは、あるスナップショット制御ファイルにアクセスするRecovery Managerセッションが一度に1つのみに制限されます。Recovery Managerは、ターゲット・データベース・ホスト上のオペレーティング・システム固有の場所にスナップショット制御ファイルを作成します。スナップショット制御ファイルの名前および場所は、「スナップショット制御ファイルの場所の構成」の説明に従って指定できます。
このスナップショット制御ファイルによって、Recovery Managerは制御ファイルの一貫性ビューを持つことができます。制御ファイルは短期の使用を目的としているため、カタログには登録されません。Recovery Managerは、制御ファイルのチェックポイントをリカバリ・カタログに記録して、そのカタログが記録された時点を示します。
Recovery Managerは、データベースにTARGETとして接続すると、リカバリ・カタログをそのデータベースとのみ自動的に再同期化します。つまり、Recovery Managerは、Data Guard環境内の1つのデータベースにTARGETとして接続しても、Data Guard環境内のすべてのデータベースは自動的に再同期化しません。RESYNC CATALOG FROM DB_UNIQUE_NAMEコマンドを使用すると、リカバリ・カタログをData Guard環境内のデータベースと手動で再同期化できます。
手動での再同期化の例では、Recovery Managerが本番データベースprodにTARGETとして接続していること、およびCONFIGUREを使用してdgprod3用の構成を作成していることを想定しています。RESYNC CATALOG FROM DB_UNIQUE_NAME dgprod3を実行すると、Recovery Managerは、リカバリ・カタログをdgprod3制御ファイルと再同期化します。この場合、Recovery Managerは、通常の再同期化（メタデータのフローがdgprod3制御ファイルからカタログの方向）と逆再同期化の両方が実行されます。逆再同期化では、Recovery Managerは、リカバリ・カタログの永続的な構成を使用して、dgprod3制御ファイルを更新します。
Recovery Managerがターゲット・データベースおよびリカバリ・カタログに接続しているときにRecovery Managerコマンドを実行すると、Recovery Managerは自動的にリカバリ・カタログを再同期化します。そのため、RESYNC CATALOGコマンドを手動で実行する必要がある機会はあまり多くありません。次の項では、カタログの再同期化を手動で実行する必要がある場合について説明します。
部分再同期化を実行するRecovery Managerコマンドの発行時にリカバリ・カタログが使用不可であった場合、後でカタログ・データベースをオープンして、RESYNC CATALOGコマンドを使用して手動で再同期化します。
たとえば、ターゲット・データベースがニューヨークに存在し、リカバリ・カタログが日本に存在するとします。地理的に離れたデータベースの可用性に依存しないようにするため、CATALOGモードのターゲット・データベースの日次バックアップは行わないことにします。このような場合、実行可能な頻度でカタログに接続し、RESYNC CATALOGコマンドを実行します。
ターゲット・データベースがARCHIVELOGモードで実行されていると想定します。また、次の操作を実行すると想定します。
この場合、REDOログ・スイッチの発生時またはREDOログのアーカイブ時にリカバリ・カタログが自動的に更新されないため、リカバリ・カタログを定期的に手動で再同期化する必要があります。データベースでは、REDOログ・スイッチおよびアーカイブREDOログに関するメタデータは制御ファイルにのみ格納されます。定期的に再同期化を実行して、この情報をリカバリ・カタログに伝播する必要があります。
リカバリ・カタログの再同期化の頻度は、データベースがREDOログをアーカイブする頻度によって異なります。この操作のコストは、制御ファイル内の、最後の再同期化以降に挿入または変更されたレコードの数に比例します。挿入または変更されたレコードがない場合、再同期化のコストは非常に低くなります。多くのレコードが挿入または変更された場合、再同期化にかかる時間が長くなります。
スタンバイ・データベースにTARGETとして接続されていない場合でも、このデータベースに対してRecovery Manager構成の作成または変更を行うことができます。このタスクは、CONFIGURE DB_UNIQUE_NAMEまたはCONFIGURE ... FOR DB_UNIQUE_NAMEコマンドを使用して実行します。「リカバリ・カタログの手動での再同期化」で説明されているように、スタンバイ・データベースを手動で再同期化して、スタンバイ・データベースの制御ファイルを更新できます。
リカバリ・カタログ内のメタデータは、常に最新の状態にしておく必要があります。リカバリ・カタログはターゲット制御ファイルからメタデータを取得するため、カタログ内のデータが最新の状態かどうかは、制御ファイル内のデータが最新の状態かどうかによって決まります。制御ファイル内のバックアップ・メタデータが、新しいレコードで上書きされる前にカタログに記録されていることを確認する必要があります。
CONTROL_FILE_RECORD_KEEP_TIME初期化パラメータは、レコードが制御ファイルに保持される最小日数を指定します。この日数後は、レコードは上書き対象になります。このため、これらのレコードが消去される前に、リカバリ・カタログを制御ファイルのレコードと再同期化する必要があります。CONTROL_FILE_RECORD_KEEP_TIME設定より短い間隔で、次の処理のいずれかを実行する必要があります。
CONTROL_FILE_RECORD_KEEP_TIMEがバックアップまたは再同期化の間隔より長くなるようにします。そうしないと、制御ファイルがリカバリ・カタログに伝播される前に再利用される場合があります。通常、予定の間隔に1週間を追加することをお薦めします。
制御ファイルのサイズが大きくなりすぎることは問題です。ターゲット・データベースの制御ファイルのサイズは、次のものの数に応じて大きくなります。
制御ファイルのサイズが大きくなり、ブロック数またはレコード数が上限に達して制御ファイルのサイズがそれ以上大きくならない場合、最も古いレコードは、CONTROL_FILE_RECORD_KEEP_TIMEの設定値に達していなくても上書きされる場合があります。この場合、データベースはアラート・ログにメッセージを書き込みます。この状況が頻繁に発生する場合、CONTROL_FILE_RECORD_KEEP_TIMEの値を減らし、再同期化の頻度を高くします。
|
参照:
|
ターゲット・データベースの制御ファイルを使用してリカバリ・カタログの完全再同期化を強制実行するには、RESYNC CATALOGを使用します。Data Guard環境で特定のデータベースを再同期化するか、またはすべてのデータベースを再同期化するかに応じて、RESYNC FROM DB_UNIQUE_NAMEまたはALLを使用してデータベースの一意の名前を指定できます。通常、この操作は、スタンバイ・データベースに対するCONFIGUREコマンドを実行した後、そのスタンバイ・データベースに接続していない場合に実行します。
STARTUP MOUNT;
Recovery Managerプロンプトで、RESYNC CATALOGコマンドを次のように実行します。
RESYNC CATALOG;
次の例では、standby1の制御ファイルを再同期化します。
RESYNC CATALOG FROM DB_UNIQUE_NAME standby1;
次の例では、Data Guard環境内ですべてのデータベースの制御ファイルを再同期化します。
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
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で、プライマリ・データベースではなく、スタンバイ・データベースにRecovery ManagerをTARGETとして接続する点は異なります。
TARGETとしてプライマリ・データベースに接続し、リカバリ・カタログにも接続します。たとえば、次のコマンドを入力します。
% rman RMAN> CONNECT CATALOG catowner@catdb recovery catalog database Password: password connected to recovery catalog database RMAN> CONNECT TARGET SYS@prodny target database Password: password connected to target database: PRODNY (DBID=39525561)
DB_UNQUE_NAME値を表示します。次のLISTコマンドを実行します。
RMAN> LIST DB_UNIQUE_NAME OF DATABASE;
DB_UNIQUE_NAMEを変更します。次の例では、データベースの一意の名前をスタンバイ・データベースprodsf1からprodsf2に変更します。
RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;
UNREGISTER DATABASEコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。データベースがリカバリ・カタログから登録解除されると、Recovery Managerのすべてのリポジトリ・レコードが消失します。データベースは再度登録できますが、このデータベースのリカバリ・カタログ・レコードは、再登録時の制御ファイルの内容に基づきます。ターゲット・データベースの制御ファイル内のCONTROLFILE_RECORD_KEEP_TIME設定より古いレコードは消失します。また、制御ファイルに格納されていないストアド・スクリプトも消失します。
この例では、リカバリ・カタログを使用せずにプライマリ・データベースとスタンバイ・データベースのメタデータを格納すると想定しています。
TARGETとして接続します。リカバリ・カタログにも接続します。ターゲット・データベースに接続する必要はありませんが、接続しない場合はUNREGISTERコマンドにターゲット・データベースの名前を指定する必要があります。リカバリ・カタログ内に同じ名前が付いた複数のデータベースが存在する場合、RUNブロックにUNREGISTERコマンドを含め、SET DBIDを使用して、該当するデータベースのDBIDを設定します。
たとえば、Recovery Managerは、オープンしているターゲット・データベースに接続した場合、次の形式の行を出力します。
connected to target database: PROD (DBID=39525561)
LIST BACKUP SUMMARYおよびLIST COPY SUMMARYを使用して、リカバリ・カタログに記録されているすべてのバックアップを表示すると役に立つ場合があります。この場合、後でデータベースを再登録するときに、制御ファイルで認識されないバックアップをカタログに再度追加できます。
DELETE文を実行して、既存のすべてのバックアップを削除します。データベースをリカバリ・カタログから削除し、制御ファイルを使用してこのデータベースのRecovery Managerメタデータを格納する場合は、すべてのバックアップは削除しないでください。次のコマンドは、バックアップの削除方法を示しています。
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
UNREGISTERコマンドでは、Data Guard環境での使用のためにDB_UNIQUE_NAME句がサポートされています。この句を使用すると、特定のデータベースのメタデータを削除できます。
リカバリ・カタログによって、バックアップは特定のデータベースに関連付けられます。データベースの登録を解除すると、Recovery Managerは、これらのバックアップ・ファイルのデータベース名をNULLに更新します。そのため、バックアップは記録されていますが、バックアップの所有者は存在しなくなります。CHANGE ... RESET DB_UNIQUE_NAMEコマンドを実行すると、現在所有者が存在しないバックアップの所有権を別のデータベースに関連付けることができます。UNREGISTERコマンドにINCLUDING BACKUPSを指定した場合、Recovery Managerは、登録を解除されたデータベースのバックアップ・メタデータも削除します。
この例では、プライマリ・データベースlnx3に、関連付けられたスタンバイ・データベースstandby1があると想定しています。このスタンバイ・データベースの登録を解除します。
TARGETとしてソース・データベースに接続します。また、リカバリ・カタログにもRecovery Managerを接続します。たとえば、次のコマンドを入力します。
% rman RMAN> CONNECT TARGET SYS@lnx3 target database Password: password connected to target database: LNX3 (DBID=781317675) RMAN> CONNECT CATALOG rman@catdb
たとえば、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 STANDBY
1 LNX3 781317675 PRIMARY LNX3
UNREGISTER DB_UNIQUE_NAMEコマンドを実行します。たとえば、データベースstandbyの登録を解除するには、UNREGISTERコマンドを次のように実行します。
RMAN> UNREGISTER DB_UNIQUE_NAME standby;
Recovery Managerにデータベース名およびDBIDが表示され、確認するように求められます。
database db_unique_name is "standby", db_name is "LNX3" and DBID is 781317675 Do you really want to unregister the database (enter YES or NO)? yes
プロセスが完了すると、Recovery Managerは次のメッセージを出力します。
database with db_unique_name standby unregistered from the recovery catalog
「データベース・インカネーション」で説明されているように、RESETLOGSオプションでデータベースをオープンする際にデータベースの新しいインカネーションを作成します。新しいインカネーションのレコードには、V$DATABASE_INCARNATIONビューでアクセスできます。
RESETLOGSオプションでデータベースをオープンすると、新しいデータベース・インカネーション・レコードがリカバリ・カタログ内に自動的に作成されます。また、データベースによって暗黙的かつ自動的にRESET DATABASEコマンドが発行され、このデータベースの新しいインカネーションが現行のインカネーションであることが指定されます。ターゲット・データベースによって実行される後続のすべてのバックアップおよびログのアーカイブは、新しいデータベース・インカネーションに関連付けられます。
Recovery Managerで、RESTOREとRECOVER、またはFLASHBACK DATABASEのいずれかを使用してデータベースを現行のRESETLOGS SCNより前のSCNに戻す場合は、常にRESET DATABASE TO INCARNATIONコマンドを実行する必要があります。ただし、Recovery ManagerではフラッシュバックでRESET DATABASE TO INCARNATIONが暗黙的に実行されるため、次の場合はこのコマンドを明示的に実行する必要はありません。
FLASHBACK DATABASEを使用して、データベースを直系祖先パス内のSCNに戻す場合（直系祖先パスについては、「データベース・インカネーション」を参照）
FLASHBACK DATABASEを使用して、データベースをリストア・ポイントに戻す場合
次の手順では、RESETLOGSを使用してリカバリする場合にデータベース・インカネーションをリセットする方法について説明します。
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;
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;
この項では、リカバリ・カタログのアップグレードおよびアップグレードの実行が必要となるタイミングについて説明します。
Recovery Managerクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。Recovery Managerのバージョンと互換性があるスキーマ・バージョンについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表を参照してください。たとえば、Oracle Database 11g のRecovery Managerクライアントでリリース10.2のリカバリ・カタログ・スキーマを使用する場合、そのカタログをアップグレードする必要があります。
Oracle Database 10g R1バージョンのリカバリ・カタログ・スキーマには、CREATE TYPE権限が必要であることに注意してください。10g R1より前のリリースでリカバリ・カタログの所有者を作成し、CREATE TYPE権限が含まれていないRECOVERY_CATALOG_OWNERロールを付与した場合は、カタログのアップグレードの前に、明示的にこの所有者にCREATE TYPEを付与する必要があります。
Recovery Managerクライアントで要求されるバージョンより新しいバージョンのリカバリ・カタログを使用している場合、UPGRADE CATALOGを発行するとエラーが表示されます。Recovery Managerでは、リカバリ・カタログが現行のバージョンでアップグレードが必要ない場合でもUPGRADE CATALOGコマンドを実行できます。このコマンドを実行すると、必要に応じていつでもパッケージを再作成できます。アップグレード中に生成されたエラー・メッセージを、メッセージ・ログで確認してください。
Data Guard環境で、リカバリ・カタログ・スキーマをOracle Database 11g にアップグレードすると想定します。Recovery Managerは、スタンバイ・データベースに接続する際に、新しいデータベース情報を自動的に登録し、再同期化してファイル名を制御ファイルから取得します。
再同期化中に、Recovery Managerは名前をターゲット・データベース名に関連付けます。リカバリ・カタログには、履歴メタデータが含まれているため、制御ファイルで認識されないレコードもあります。たとえば、standby1制御ファイルでは、primary1に作成されたすべてのバックアップについては認識されません。これらの古いレコードのデータベースの一意の名前はNULLになります。「リカバリ・カタログのメンテナンス」で説明されているように、CROSSCHECKを使用してこれらのレコードを修正できます。
リカバリ・カタログのスキーマ・バージョンは、リカバリ・カタログ自体に格納されます。この情報は、本番システムにバージョンの異なる複数のデータベースが存在し、カタログのスキーマ・バージョンが特定のターゲット・データベース・バージョンで使用可能かどうかを確認する必要がある場合に重要です。
RCVER表を問い合せてスキーマ・バージョンを取得します。次に、コマンドと出力の例を示します。
SELECT * FROM rcver; VERSION ------------ 10.02.00
rcver表に複数の行が表示される場合、この表内で最上位のバージョンが、現行のカタログ・スキーマ・バージョンです。この表に格納されるのはメジャー・バージョン番号のみであり、パッチ番号は格納されません。たとえば、rcver表に次の行が表示されたと想定します。
VERSION ------------ 08.01.07 09.00.01 10.02.00
これらの行は、カタログがリリース8.1.7の実行可能ファイルによって作成され、リリース1（9.0.1）にアップグレードされ、最後にリリース2（10.2）にアップグレードされたことを示しています。カタログ・スキーマの現行バージョンは2（10.2）です。
この例では、リカバリ・カタログ・スキーマを現行のバージョンにアップグレードすると想定しています。
RECOVERY_CATALOG_OWNERロールにCREATE TYPE権限が含まれていなかった場合は、これを付与します。たとえば、SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースに接続します。これによって、次のGRANT文を実行できます。
SQL> GRANT CREATE TYPE TO rman; SQL> EXIT;
UPGRADE CATALOGコマンドを実行します。
RMAN> UPGRADE CATALOG; recovery catalog owner is rman enter UPGRADE CATALOG command again to confirm catalog upgrade
UPDATE CATALOGコマンドを再度実行します。
RMAN> UPGRADE CATALOG; recovery catalog upgraded to version 11.01.00 DBMS_RCVMAN package upgraded to version 11.01.00 DBMS_RCVCAT package upgraded to version 11.01.00
Recovery ManagerでIMPORT CATALOGコマンドを使用して、1つのリカバリ・カタログ・スキーマを別のリカバリ・カタログ・スキーマにマージできます。このコマンドは、次の場合に有効です。
ソース・カタログ・スキーマとは、IMPORT CATALOGを使用して別のスキーマにインポートするカタログ・スキーマのことです。宛先カタログ・スキーマとは、ソース・カタログ・スキーマのインポート先となるカタログ・スキーマのことです。
デフォルトでは、Recovery Managerは、ソース・リカバリ・カタログに登録されているすべてのターゲット・データベースのメタデータをインポートします。必要に応じて、ソース・カタログ・スキーマからインポートするデータベースのIDのリストを指定できます。
デフォルトでは、Recovery Managerは、正常なインポートの後で、インポートしたデータベースをソース・カタログ・スキーマから登録解除します。登録解除が正常に実行されたかどうかを示すために、Recovery Managerは、マージされたデータベースの登録解除の前後にメッセージを出力します。NO UNREGISTERオプションを指定して、データベースが宛先カタログから登録解除されないように指定することもできます。
ストアド・スクリプトは、グローバルまたはローカルのいずれかです。グローバル・スクリプトでは、宛先スキーマにすでにスクリプト名が含まれているために、インポート中に名前の競合が発生する可能性があります（ローカル・スクリプトでは発生しません）。この場合、Recovery Managerは、グローバル・スクリプト名をCOPY OF script_nameに変更します。たとえば、Recovery Managerは、bp_cmdをCOPY OF bp_cmdに変更します。
名前が変更されたグローバル・スクリプトも一意でない場合、Recovery Managerは、その名前をCOPY(2) OF script_nameに変更します。このスクリプト名も存在する場合、Recovery Managerは、スクリプトの名前をCOPY(3) OF script_nameに変更します。Recovery Managerは、スクリプト名が一意になるまでCOPY(n) OFのパターンを繰り返します。
『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表に示されているように、ターゲット・データベース、リカバリ・カタログ・データベースおよびリカバリ・カタログ・スキーマのデータベース・バージョンが異なっている場合があります。最新のバージョンのリカバリ・カタログ・スキーマで、既存のすべてのリカバリ・カタログを1つのリカバリ・カタログにインポートすることをお薦めします。カタログのバージョンを確認する方法については、「リカバリ・カタログのスキーマ・バージョンの確認」を参照してください。互換性の表を確認し、使用している環境内で互換性があるスキーマ・バージョンを判別します。
IMPORT CATALOGを使用する場合、ソース・リカバリ・カタログ・スキーマのバージョンは、このコマンドの実行に使用するRecovery Manager実行可能ファイルの現行のバージョンと一致している必要があります。ソース・カタログ・スキーマのバージョンのほうが低い場合は、スキーマをインポートする前に現行のバージョンにアップグレードします。アップグレード方法については、「リカバリ・カタログのアップグレード」を参照してください。ソース・リカバリ・カタログ・スキーマのバージョンのほうが高い場合は、より高いバージョンのRecovery Manager実行可能ファイルを使用してインポートを再試行します。
ソース・カタログ・スキーマと宛先カタログ・スキーマの両方にデータベースを登録することはできません。現在、データベースが両方のカタログ・スキーマに登録されている場合は、インポートを実行する前にソース・カタログ・スキーマからデータベースを登録解除します。
リカバリ・カタログを別のリカバリ・カタログにインポートする場合、ターゲット・データベースへの接続は必要ありません。Recovery Managerは、ソース・カタログおよび宛先カタログにのみ接続する必要があります。
次の例では、データベースsrcdbにユーザー102catが所有する10.2リカバリ・カタログ・スキーマが含まれており、データベースdestdbにユーザー111catが所有する11.1リカバリ・カタログ・スキーマが含まれています。
CATALOGとして宛先リカバリ・カタログ・スキーマに接続します。たとえば、次のように入力します。
% rman RMAN> CONNECT CATALOG 111cat@destdb;
たとえば、次のコマンドを入力して、データベースsrcdbの102catが所有するカタログをインポートします。
IMPORT CATALOG 102cat@srcdb;
前述の例を少し変更して、ソース・カタログに登録されたターゲット・データベースのサブセットに関するメタデータをインポートすることもできます。DBIDまたはデータベース名によってデータベースを指定できます。次に例を示します。
IMPORT CATALOG 102cat@srcdb DBID=1423241, 1423242; IMPORT CATALOG 102cat@srcdb DB_NAME=prod3, prod4;
prod1にTARGETとして接続し、このデータベースのすべてのバックアップを表示します。
LIST BACKUP;
データベース間でリカバリ・カタログを移動する手順は、カタログをインポートする手順に類似しています。次の例では、ソース・データベースは既存のリカバリ・カタログを含むデータベースで、移動先データベースには移動されたリカバリ・カタログが含まれます。
ソース・データベースから移動先データベースにリカバリ・カタログを移動する手順
このタスクの実行方法については、「リカバリ・カタログの作成」を参照してください。
このタスクの実行方法については、「リカバリ・カタログのインポート」を参照してください。
DROP CATALOGコマンドを使用すると、CREATE CATALOGコマンドの結果として作成されたオブジェクトが削除されます。リカバリ・カタログを所有するユーザーが、CREATE CATALOGで作成されなかったオブジェクトも所有している場合、これらのオブジェクトはDROP CATALOGコマンドでは削除されません。
リカバリ・カタログ・スキーマのバックアップが存在しない場合にリカバリ・カタログを削除すると、このカタログに登録されているすべてのターゲット・データベースのバックアップが使用できなくなる可能性があります。ただし、すべてのターゲット・データベースの制御ファイルには、そのデータベースの最近のバックアップのレコードが保持されます。
DROP CATALOGコマンドは、複数のターゲット・データベースが登録されたリカバリ・カタログから1つのデータベースを登録解除する場合には使用しないことをお薦めします。リカバリ・カタログを削除すると、そのカタログに登録されたすべてのターゲット・データベースのバックアップのリカバリ・カタログ・レコードが削除されます。
次の例では、ユーザーcatownerとしてリカバリ・カタログに接続します。
% rman TARGET / CATALOG catowner@catdb
DROP CATALOGコマンドを実行します。
DROP CATALOG; recovery catalog owner is catowner enter DROP CATALOG command again to confirm catalog removal
DROP CATALOGコマンドを再度実行します。
DROP CATALOG;
|
参照:
|
|
 Copyright © 2003, 2008, Oracle Corporation. All Rights Reserved. |
|