| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース2(11.2) B56269-05 |
|
 前 |
 次 |
この章では、RMANリカバリ・カタログを管理する方法について説明します。このカタログは、1つ以上のターゲット・データベースのRMANリポジトリ・データが含まれているデータベース・スキーマです。この章の内容は次のとおりです。
|
関連項目:
|
この項では、リカバリ・カタログの管理に関連する基本的な概念について説明します。
リカバリ・カタログとは、1つ以上のOracle Databaseに関するメタデータを格納するためにRMANで使用されるデータベース・スキーマのことです。通常、このカタログは専用のデータベースに格納します。リカバリ・カタログには、次のメリットがあります。
リカバリ・カタログによって、各ターゲット・データベースの制御ファイルに格納されているRMANリポジトリに対して冗長性が作成されます。リカバリ・カタログは、セカンダリ・メタデータ・リポジトリとして機能します。ターゲット制御ファイルおよびすべてのバックアップが消失した場合でも、RMANメタデータはリカバリ・カタログ内に存在します。
リカバリ・カタログによって、すべてのターゲット・データベースのメタデータが集中化されます。メタデータを1つの場所に格納することによって、レポート・タスクおよび管理タスクの実行が簡単になります。
リカバリ・カタログには、制御ファイルより長期のメタデータ履歴を格納できます。この機能は、制御ファイルの履歴より前の時点にリカバリする必要がある場合に有効です。リカバリ・カタログ・データベースを使用することによって管理はより複雑になりますが、より長期のバックアップ履歴を使用できるというメリットがあります。
一部のRMAN機能は、リカバリ・カタログを使用する場合にのみ機能します。たとえば、リカバリ・カタログにはRMANスクリプトを格納することができます。ストアド・スクリプトの主なメリットは、ターゲット・データベースおよびリカバリ・カタログに接続可能なRMANクライアントで使用できることです。コマンド・ファイルは、それらが格納されているファイル・システムにRMANクライアントがアクセスできる場合にのみ使用できます。
Data Guard環境でRMANを使用する場合は、リカバリ・カタログが必要です。すべてのプライマリ・データベースおよびスタンバイ・データベースのバックアップ・メタデータを格納すると、カタログによって、バックアップ・タスクを1つのスタンバイ・データベースにオフロードし、その環境内のその他のデータベースにバックアップをリストアできます。
リカバリ・カタログには、登録されている各ターゲット・データベースのRMAN操作に関するメタデータが含まれています。RMANは、リカバリ・カタログに接続されると、カタログから排他的にそのメタデータを取得します。このカタログには、次のタイプのメタデータが含まれています。
データファイルとアーカイブREDOログのバックアップ・セットおよびバックアップ・ピース
データファイルのコピー
アーカイブREDOログおよびそのコピー
データベース構造(表領域およびデータファイル)
ストアド・スクリプト(ユーザーが作成した一連の名前付きRMANコマンド)
RMAN構成の永続設定
RMANで使用するために、リカバリ・カタログにデータベースを記載するプロセスを登録と呼びます。すべてのターゲット・データベースを環境内の単一のリカバリ・カタログに登録することをお薦めします。たとえば、データベースprod1、prod2およびprod3を、データベースcatdbのcatownerが所有する1つのカタログに登録できます。
集中化されたリカバリ・カタログ(ベース・リカバリ・カタログとも呼ばれる)の所有者は、他のデータベース・ユーザーに対してカタログへの制限付きアクセス権限を付与および取り消すことができます。制限付きユーザーは、それぞれ仮想プライベート・カタログと呼ばれる独自のメタデータへの完全な読取り/書込み権限を持っています。RMANメタデータは、仮想プライベート・カタログ所有者のスキーマに格納されます。ベース・リカバリ・カタログの所有者は、各仮想プライベート・カタログ・ユーザーがアクセスできるオブジェクトを決定します。
リカバリ・カタログは、様々なバージョンのOracle Databaseを使用している環境、または使用してきた環境で使用できます。その結果、様々なバージョンのRMANクライアント、リカバリ・カタログ・データベース、リカバリ・カタログ・スキーマおよびターゲット・データベースが環境内に存在する可能性があります。複数のリカバリ・カタログ・スキーマを1つにマージする方法については、「リカバリ・カタログのインポートおよび移動」を参照してください。
バックアップ、リストア、クロスチェックなどのRMAN操作では、RMANによって常に最初に制御ファイルが更新され、次にメタデータがリカバリ・カタログに伝播されます。マウントされた制御ファイルからリカバリ・カタログへのメタデータのこのフローは、リカバリ・カタログの再同期化と呼ばれます。これによって、RMANが制御ファイルから取得するメタデータが現行のものになります。
ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連のRMANコマンドの管理に使用できます。 このスクリプトは、ファイル・システムではなくリカバリ・カタログに格納されます。
ローカル・ストアド・スクリプトは、作成時にRMANが接続していたターゲット・データベースに関連付けられます。スクリプトは、関連付けられたターゲット・データベースに接続している場合にのみ実行できます。グローバル・ストアド・スクリプトは、リカバリ・カタログに登録されているすべてのデータベースに対して実行できます。仮想プライベート・カタログ・ユーザーは、グローバル・スクリプトへの読取り専用アクセス権限を持っています。グローバル・スクリプトの作成または更新は、ベース・リカバリ・カタログへの接続中に実行する必要があります。
「Data Guard環境でのRMAN」で説明されているように、Data Guard環境内のすべての物理データベース(プライマリ・データベースとスタンバイ・データベースの両方)のRMANメタデータを管理するには、リカバリ・カタログを使用する必要があります。RMANは、Data Guard環境の実情の単一のソースとしてリカバリ・カタログを使用します。
RMANは、逆再同期化で、リカバリ・カタログを使用してプライマリまたはスタンバイ制御ファイルを更新できます。この場合、メタデータのフローの方向は、制御ファイルからカタログではなく、カタログから制御ファイルになります。RMANは、再同期化が必要なほぼすべての場合に、再同期化を自動的に実行します。そのため、RESYNCコマンドを使用して手動で再同期化する必要がある機会はあまり多くありません。
|
関連項目: スタンバイ・データベースで使用するためにRMAN環境を構成する方法については、『Oracle Data Guard概要および管理』を参照してください。 |
リカバリ・カタログをRMANで使用できるように設定する基本手順は次のとおりです。
リカバリ・カタログを作成します。
このタスクの実行方法については、「リカバリ・カタログの作成」を参照してください。
リカバリ・カタログにターゲット・データベースを登録します。
この手順によって、RMANはターゲット・データベースに関するメタデータをリカバリ・カタログに格納できます。このタスクについては、「リカバリ・カタログへのデータベースの登録」を参照してください。
必要に応じて、ターゲット制御ファイルに格納されていないレコードが含まれている古いバックアップをカタログに追加します。
このタスクの実行方法については、「リカバリ・カタログへのバックアップの追加」を参照してください。
必要に応じて、特定のユーザー用の仮想プライベート・カタログを作成し、そのユーザーがアクセスできるメタデータを指定します。
このタスクの実行方法については、「仮想プライベート・カタログの作成および管理」を参照してください。
バックアップおよびリカバリ計画に含めることによって、リカバリ・カタログを保護します。
カタログをバックアップおよびリカバリする方法および可用性を向上させる方法については、「リカバリ・カタログの保護」を参照してください。
この章の残りでは、リカバリ・カタログの使用開始後、そのリカバリ・カタログを管理する方法について説明します。次のタスクを実行できます。
RMANスクリプトをリカバリ・カタログに格納して管理する方法については、「ストアド・スクリプトの管理」を参照してください。
RMAN操作に関してレポートする方法については、第11章「RMAN操作に関するレポート」を参照してください。LISTおよびREPORTコマンドは、リカバリ・カタログを使用しているかどうかに関係なく使用できます。リカバリ・カタログ内の固定ビューによってRMAN操作に関してレポートする方法については、「リカバリ・カタログ・ビューの問合せ」を参照してください。
実行中のリカバリ・カタログのメンテナンスでの様々なタスク(1つのリカバリ・カタログを別のリカバリ・カタログにインポートするタスクなど)については、「リカバリ・カタログのメンテナンス」を参照してください。
リカバリ・カタログをメンテナンスしない場合は、「リカバリ・カタログの削除」を参照してください。
この項では、リカバリ・カタログ作成時の各フェーズについて説明します。この項の内容は、次のとおりです。
RMANでリカバリ・カタログを使用する場合、リカバリ・カタログ・スキーマを保持する必要があります。リカバリ・カタログは、スキーマのデフォルト表領域に格納されます。SYSユーザーはリカバリ・カタログ所有者に設定できません。
リカバリ・カタログ・スキーマをインストールするために使用するデータベースおよびそのデータベースのバックアップ方法を決定します。また、カタログ・データベースをARCHIVELOGモード(推奨)で動作させるかどうかを決定します。
|
注意: ターゲット・データベースを使用して、リカバリ・カタログのデータベースとしてバックアップしないでください。リカバリ・カタログは、ターゲット・データベースが消失した場合に保護される必要があります。 |
カタログ・スキーマによって使用される領域を割り当てる必要があります。リカバリ・カタログ・スキーマのサイズは、カタログによって監視されるデータベースの数によって異なります。スキーマは、アーカイブREDOログ・ファイルおよび各データベースのバックアップの増加とともに増大します。カタログに格納されているRMANストアド・スクリプトを使用する場合は、これらのスクリプトに対して領域を割り当てる必要があります。
たとえば、trgtデータベースにファイルが100個あり、このデータベースを1日に1回バックアップして、それぞれ1つのバックアップ・ピースを含む50個のバックアップ・セットを作成すると想定します。バックアップ・ピース表内の各行が領域を最大限に使用すると想定すると、1回の日次バックアップによってリカバリ・カタログ内で使用される領域は170KB未満です。この日次バックアップを1年間行うと、この期間中に使用される合計記憶域は約62MBです。これとほぼ同じ量の記憶域がアーカイブ・ログに使用されると想定されます。したがって、最悪の場合はメタデータの格納に1年間で約120MBが必要になります。バックアップ・ピースの行領域の一部のみを使用する通常の状況の場合、現実的な値は年間15MBです。
リカバリ・カタログに複数のデータベースの登録を予定している場合、前述の計算に従って各データベースに必要な領域を足し、リカバリ・カタログ・スキーマのデフォルト表領域の合計サイズを算出してください。
リカバリ・カタログを既存のデータベース内に作成する場合、リカバリ・カタログ・スキーマ用のデフォルト表領域を保持できる十分な空き領域を追加します。リカバリ・カタログを格納するための新しいデータベースを作成する場合、リカバリ・カタログ・スキーマ自体の領域に加えて、次に示すリカバリ・カタログ・データベース内の他のファイル用の領域も考慮します。
SYSTEM表領域およびSYSAUX表領域
一時表領域
UNDO表領域
オンラインREDOログ・ファイル
リカバリ・カタログ・データベース内の領域の大部分は、SYSTEM表領域、一時表領域、UNDO表領域などの表領域をサポートするために使用されます。表13-1に、一般的な領域要件を示します。
表13-1 1年間での一般的なリカバリ・カタログ領域要件
| 領域タイプ | 領域要件 |
|---|---|
|
|
90MB |
|
一時表領域 |
5MB |
|
ロールバック表領域またはUNDO表領域 |
5MB |
|
リカバリ・カタログ表領域 |
リカバリ・カタログに登録されたデータベースごとに15MB |
|
オンラインREDOログ |
ログごとに1MB(3グループ、各グループに2メンバー) |
|
注意: リカバリ・カタログとターゲット・データベースが同じディスク上に存在していないことを確認してください。リカバリ・カタログとターゲット・データベースの両方にハード・ディスク障害が発生した場合、リカバリ・プロセスがより困難になります。可能な場合、他の手段を利用し、リカバリ・カタログ・データベースとバックアップ対象のデータベースの共通の致命的な障害箇所を排除してください。 |
リカバリ・カタログ・データベースを選択して必要な領域を作成した後、リカバリ・カタログの所有者を作成し、そのユーザーに必要な権限を付与します。後続の項に示す手順では、次の状況を想定しています。
ユーザーSYSは、catdbリカバリ・カタログ・データベースに対するSYSDBA権限を持っています。
catdbリカバリ・カタログ・データベース内のtoolsという表領域にリカバリ・カタログが格納されています。RMANの予約語を表領域名として使用する場合、その語を引用符で囲み、大文字を使用する必要があります。(RMANの予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。)
tempという表領域が、リカバリ・カタログ・データベース内に存在します。
リカバリ・カタログ・データベース内にリカバリ・カタログ・スキーマを作成する手順
SQL*Plusを起動し、リカバリ・カタログを含むデータベースに管理者権限で接続します。この例では、データベースはcatdbです。
リカバリ・カタログのユーザーおよびスキーマを作成します。たとえば、次のSQL文を入力できます(passwordはユーザー定義のパスワードに置き換えます)。
CREATE USER rman IDENTIFIED BY password
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE tools
QUOTA UNLIMITED ON tools;
|
注意: 安全なパスワードを作成してください。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
スキーマ所有者にRECOVERY_CATALOG_OWNERロールを付与します。このロールによって、リカバリ・カタログのメンテナンスおよび問合せに必要なすべての権限がユーザーに付与されます。
GRANT RECOVERY_CATALOG_OWNER TO rman;
カタログ所有者の作成後、RMANのCREATE CATALOGコマンドを使用してカタログ表を作成します。このコマンドを実行すると、カタログ所有者のデフォルト表領域内にカタログが作成されます。
リカバリ・カタログを作成する手順
RMANを起動し、カタログを格納するデータベースに接続します。データベースには、リカバリ・カタログ所有者として接続します。
CREATE CATALOGコマンドを実行してカタログを作成します。カタログの作成には数分かかります。カタログ表領域がこのユーザーのデフォルト表領域の場合、次のコマンドを実行できます。
RMAN> CREATE CATALOG;
CREATE CATALOGコマンドでカタログの表領域名を指定できます。次に例を示します。
RMAN> CREATE CATALOG TABLESPACE cat_tbs;
|
注意: リカバリ・カタログに使用する表領域名がRMANの予約語である場合は、その予約語を大文字にして引用符で囲む必要があります。次に例を示します。CREATE CATALOG TABLESPACE 'CATALOG'; |
結果を確認するには、SQL*Plusを使用し、リカバリ・カタログを問い合せて作成された表を表示します。
SQL> SELECT TABLE_NAME FROM USER_TABLES;
|
関連項目: GRANTおよびCREATEUSER文のSQL構文については、 |
この項では、リカバリ・カタログでターゲット・データベース・レコードをメンテナンスする方法について説明します。この章の内容は、次のとおりです。
リカバリ・カタログにターゲット・データベースを記載するプロセスを登録と呼びます。ターゲット・データベースがリカバリ・カタログに登録されていない場合、RMANは、カタログを使用して操作に関するメタデータをそのデータベースに格納できません。登録されていないデータベースでも、RMAN操作を実行することはできます。RMANは、そのメタデータを常にターゲット・データベースの制御ファイルに格納するためです。
Data Guard環境でリカバリ・カタログを使用していない場合は、REGISTERコマンドを使用して各データベースを登録します。各データベースには、一意のDBIDが必要です。RMANのDUPLICATEコマンドまたはSQLのCREATE DATABASE文を使用すると、データベースに一意のDBIDが自動的に割り当てられます。その他の方法でデータベースを作成すると、コピーされたデータベースのDBIDとソース・データベースのDBIDが同じになる場合があります。ソース・データベースとコピー・データベースを同じカタログに登録できるように、DBNEWIDユーティリティを使用してDBIDを変更できます。
UNREGISTERコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。
Data Guard環境では、プライマリ・データベースとスタンバイ・データベースは同じDBIDおよびデータベース名を共有します。Data Guard環境のデータベースをリカバリ・カタログに登録できるようにするには、各データベースに異なるDB_UNIQUE_NAME値が必要です。データベースのDB_UNIQUE_NAMEパラメータは、その初期化パラメータ・ファイルに設定されています。
Data Guard環境でRMANを使用する場合は、プライマリ・データベースに対してのみREGISTER DATABASEコマンドを使用できます。次の方法を使用すると、スタンバイ・データベースをリカバリ・カタログに登録できます。
TARGETとしてスタンバイ・データベースに接続すると、RMANによってデータベースがリカバリ・カタログに自動的に登録されます。
リカバリ・カタログで認識されないスタンバイ・データベースに対してCONFIGURE DB_UNIQUE_NAMEコマンドを実行する場合、RMANは、対応するプライマリ・データベースが登録されていれば、このスタンバイ・データベースを自動的に登録します。
|
関連項目:
|
ターゲット・データベースでリカバリ・カタログを使用するには、まずそのターゲット・データベースをリカバリ・カタログに登録します。Data Guard環境でカタログを使用する場合は、この方法でプライマリ・データベースのみを登録できます。
次の手順を実行します。
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。リカバリ・カタログ・データベースはオープンされている必要があります。
たとえば、ネット・サービス名catdbを使用してカタログ・データベースにユーザーrman(カタログ・スキーマ所有者)として接続するには、次のコマンドを発行します。
% rman TARGET / CATALOG rman@catdb
ターゲット・データベースをマウントしていない場合、マウントまたはオープンします。
STARTUP MOUNT;
接続しているリカバリ・カタログに、ターゲット・データベースを登録します。
REGISTER DATABASE;
RMANは、カタログ表内に、ターゲット・データベースに関する情報を格納する行を作成し、ターゲット・データベースに関連するすべてのデータを制御ファイルからカタログにコピーし、カタログと制御ファイルを同期化します。
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/';
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/';
|
関連項目:
|
デフォルトでは、RMANのリカバリ・カタログの全ユーザーは、カタログのすべてのメタデータを挿入、更新および削除する完全な権限を持ちます。たとえば、2つの関連のないデータベースの管理者が同じリカバリ・カタログを共有している場合、各管理者は、誤ってまたは意図的に、もう一方の管理者のデータベース用のカタログ・データを破壊することができます。多くの企業では、同じ担当者が多くの異なるデータベースを管理し、そのリカバリ・カタログも管理するため、この状況が許容されています。ただし、その他の企業では、様々なデータベースの管理者の間、およびDBAとリカバリ・カタログの管理者の間に、明確な責務の分離が存在しており、このような企業では、各データベース管理者が、担当のデータベースに属するバックアップ・メタデータのみを変更するように制限すると同時に、単一の中央管理されたRMANリカバリ・カタログによるメリットも保つ必要がある場合があります。 この目的は、仮想プライベート・カタログを実装することによって達成できます。
すべての11gのリカバリ・カタログは、仮想プライベート・カタログをサポートしていますが、仮想プライベート・カタログは、明示的に作成しないと使用されません。1つのリカバリ・カタログに対して作成できる仮想プライベート・カタログの数に、制限はありません。各仮想プライベート・カタログは、データベース・スキーマのユーザーによって所有されます。このユーザーは、リカバリ・カタログを所有するユーザーとは異なります。
1つ以上の仮想プライベート・カタログを作成した後、その後の指示に従って、リカバリ・カタログの管理者は、各仮想プライベート・カタログに対して、リカバリ・カタログに現在登録されている1つ以上のデータベースにそのカタログを使用する権限を付与します。リカバリ・カタログの管理者は、仮想プライベート・カタログの使用中に新しいデータベースを登録する権限を付与することもできます。
|
注意: 各仮想プライベート・カタログは、すべてのグローバル・ストアド・スクリプト、および仮想プライベート・カタログが権限を持つデータベースに属する非グローバル・ストアド・スクリプトにアクセスできます。 仮想プライベート・カタログは、権限を持たないデータベースに属する非グローバル・ストアド・スクリプトにはアクセスできません。また、グローバル・ストアド・スクリプトを作成することはできません。 |
仮想プライベート・カタログを作成する基本的な手順は次のとおりです。
仮想プライベート・カタログを所有するデータベース・ユーザーを作成し(このユーザーが存在しない場合)、このユーザーにアクセス権限を付与します。
このタスクについては、「仮想プライベート・カタログ所有者の作成および権限の付与」を参照してください。
仮想プライベート・カタログを作成します。
このタスクについては、「仮想プライベート・カタログの作成」を参照してください。
仮想プライベート・カタログの作成後に、必要に応じてカタログ・アクセス権限を取り消すことができます。このタスクについては、「仮想プライベート・カタログ所有者からの権限の取消し」を参照してください。仮想プライベート・カタログを削除する方法については、「仮想プライベート・カタログの削除」を参照してください。
リカバリ・カタログが仮想プライベート・カタログの場合、これに接続しているRMANクライアントは、パッチ・レベル10.1.0.6または10.2.0.3である必要があります。Oracle9iのRMANクライアントは、仮想プライベート・カタログに接続できません。ベース・カタログに仮想プライベート・カタログ・ユーザーが含まれている場合でも、Oracle Database 11gのベース・リカバリ・カタログへのRMANクライアントの接続は、このバージョン制限の影響を受けません。
|
関連項目: RMANのバージョン互換性の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
この項では、ベース・リカバリ・カタログは作成済であると想定しています。
データベースprod1、prod2およびprod3がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログを所有するデータベース・ユーザーはcatownerです。データベース・ユーザーvpc1を作成し、このユーザーにprod1およびprod2のみへのアクセス権限を付与します。デフォルトでは、仮想プライベート・カタログ所有者にベース・リカバリ・カタログへのアクセス権限はありません。
仮想プライベート・カタログ所有者を作成し、権限を付与する手順
SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースに接続します。
仮想プライベート・カタログを所有するユーザーが存在しない場合は作成します。
たとえば、カタログを所有するデータベース・ユーザーvpc1を作成する場合は、次のコマンドを実行します(passwordはユーザー定義のパスワードに置き換えます)。
SQL> CREATE USER vpc1 IDENTIFIED BY password
2 DEFAULT TABLESPACE vpcusers
3 QUOTA UNLIMITED ON vpcusers;
|
注意: 安全なパスワードを作成してください。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。 |
仮想カタログを所有するデータベース・ユーザーにRECOVERY_CATALOG_OWNERロールを付与し、SQL*Plusを終了します。
次の例では、ユーザーvpc1にロールを付与します。
SQL> GRANT recovery_catalog_owner TO vpc1; SQL> EXIT;
RMANを起動し、(仮想プライベート・カタログ所有者ではなく)ベース・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、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コマンドを使用して、ベース・リカバリ・カタログ内のメタデータへのアクセス権限を仮想プライベート・カタログ所有者に付与しています。
仮想プライベート・カタログを作成する手順
RMANを起動し、(ベース・リカバリ・カタログ所有者ではなく)仮想プライベート・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、vpc1としてリカバリ・カタログに接続します。
% rman RMAN> CONNECT CATALOG vpc1@catdb;
仮想プライベート・カタログを作成します。
次のコマンドによって仮想プライベート・カタログが作成されます。
RMAN> CREATE VIRTUAL CATALOG;
この仮想プライベート・カタログで10.2以前のリリースのRMANを使用する場合は、次のPL/SQLプロシージャを実行します(base_catalog_ownerは、ベース・リカバリ・カタログを所有するデータベース・ユーザーです)。
SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG;
この項では、仮想プライベート・カタログを作成していると想定しています。
2つのデータベースprod1およびprod2がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログの所有者として、vpc1ユーザーにprod1へのアクセス権限を付与しています。また、このユーザーには、仮想プライベート・カタログにデータベースを登録する権限も付与しています。ここで、vpc1から権限を取り消します。
仮想プライベート・カタログ所有者から権限を取り消す手順
RMANを起動し、(仮想プライベート・カタログ所有者ではなく)リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、catownerとしてリカバリ・カタログに接続します。
% rman RMAN> CONNECT CATALOG catowner@catdb;
指定した権限を仮想プライベート・カタログ所有者から取り消します。
次のコマンドによって、prod1に関するメタデータへのアクセス権限が仮想プライベート・カタログ所有者vpc1から取り消されます。
REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
データベース名ではなくDBIDを指定することもできます。カタログvpc1は、付与されているその他のすべてのカタログ権限を保持します。
新しいターゲット・データベースをリカバリ・カタログに登録する権限を取り消すこともできます。次に例を示します。
REVOKE REGISTER DATABASE FROM vpc1;
この項では、仮想プライベート・カタログを作成しており、この時点でこれを削除すると想定しています。仮想プライベート・カタログを削除する場合、ベース・リカバリ・カタログ自体は削除しません。ベース・リカバリ・カタログを参照するシノニムおよびビューのみを削除します。
仮想プライベート・カタログを削除する手順
RMANを起動し、(ベース・リカバリ・カタログ所有者ではなく)仮想プライベート・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、ユーザーvpc1としてリカバリ・カタログに接続します。
% rman RMAN> CONNECT CATALOG vpc1@catdb;
カタログを削除します。
Oracle Database 11g以上のRMAN実行可能ファイルを使用している場合は、DROP CATALOGコマンドを使用して仮想プライベート・カタログを削除します。
RMAN> DROP CATALOG;
Oracle Database 10g以前のRMAN実行可能ファイルを使用している場合は、DROP CATALOGコマンドは使用できません。かわりに、仮想プライベート・カタログ・ユーザーとしてSQL*Plusをカタログ・データベースに接続してから、次のPL/SQLプロシージャを実行します(base_catalog_ownerは、ベース・リカバリ・カタログを所有するデータベース・ユーザーです)。
SQL> EXECUTE base_catalog_owner.DBMS_RCVCAT.DELETE_VIRTUAL_CATALOG;
バックアップおよびリカバリ計画には、リカバリ・カタログ・データベースも含める必要があります。リカバリ・カタログをバックアップしないと、ディスク障害が発生してリカバリ・カタログ・データベースが破損した場合、カタログ内のメタデータが消失する場合があります。リカバリ・カタログの内容がない場合は、その他のデータベースのリカバリがより困難になる可能性があります。
1つのリカバリ・カタログには、複数のターゲット・データベースに関するメタデータを格納できます。したがって、リカバリ・カタログが消失すると、重大な問題が発生する可能性があります。リカバリ・カタログは、頻繁にバックアップしてください。この項では、リカバリ・カタログを保護する計画を作成するための一般的なガイドラインについて説明します。
リカバリ・カタログ・データベースは他のデータベースと同様のデータベースであり、バックアップおよびリカバリ計画に含める必要があります。リカバリ・カタログは、データベースの他の部分と同様にバックアップして保護してください。リカバリ・カタログ・データベースのバックアップは、全体的なバックアップおよびリカバリの一環として計画する必要があります。
リカバリ・カタログのバックアップは、ターゲット・データベースのバックアップと同じ頻度で行います。たとえば、ターゲット・データベース全体のバックアップを週1回行う場合、ターゲット・データベースのバックアップ後にリカバリ・カタログをバックアップします。リカバリ・カタログのこのバックアップは、障害リカバリに役立ちます。制御ファイルの自動バックアップを使用してリカバリ・カタログ・データベースをリストアする必要がある場合も、リストアしたリカバリ・カタログ・データベース内の完全なバックアップ・レコードを使用すると、ターゲット・データベースをリストアできます。
リカバリ・カタログ・データベースのバックアップは、RMANを使用して実行できます。図13-1に示すように、RMANのリポジトリがカタログ・データベースの制御ファイルになるように、NOCATALOGオプションを指定してRMANを起動します。
RMANを使用したリカバリ・カタログ・データベースのバックアップを計画する場合、次のガイドラインに従います。
必要に応じてPoint-in-Timeリカバリを実行できるように、リカバリ・カタログ・データベースをARCHIVELOGモードで実行します。
保存方針として、REDUNDANCY値を1より大きい値に設定します。
データベースを2つの異なるメディア(ディスクとテープなど)にバックアップします。
BACKUP DATABASE PLUS ARCHIVELOGを、使用可能な場合はメディア・マネージャに、メディア・マネージャが使用不可の場合はディスクのみに定期的に実行します。
別のリカバリ・カタログをバックアップのリポジトリに使用しないでください。
制御ファイルの自動バックアップ機能をONに設定します。
この方法では、制御ファイルの自動バックアップ機能によって、この機能が使用可能なかぎり確実にリカバリ・カタログ・データベースがリカバリされます。
リカバリ・カタログは、そのカタログが保護するデータとは別の場所に格納されている場合にのみ有効です。そのため、データベースのRMANリポジトリを含むリカバリ・カタログは、ターゲット・データベースと同じデータベースには格納しないでください。また、カタログ・データベースはターゲット・データベースと同じディスクに格納しないでください。
データの分離をお薦めする理由を説明するために、データベースprod1のカタログをprod1に格納したとします。prod1にメディア全体の障害が発生したときに、prod1のリカバリ・カタログもprod1に格納されていた場合、データベースが消失すると、リカバリ・カタログも同様に消失します。この場合の対応策は1つのみです。リカバリ・カタログに格納されている情報を使用せずに、prod1の制御ファイルの自動バックアップをリストアして使用して、データベースのリストアおよびリカバリを実行する必要があります。
リカバリ・カタログ・データベースのリストアおよびリカバリは、RMANを使用して他のデータベースをリストアおよびリカバリする場合とほぼ同様です。リカバリ・カタログ・データベースの制御ファイルおよびサーバー・パラメータ・ファイルを自動バックアップからリストアし、その後、データベースの残りの部分のリストアおよび完全リカバリを実行できます。複数のリカバリ・カタログを使用している場合、別のリカバリ・カタログを使用して、このリカバリ・カタログ・データベースのバックアップに関するメタデータを記録することもできます。
通常のOracleのリカバリ手順によるリカバリ・カタログ・データベースのリカバリが実行不可能である場合は、カタログを再作成する必要があります。最悪の場合の例を次に示します。
リカバリ・カタログ・データベースを一度もバックアップしていない。
リカバリ・カタログ・データベースをバックアップしているが、データファイルのバックアップまたはアーカイブ・ログが使用不可であるためリカバリできない。
欠落しているリカバリ・カタログの内容を部分的に再作成するには、次の方法があります。
RESYNC CATALOGコマンドを使用して、ターゲット・データベースの制御ファイルまたは制御ファイルのコピーからのRMANリポジトリ情報でリカバリ・カタログを更新します。制御ファイルからエージ・アウトされた制御ファイル・レコードに含まれているメタデータは消失します。
CATALOG START WITH ... コマンドを発行して、使用可能なバックアップをカタログに再度追加します。
この最悪の状況が発生する可能性を最小限に抑えるには、バックアップ計画に少なくともリカバリ・カタログのバックアップを含める必要があります。この方法については、「リカバリ・カタログのバックアップ」を参照してください。
|
関連項目:
|
「ストアド・スクリプト」で説明するように、リカバリ・カタログにスクリプトを格納できます。この項では、ストアド・スクリプトを作成および管理する方法について説明します。
ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連の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;
ストアド・スクリプト(グローバル・スクリプトの場合も)に関連するコマンドを使用するには、リカバリ・カタログとターゲット・データベース・インスタンスの両方に接続する必要があります。
CREATE SCRIPTコマンドを使用すると、ストアド・スクリプトを作成できます。GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在していない必要があります。GLOBALを指定しない場合は、同じターゲット・データベースに対して同じ名前のローカル・スクリプトが存在していない必要があります。また、 REPLACE SCRIPTを使用すると、スクリプトの作成または既存のスクリプトの更新を行うこともできます。
ストアド・スクリプトを作成する手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
次に、ローカル・スクリプトを作成する例を示します。
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';
出力を確認します。
エラーが表示されていない場合、RMANは、スクリプトを正常に作成し、リカバリ・カタログに格納しています。
|
関連項目: RMANの予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
ストアド・スクリプトを更新するには、REPLACE SCRIPTコマンドを使用します。ローカル・スクリプトを置き換える場合は、スクリプトの作成時に接続していたターゲット・データベースに接続する必要があります。スクリプトが存在しない場合、RMANによってスクリプトが作成されます。
ストアド・スクリプトを置き換える手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
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コマンドの構文については、 |
ストアド・スクリプトを実行するには、EXECUTE SCRIPTコマンドを使用します。GLOBALを指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在している必要があります。存在していない場合、RMANはエラーRMAN-06004を戻します。GLOBALを指定しなかった場合は、RMANによって、現行のターゲット・データベースに対して定義されているローカル・ストアド・スクリプトが検索されます。その名前のローカル・スクリプトが見つからなかった場合は、同じ名前のグローバル・スクリプトが検索され、見つかった場合はそのスクリプトが実行されます。
ストアド・スクリプトを実行する手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログ(使用している場合)に接続します。
必要に応じて、SHOWを使用して構成済のチャネルを確認します。
スクリプトは、実行時に構成されていた自動チャネルを使用します。構成済のチャネルを変更する必要がある場合、スクリプトにALLOCATE CHANNELを指定します。RUNブロックが使用されているため、スクリプト内のあるRMANコマンドが正常に実行されなかった場合、スクリプト内の後続のRMANコマンドは実行されません。
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コマンドの構文については、 |
CREATE SCRIPTコマンドでは置換変数を指定できます。コマンドラインでRMANを起動する場合、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をターゲット・データベース(マウントまたはオープンされている必要があります)およびリカバリ・カタログに接続して、リカバリ・カタログ・スクリプトの初期値を指定します。
たとえば、次のコマンドを入力します。
% 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コマンドを使用します。
ストアド・スクリプトを出力する手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
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コマンドの構文については、 |
リカバリ・カタログに定義されたスクリプトの名前を表示するには、LIST ... SCRIPT NAMESコマンドを使用します。RMANがターゲット・インスタンスに接続せずにリカバリ・カタログに接続している場合に使用できるコマンドは、LIST GLOBAL SCRIPT NAMESおよびLIST ALL SCRIPT NAMESのみです。その他の形式のLIST ... SCRIPT NAMESコマンドでは、リカバリ・カタログ接続が必要です。
ストアド・スクリプト名を表示する手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
LIST ... SCRIPT NAMESコマンドを実行します。
たとえば、現在接続しているターゲット・データベースに対して実行可能なすべてのグローバル・スクリプトおよびローカル・スクリプトの名前を表示するには、次のコマンドを実行します。
LIST SCRIPT NAMES;
次の例では、グローバル・スクリプトの名前のみを表示します。
LIST GLOBAL SCRIPT NAMES;
現行のリカバリ・カタログに格納されたすべてのスクリプト(リカバリ・カタログに登録されたすべてのターゲット・データベースのグローバル・スクリプトとローカル・スクリプトを含む)の名前を表示するには、次の形式のコマンドを使用します。
LIST ALL SCRIPT NAMES;
表示された各スクリプトに関して、出力では、定義されたターゲット・データベース(または各スクリプトがグローバルであるかどうか)が示されます。
|
関連項目: LIST SCRIPT NAMESコマンドの構文および出力形式については、 |
リカバリ・カタログからストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPTコマンドを使用します。
ストアド・スクリプトを削除する手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
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コマンドの構文については、 |
RMANクライアントの起動時にリカバリ・カタログ内のストアド・スクリプトを実行するには、RMANクライアントの起動時にSCRIPT引数を指定します。たとえば、次のコマンドを入力してスクリプト/tmp/fbkp.cmdを実行できます。
% rman TARGET / CATALOG rman@catdb SCRIPT '/tmp/fbkp.cmd';
RMANクライアントの起動時には、(ストアド・スクリプトを含む)リカバリ・カタログおよび(スクリプトの実行先の)ターゲット・データベースに接続する必要があります。
ローカル・スクリプトとグローバル・ストアド・スクリプトが同じ名前で定義されている場合、RMANは常にローカル・スクリプトを実行します。
|
関連項目: RMANクライアントのコマンドライン構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
この項では、様々な管理タスクおよびメンテナンス・タスクについて説明します。この項の内容は、次のとおりです。
リカバリ・カタログを作成してターゲット・データベースを登録した後、このカタログをメンテナンスする必要があります。たとえば、RMANメンテナンス・コマンド(第12章「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照)を実行して、バックアップ・レコードの更新および不要なバックアップの削除を行う必要があります。このタイプのメンテナンスは、リカバリ・カタログでRMANを使用するかどうかに関係なく実行する必要があります。リカバリ・カタログ・スキーマのアップグレードなどのその他のタイプのメンテナンスは、リカバリ・カタログでのRMANの使用に固有です。
Data Guard環境でリカバリ・カタログを使用する場合は、カタログに記録されるバックアップおよびデータベース・ファイルに、特別な考慮事項が適用されます。RMANでバックアップにアクセスできるタイミング、およびアクセス可能なバックアップに対するRMANメンテナンス・コマンドの動作については、「Data Guard環境でのRMANによるファイル管理」を参照してください。
RMANは、再同期化を実行する際に、リカバリ・カタログと、ターゲット・データベースの現行の制御ファイルまたはバックアップ制御ファイルを比較し、欠落したメタデータまたは変更されたメタデータを追加してカタログを更新します。ほとんどのRMANコマンドは、ターゲット制御ファイルがマウントされ、カタログが使用可能になると、再同期化を自動的に実行します。Data Guard環境では、RMANは逆再同期化を実行して、カタログのメタデータでデータベース制御ファイルを更新できます。
リカバリ・カタログを再同期化すると、RMANが制御ファイルから取得するメタデータが常に最新に保たれます。再同期化には、完全再同期化と部分再同期化があります。
部分再同期化では、RMANはターゲット・データベースの現行の制御ファイルを読み取って、新しいバックアップ、新しいアーカイブREDOログなどに関する変更されたメタデータを更新します。RMANは、データベースの物理スキーマに関するメタデータは再同期化しません。
完全再同期化では、RMANは、データベース・スキーマのレコードを含め、変更されたすべてのレコードを更新します。RMANは、データベースに構造変更(データベース・ファイルの追加または削除、新しいインカネーションの作成など)を行った後またはRMANの永続的な構成を変更した後に完全再同期化を実行します。
RMANは、完全再同期化の実行時に、一時的なバックアップ制御ファイルであるスナップショット制御ファイルを作成します。データベースでは、あるスナップショット制御ファイルにアクセスするRMANセッションが一度に1つのみに制限されます。RMANは、ターゲット・データベース・ホスト上のオペレーティング・システム固有の場所にスナップショット制御ファイルを作成します。スナップショット制御ファイルの名前および場所は、「スナップショット制御ファイルの場所の構成」の説明に従って指定できます。
このスナップショット制御ファイルによって、RMANは制御ファイルの一貫性ビューを持つことができます。制御ファイルは短期の使用を目的としているため、カタログには登録されません。RMANは、制御ファイルのチェックポイントをリカバリ・カタログに記録して、そのカタログが記録された時点を示します。
|
関連項目: RESYNCコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 |
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概要および管理』 |
RMANがターゲット・データベースおよびリカバリ・カタログに接続しているときにRMANコマンドを実行すると、RMANは自動的にリカバリ・カタログを再同期化します。そのため、RESYNC CATALOGコマンドを手動で実行する必要がある機会はあまり多くありません。次の項では、カタログの再同期化を手動で実行する必要がある場合について説明します。
部分再同期化を実行するRMANコマンドの発行時にリカバリ・カタログが使用不可であった場合、後でカタログ・データベースをオープンして、RESYNC CATALOGコマンドを使用して手動で再同期化します。
たとえば、ターゲット・データベースがニューヨークに存在し、リカバリ・カタログが日本に存在するとします。地理的に離れたデータベースの可用性に依存しないようにするため、CATALOGモードのターゲット・データベースの日次バックアップは行わないことにします。このような場合、実行可能な頻度でカタログに接続し、RESYNC CATALOGコマンドを実行します。
ターゲット・データベースがARCHIVELOGモードで実行されていると想定します。また、次の操作を実行すると想定します。
データベースを低い頻度でバックアップします(たとえば、REDOログが100個アーカイブされるごとにデータベースをアーカイブします)。
毎日多数のログ・スイッチが発生します(たとえば、スイッチが1000回発生するごとにカタログを再同期化します)。
この場合、REDOログ・スイッチの発生時またはREDOログのアーカイブ時にリカバリ・カタログが自動的に更新されないため、リカバリ・カタログを定期的に手動で再同期化する必要があります。データベースでは、REDOログ・スイッチおよびアーカイブREDOログに関するメタデータは制御ファイルにのみ格納されます。定期的に再同期化を実行して、この情報をリカバリ・カタログに伝播する必要があります。
リカバリ・カタログの再同期化の頻度は、データベースがREDOログをアーカイブする頻度によって異なります。 この操作のコストは、制御ファイル内の、最後の再同期化以降に挿入または変更されたレコードの数に比例します。挿入または変更されたレコードがない場合、再同期化のコストは非常に低くなります。多くのレコードが挿入または変更された場合、再同期化にかかる時間が長くなります。
スタンバイ・データベースにTARGETとして接続されていない場合でも、このデータベースに対してRMAN構成の作成または変更を行うことができます。このタスクは、CONFIGURE DB_UNIQUE_NAMEまたはCONFIGURE ... FOR DB_UNIQUE_NAMEコマンドを使用して実行します。「リカバリ・カタログの手動での再同期化」で説明されているように、スタンバイ・データベースを手動で再同期化して、スタンバイ・データベースの制御ファイルを更新できます。
リカバリ・カタログ内のメタデータは、常に最新の状態にしておく必要があります。リカバリ・カタログはターゲット制御ファイルからメタデータを取得するため、カタログ内のデータが最新の状態かどうかは、制御ファイル内のデータが最新の状態かどうかによって決まります。制御ファイル内のバックアップ・メタデータが、新しいレコードで上書きされる前にカタログに記録されていることを確認する必要があります。
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の値を減らし、再同期化の頻度を高くします。
|
関連項目:
|
ターゲット・データベースの制御ファイルを使用してリカバリ・カタログの完全再同期化を強制実行するには、RESYNC CATALOGを使用します。Data Guard環境で特定のデータベースを再同期化するか、またはすべてのデータベースを再同期化するかに応じて、RESYNC FROM DB_UNIQUE_NAMEまたはALLを使用してデータベースの一意の名前を指定できます。通常、この操作は、スタンバイ・データベースに対するCONFIGUREコマンドを実行した後、そのスタンバイ・データベースに接続していない場合に実行します。
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。
ターゲット・データベースをマウントまたはオープンします。
STARTUP MOUNT;
リカバリ・カタログを再同期化します。
RMANプロンプトで、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で、プライマリ・データベースではなく、スタンバイ・データベースにRMANをTARGETとして接続する点は異なります。
DB_UNIQUE_NAMEを変更した後にリカバリ・カタログを更新する手順
RMANを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;
RMANメタデータ内のDB_UNIQUE_NAMEを変更します。
次の例では、データベースの一意の名前をスタンバイ・データベースprodsf1からprodsf2に変更します。
RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;
UNREGISTER DATABASEコマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。データベースがリカバリ・カタログから登録解除されると、RMANのすべてのリポジトリ・レコードが消失します。データベースは再度登録できますが、このデータベースのリカバリ・カタログ・レコードは、再登録時の制御ファイルの内容に基づきます。ターゲット・データベースの制御ファイル内のCONTROLFILE_RECORD_KEEP_TIME設定より古いレコードは消失します。また、制御ファイルに格納されていないストアド・スクリプトも消失します。
この例では、リカバリ・カタログを使用せずにプライマリ・データベースとスタンバイ・データベースのメタデータを格納すると想定しています。
データベースの登録を解除する手順
RMANを起動し、登録を解除するデータベースにTARGETとして接続します。リカバリ・カタログにも接続します。
ターゲット・データベースに接続する必要はありませんが、接続しない場合は、UNREGISTERコマンドでターゲット・データベースの名前を指定する必要があります。リカバリ・カタログで複数のデータベースに同じ名前がある場合は、コマンドを囲むようにRUNブロックを作成し、SET DBIDを使用してデータベースのDBIDを設定する必要があります。
起動時に、RMANによって表示されたDBIDを書き留めます。
たとえば、RMANは、オープンしているターゲット・データベースに接続した場合、次の形式の行を出力します。
connected to target database: PROD (DBID=39525561)
念のため、LIST BACKUP SUMMARYおよびLIST COPY SUMMARYを使用して、リカバリ・カタログに記録されているすべてのバックアップを表示すると役に立つ場合があります。この場合、後でデータベースを再登録するときに、制御ファイルで認識されないバックアップをカタログに再度追加できます。
データベースのすべてのバックアップを実際に削除する場合は、DELETE文を実行して、既存のすべてのバックアップを削除します。データベースをリカバリ・カタログから削除し、制御ファイルを使用してこのデータベースのRMANメタデータを格納する場合は、すべてのバックアップは削除しないでください。
次のコマンドは、バックアップの削除方法を示しています。
DELETE BACKUP DEVICE TYPE sbt; DELETE BACKUP DEVICE TYPE DISK; DELETE COPY;
RMANによって、削除されるバックアップが表示され、それらの削除前に確認するように求められます。
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
UNREGISTERコマンドでは、Data Guard環境での使用のためにDB_UNIQUE_NAME句がサポートされています。この句を使用すると、特定のデータベースのメタデータを削除できます。
リカバリ・カタログによって、バックアップは特定のデータベースに関連付けられます。データベースの登録を解除すると、RMANは、これらのバックアップ・ファイルのデータベース名をNULLに更新します。そのため、バックアップは記録されていますが、バックアップの所有者は存在しなくなります。CHANGE ... RESET DB_UNIQUE_NAMEコマンドを実行すると、現在所有者が存在しないバックアップの所有権を別のデータベースに関連付けることができます。UNREGISTERコマンドにINCLUDING BACKUPSを指定した場合、RMANは、登録を解除されたデータベースのバックアップ・メタデータも削除します。
この例では、プライマリ・データベースlnx3に、関連付けられたスタンバイ・データベースstandbyがあると想定しています。このスタンバイ・データベースの登録を解除します。
スタンバイ・データベースの登録を解除する手順
RMANを起動し、TARGETとしてプライマリ・データベースに接続します。また、リカバリ・カタログにもRMANを接続します。
たとえば、次のコマンドを入力します。
% 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;
RMANにデータベース名および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
プロセスが完了すると、RMANは次のメッセージを出力します。
database with db_unique_name standby unregistered from the recovery catalog
「データベース・インカネーション」で説明されているように、RESETLOGSオプションでデータベースをオープンする際にデータベースのインカネーションを作成します。新しいインカネーションのレコードには、V$DATABASE_INCARNATIONビューでアクセスできます。
RESETLOGSオプションでデータベースをオープンすると、新しいデータベース・インカネーション・レコードがリカバリ・カタログ内に自動的に作成されます。また、データベースによって暗黙的かつ自動的にRESET DATABASEコマンドが発行され、このデータベースの新しいインカネーションが現行のインカネーションであることが指定されます。ターゲット・データベースによって実行される後続のすべてのバックアップおよびログのアーカイブは、新しいデータベース・インカネーションに関連付けられます。
RMANで、RESTOREとRECOVER、またはFLASHBACK DATABASEのいずれかを使用してデータベースを現行のRESETLOGS SCNより前のSCNに戻す場合は、常にRESET DATABASE TO INCARNATIONコマンドを実行する必要があります。ただし、RMANではフラッシュバックで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;
以前のインカネーションの制御ファイルが使用可能でマウントされている場合、手順6にスキップします。そうでない場合、データベースを停止して、NOMOUNTモードで起動します。次に例を示します。
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の構文については、 |
この項では、リカバリ・カタログのアップグレードおよびアップグレードの実行が必要となるタイミングについて説明します。
RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。RMANのバージョンと互換性があるスキーマ・バージョンについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表を参照してください。たとえば、Oracle Database 11gのRMANクライアントでリリース10.2のリカバリ・カタログ・スキーマを使用する場合、そのカタログをアップグレードする必要があります。
Oracle Database 10gR1バージョンのリカバリ・カタログ・スキーマには、CREATE TYPE権限が必要です。10gR1より前のリリースでリカバリ・カタログの所有者を作成し、CREATE TYPE権限が含まれていないRECOVERY_CATALOG_OWNERロールを付与した場合は、カタログのアップグレードの前に、明示的にこの所有者にCREATE TYPEを付与する必要があります。
RMANクライアントで要求されるバージョンより新しいバージョンのリカバリ・カタログを使用している場合、UPGRADE CATALOGを発行するとエラーが表示されます。RMANでは、リカバリ・カタログが現行のバージョンでアップグレードが必要ない場合でもUPGRADE CATALOGコマンドを実行できます。このコマンドを実行すると、必要に応じていつでもパッケージを再作成できます。アップグレード中に生成されたエラー・メッセージを、メッセージ・ログで確認してください。
Data Guard環境で、リカバリ・カタログ・スキーマをOracle Database 11gにアップグレードすると想定します。RMANは、スタンバイ・データベースに接続する際に、新しいデータベース情報を自動的に登録し、再同期化してファイル名を制御ファイルから取得します。
再同期化中に、RMANは名前をターゲット・データベース名に関連付けます。リカバリ・カタログには、履歴メタデータが含まれているため、制御ファイルで認識されないレコードもあります。たとえば、standby1制御ファイルでは、primary1に作成されたすべてのバックアップについては認識されません。これらの古いレコードのデータベースの一意の名前はNULLです。「リカバリ・カタログのメンテナンス」で説明されているように、CROSSCHECKを使用してこれらのレコードを修正できます。
リカバリ・カタログのスキーマ・バージョンは、リカバリ・カタログ自体に格納されます。この情報は、本番システムにバージョンの異なる複数のデータベースが存在し、カタログのスキーマ・バージョンが特定のターゲット・データベース・バージョンで使用可能かどうかを確認する必要がある場合に重要です。
リカバリ・カタログのスキーマ・バージョンを確認する手順
SQL*Plusを起動し、カタログ所有者としてリカバリ・カタログ・データベースに接続します。
RCVER表を問い合せてスキーマ・バージョンを取得します。次に、コマンドと出力の例を示します。
SELECT * FROM rcver; VERSION ------------ 10.02.00
RCVER表に複数の行が表示される場合、この表内で最上位のバージョンが、現行のカタログ・スキーマ・バージョンです。この表に格納されるのはメジャー・バージョン番号のみであり、パッチ番号は格納されません。たとえば、rcver表に次の行が表示されたと想定します。
VERSION ------------ 08.01.07 09.00.01 10.02.00
これらの行は、カタログがリリース8.1.7の実行可能ファイルによって作成され、リリース9.0.1にアップグレードされ、最後にリリース10.2.0にアップグレードされたことを示しています。カタログ・スキーマの現行バージョンは10.2.0です。
|
関連項目: RMAN環境で適用される互換性規則の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
この例では、リカバリ・カタログ・スキーマを現行のバージョンにアップグレードすると想定しています。
リカバリ・カタログをアップグレードする手順
10gR1より前のリリースでリカバリ・カタログの所有者を作成し、RECOVERY_CATALOG_OWNERロールにCREATE TYPE権限が含まれていなかった場合は、これを付与します。
たとえば、SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースに接続します。これによって、次のGRANT文を実行できます。
SQL> GRANT CREATE TYPE TO rman; SQL> EXIT;
RMANを起動し、リカバリ・カタログ・データベースにRMANを接続します。
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
|
関連項目:
|
RMANでIMPORT CATALOGコマンドを使用して、1つのリカバリ・カタログ・スキーマを別のリカバリ・カタログ・スキーマにマージできます。このコマンドは、次の場合に有効です。
様々なバージョンのデータベースに対して複数のリカバリ・カタログ・スキーマが存在する場合。バックアップ・メタデータを失わずに、既存のすべてのスキーマを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のパターンを繰り返します。
『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表に示されているように、ターゲット・データベース、リカバリ・カタログ・データベースおよびリカバリ・カタログ・スキーマのデータベース・バージョンが異なっている場合があります。最新のバージョンのリカバリ・カタログ・スキーマで、既存のすべてのリカバリ・カタログを1つのリカバリ・カタログにインポートすることをお薦めします。カタログのバージョンを確認する方法については、「リカバリ・カタログのスキーマ・バージョンの確認」を参照してください。互換性の表を確認し、使用している環境内で互換性があるスキーマ・バージョンを判別します。
IMPORT CATALOGを使用する場合、ソース・リカバリ・カタログ・スキーマのバージョンは、このコマンドの実行に使用するRMAN実行可能ファイルの現行のバージョンと一致している必要があります。ソース・カタログ・スキーマのバージョンのほうが低い場合は、スキーマをインポートする前に現行のバージョンにアップグレードします。アップグレード方法については、「リカバリ・カタログのアップグレード」を参照してください。ソース・リカバリ・カタログ・スキーマのバージョンのほうが高い場合は、より高いバージョンのRMAN実行可能ファイルを使用してインポートを再試行します。
ソース・カタログ・スキーマと宛先カタログ・スキーマの両方にデータベースを登録することはできません。現在、データベースが両方のカタログ・スキーマに登録されている場合は、インポートを実行する前にソース・カタログ・スキーマからデータベースを登録解除します。
リカバリ・カタログを別のリカバリ・カタログにインポートする場合、ターゲット・データベースへの接続は必要ありません。RMANは、ソース・カタログおよび宛先カタログにのみ接続する必要があります。
次の例では、データベースsrcdbにユーザー102catが所有する10.2リカバリ・カタログ・スキーマが含まれており、データベースdestdbにユーザー111catが所有する11.1リカバリ・カタログ・スキーマが含まれています。
リカバリ・カタログをインポートする手順
RMANを起動し、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つのデータベースを登録解除する場合には使用しないことをお薦めします。リカバリ・カタログを削除すると、そのカタログに登録されたすべてのターゲット・データベースのバックアップのリカバリ・カタログ・レコードが削除されます。
リカバリ・カタログ・スキーマを削除する手順
RMANを起動し、ターゲット・データベースおよびリカバリ・カタログに接続します。削除するカタログ・スキーマの所有者として、リカバリ・カタログに接続します。
次の例では、ユーザー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;
|
注意: リカバリ・カタログを削除しても、制御ファイルにはバックアップに関するレコードが含まれたままです。RMANリポジトリ・レコードを制御ファイルから消去するには、制御ファイルを再作成します。 |
|
関連項目: DROP CATALOGコマンドの構文については、 |
