この章では、RMANリカバリ・カタログを管理する方法について説明します。このカタログは、1つ以上のターゲット・データベースのRMANリポジトリ・データが含まれているデータベース・スキーマです。この章の内容は次のとおりです。
関連項目:
リカバリ・カタログを使用せずに、制御ファイルに格納されているRMANリポジトリを管理する方法については、「RMANバックアップおよびリポジトリ・レコードのメンテナンス」を参照してください。
サポートされている相互運用の例は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表を参照してください。
この項では、リカバリ・カタログの管理に関連する基本的な概念について説明します。
リカバリ・カタログとは、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
のrco
が所有する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操作に関するレポート」を参照してください。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メンバー) |
注意:
リカバリ・カタログとターゲット・データベースが同じディスク上に存在していないことを確認してください。リカバリ・カタログとターゲット・データベースの両方にハード・ディスク障害が発生した場合、リカバリ・プロセスがより困難になります。可能な場合、他の手段を利用し、リカバリ・カタログ・データベースとバックアップ対象のデータベースの共通の致命的な障害箇所を排除してください。
リカバリ・カタログ・データベースを選択して必要な領域を作成した後、リカバリ・カタログの所有者を作成し、そのユーザーに必要な権限を付与します。後続の項に示す手順では、次の状況を想定しています。
ユーザーSBU
は、catdb
リカバリ・カタログ・データベースに対するSYSBACKUP
権限を持っています。
CATDB
リカバリ・カタログ・データベース内のTOOLS
という表領域にリカバリ・カタログが格納されています。RMANの予約語を表領域名として使用する場合、その語を引用符で囲み、大文字を使用する必要があります。
関連項目:
RMANの予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
TEMP
という表領域が、リカバリ・カタログ・データベース内に存在します。
リカバリ・カタログ・データベース内にリカバリ・カタログ・スキーマを作成する手順
カタログ所有者の作成後、RMANのCREATE
CATALOG
コマンドを使用してカタログ表を作成します。このコマンドを実行すると、カタログ所有者のデフォルト表領域内にカタログが作成されます。
注意:
Oracle Database 12cリリース1 (12.1.0.2)以降、リカバリ・カタログ・データベースではOracle DatabaseのEnterprise Editionを使用する必要があります。リカバリ・カタログを作成する手順
関連項目:
GRANT
およびCREATE
USER
文のSQL構文については、『Oracle Database SQL言語リファレンス』を参照してください。
CREATE
CATALOG
コマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この項では、リカバリ・カタログでターゲット・データベース・レコードをメンテナンスする方法について説明します。この章の内容は、次のとおりです。
リカバリ・カタログにターゲット・データベースを記載するプロセスを登録と呼びます。ターゲット・データベースがリカバリ・カタログに登録されていない場合、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は、対応するプライマリ・データベースが登録されていれば、このスタンバイ・データベースを自動的に登録します。
関連項目:
DUPLICATEコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
DBNEWID
ユーティリティを使用してDBIDを変更する方法については、『Oracle Databaseユーティリティ』を参照してください。
Data Guard環境でのRMANの使用方法については、『Oracle Data Guard概要および管理』を参照してください。
データファイルのコピー、バックアップ・ピースまたはアーカイブ・ログがディスクに存在する場合、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/';
関連項目:
REGISTERの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
データベースの移行に関する問題については、『Oracle Databaseアップグレード・ガイド』を参照してください。
この項の内容は、次のとおりです。
デフォルトでは、RMANのリカバリ・カタログの全ユーザーは、カタログのすべてのメタデータを読取り、選択、挿入、更新および削除する完全な権限を持ちます。たとえば、2つの関連のないデータベースの管理者が同じリカバリ・カタログを共有している場合、各管理者は、誤ってまたは意図的に、もう一方の管理者のデータベース用のカタログ・データを破壊することができます。多くの企業では、同じ担当者が多くの異なるデータベースを管理し、そのリカバリ・カタログも管理するため、この状況が許容されています。ただし、その他の企業では、様々なデータベースの管理者の間、およびDBAとリカバリ・カタログの管理者の間に、明確な責務の分離が存在しており、このような企業では、各データベース管理者が、担当のデータベースに属するバックアップ・メタデータのみを変更するように制限すると同時に、単一の中央管理されたRMANリカバリ・カタログによるメリットも保つ必要がある場合があります。 この目的は、仮想プライベート・カタログを実装することによって達成できます。
Oracle Database 11g以降のすべてのRMANリカバリ・カタログは、仮想プライベート・カタログをサポートしていますが、仮想プライベート・カタログは、明示的に作成しないと使用されません。1つのリカバリ・カタログに対して作成できる仮想プライベート・カタログの数に、制限はありません。各仮想プライベート・カタログは、データベース・スキーマのユーザーによって所有されます。このユーザーは、リカバリ・カタログを所有するユーザーとは異なります。
仮想プライベート・カタログ・ユーザーを設定後、リカバリ・カタログの管理者は、各仮想プライベート・カタログに対して、リカバリ・カタログに現在登録されている1つ以上のデータベースにそのカタログを使用する権限を付与します。リカバリ・カタログの管理者は、仮想プライベート・カタログの使用中に新しいデータベースを登録する権限を付与することもできます。
注意:
各仮想プライベート・カタログは、すべてのグローバル・ストアド・スクリプト、および仮想プライベート・カタログが権限を持つデータベースに属する非グローバル・ストアド・スクリプトにアクセスできます。 仮想プライベート・カタログは、権限を持たないデータベースに属する非グローバル・ストアド・スクリプトにはアクセスできません。また、グローバル・ストアド・スクリプトを作成することはできません。
仮想プロバイダ・カタログを作成および管理するプロセスは、使用しているOracle Databaseのバージョンによって異なります。
Oracle Database 12cリリース1 (12.1.0.1)を使用して仮想プライベート・カタログを作成および管理するには、「Oracle Database 12cリリース1 (12.1.0.1)を使用した仮想プライベート・カタログの作成および管理」の手順を使用します。
Oracle Database 12cリリース1 (12.1.0.2)を使用して仮想プライベート・カタログを作成するには、「Oracle Database 12cリリース1 (12.1.0.2)を使用した仮想プライベート・カタログの作成および管理」に示されている手順を使用します。
Oracle Database 12cリリース1 (12.1.0.1)以前を使用して作成された既存の仮想プライベート・カタログを移行するには、「仮想プライベート・カタログのOracle Database 12cリリース1 (12.1.0.2)へのアップグレード」に示されている手順を使用して、これらの仮想プライベート・カタログをOracle Database 12cリリース1 (12.1.0.2)にアップグレードする必要があります。
「仮想プライベート・カタログを作成する手順」に示されている手順を使用して、1つ以上の仮想プライベート・カタログを作成します。
仮想プライベート・カタログの作成後に、必要に応じてカタログ・アクセス権限を取り消すことができます。このタスクについては、「仮想プライベート・カタログ所有者からの権限の取消し」を参照してください。仮想プライベート・カタログを削除する方法については、「仮想プライベート・カタログの削除」を参照してください。
リカバリ・カタログが仮想プライベート・カタログの場合、これに接続しているRMANクライアントは、パッチ・レベル10.1.0.6または10.2.0.3である必要があります。Oracle9iのRMANクライアントは、仮想プライベート・カタログに接続できません。ベース・カタログに仮想プライベート・カタログ・ユーザーが含まれている場合でも、Oracle Database 11gのベース・リカバリ・カタログへのRMANクライアントの接続は、このバージョン制限の影響を受けません。
関連項目:
RMANのバージョン互換性の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この項では、ベース・リカバリ・カタログは作成済であると想定しています。
データベースprod1
、prod2
およびprod3
がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログを所有するデータベース・ユーザーはrco
です。データベース・ユーザーvpc1
を作成し、このユーザーにprod1
およびprod2
のみへのアクセス権限を付与します。デフォルトでは、仮想プライベート・カタログ所有者にベース・リカバリ・カタログへのアクセス権限はありません。
仮想プライベート・カタログ所有者を作成し、権限を付与する手順
この項では、仮想プライベート・カタログ所有者にCREATE SESSION
権限が付与されていると想定しています。また、ベース・リカバリ・カタログ所有者がGRANT
コマンドを使用して、ベース・リカバリ・カタログ内のメタデータへのアクセス権限を仮想プライベート・カタログ所有者に付与しています。
仮想プライベート・カタログを作成する手順
この項では、仮想プライベート・カタログを作成していると想定しています。
2つのデータベースprod1
およびprod2
がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログの所有者として、vpc1
ユーザーにprod1
へのアクセス権限を付与しています。また、このユーザーには、仮想プライベート・カタログにデータベースを登録する権限も付与しています。ここで、vpc1
から権限を取り消します。
仮想プライベート・カタログ所有者から権限を取り消す手順
「Oracle Database 12cリリース1 (12.1.0.2)を使用した仮想プライベート・カタログの作成」に示されている手順を使用して、仮想プライベート・カタログを作成します。
仮想プライベート・カタログの設定後に、必要に応じてカタログ・アクセス権限を取り消すことができます。このタスクについては、「仮想プライベート・カタログ所有者からの権限の取消し」を参照してください。
仮想プライベート・カタログを削除するには、その仮想プライベート・カタログを所有するデータベース・ユーザーに付与されているすべての権限を取り消す必要があります。仮想プライベート・カタログ所有者に権限がなくなると、仮想プライベート・カタログは自動的に削除されます。DROP USER
コマンドを実行して、仮想プライベート・カタログ所有者を引き続き削除できます。
注意:
Oracle Database 12cリリース1 (12.1.0.2)以降、仮想プライベート・カタログはOracle Database Enterprise Editionを使用する場合のみ使用できます。Standard Editionでは、この機能はサポートされません。
この項では、ベース・リカバリ・カタログは作成済であると想定しています。
データベースprod1
、prod2
およびprod3
がベース・リカバリ・カタログに登録されていると想定します。ベース・リカバリ・カタログを所有するデータベース・ユーザーはrco
です。データベース・ユーザーvpc1
を作成し、このユーザーにprod1
およびprod2
のみへのアクセス権限を付与します。次に、vpc1
が所有する仮想プライベート・カタログに接続し、データベースprod1
を仮想プライベート・カタログに登録し、仮想プライベート・カタログにprod1
のバックアップ・メタデータを格納します。
仮想プライベート・カタログ所有者を作成し、権限を付与する手順
SQL*Plusを起動し、管理者権限でリカバリ・カタログ・データベースに接続します。
仮想プライベート・カタログを所有するユーザーを作成します。
たとえば、データベース・ユーザーvpc1
に仮想プロバイダ・カタログを所有させる場合、次のコマンドを実行します(passwordをユーザー定義パスワードに置換します)。
SQL> CREATE USER vpc1 IDENTIFIED BY password
2 DEFAULT TABLESPACE vpcusers
3 QUOTA UNLIMITED ON vpcusers;
注意:
安全なパスワードを作成してください。詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
CREATE SESSION
権限をユーザーに付与してから、SQL*Plusを終了します。
次の構文例では、ユーザーvpc1
にCREATE SESSION
権限を付与します。
SQL> GRANT CREATE SESSION TO vpc1; SQL> EXIT;
RMANを起動し、(仮想プライベート・カタログ所有者ではなく)ベース・リカバリ・カタログ所有者としてリカバリ・カタログ・データベースに接続します。
次の例では、rco
としてベース・リカバリ・カタログに接続します。
% rman
RMAN> CONNECT CATALOG rco@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;
データベースを仮想プライベート・カタログに登録してバックアップ・メタデータを格納するには、次の手順を実行します。
Oracle Database 12cリリース1 (12.1.0.2)以降、RMANでは仮想プライベート・データベース(VPD)機能を使用して仮想プライベート・カタログを実装します。仮想プライベート・カタログを所有するデータベース・ユーザーに付与する必要がある唯一の権限は、CREATE SESSION
権限です。Oracle Database 12cリリース1 (12.1.0.2)より前のバージョンを使用してリカバリ・カタログと仮想プライベート・カタログを作成した場合、これらの仮想プライベート・カタログをアップグレードする必要があります。RMANでは、仮想プライベート・カタログをアップグレードするためのスクリプトが$ORACLE_HOME
/rdbms/admin
ディレクトリに用意されています。
既存の仮想プライベート・カタログをOracle Database 12cリリース1 (12.1.0.2)にアップグレードするには:
バックアップおよびリカバリ計画には、リカバリ・カタログ・データベースも含める必要があります。リカバリ・カタログをバックアップしないと、ディスク障害が発生してリカバリ・カタログ・データベースが破損した場合、カタログ内のメタデータが消失する場合があります。リカバリ・カタログの内容がない場合は、その他のデータベースのリカバリがより困難になる可能性があります。
この項の内容は、次のとおりです。
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 ...
コマンドを発行して、使用可能なバックアップをカタログに再度追加します。
この最悪の状況が発生する可能性を最小限に抑えるには、バックアップ計画に少なくともリカバリ・カタログのバックアップを含める必要があります。この方法については、「リカバリ・カタログのバックアップ」を参照してください。
関連項目:
CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
CROSSCHECKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
「ストアド・スクリプト」で説明するように、リカバリ・カタログにスクリプトを格納できます。この項では、ストアド・スクリプトを作成および管理する方法について説明します。
この項の内容は、次のとおりです。
ストアド・スクリプトは、制御ファイルの代替として、頻繁に使用する一連の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の予約語のリストは、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
ストアド・スクリプトを実行するには、EXECUTE SCRIPT
コマンドを使用します。GLOBAL
を指定する場合は、この名前のグローバル・スクリプトがリカバリ・カタログ内に存在している必要があります。存在していない場合、RMANはエラーRMAN-06004
を戻します。GLOBAL
を指定しなかった場合は、RMANによって、現行のターゲット・データベースに対して定義されているローカル・ストアド・スクリプトが検索されます。その名前のローカル・スクリプトが見つからなかった場合は、同じ名前のグローバル・スクリプトが検索され、見つかった場合はそのスクリプトが実行されます。
ストアド・スクリプトを実行する手順
関連項目:
EXECUTE
SCRIPT
コマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
リカバリ・カタログに定義されたスクリプトの名前を表示するには、LIST ... SCRIPT NAMES
コマンドを使用します。RMANがターゲット・インスタンスに接続せずにリカバリ・カタログに接続している場合に使用できるコマンドは、LIST GLOBAL SCRIPT NAMES
およびLIST ALL SCRIPT NAMES
のみです。その他の形式のLIST ... SCRIPT NAMES
コマンドでは、リカバリ・カタログ接続が必要です。
ストアド・スクリプト名を表示する手順
関連項目:
LIST
SCRIPT NAMES
コマンドの構文および出力形式については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
リカバリ・カタログからストアド・スクリプトを削除するには、DELETE GLOBAL SCRIPT
コマンドを使用します。
ストアド・スクリプトを削除する手順
関連項目:
DELETE
SCRIPT
コマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
RMANクライアントの起動時にリカバリ・カタログ内のストアド・スクリプトを実行するには、RMANクライアントの起動時にSCRIPT
引数を指定します。たとえば、次のコマンドを入力してスクリプト/tmp/fbkp.cmd
を実行できます。
% rman TARGET / CATALOG rco@catdb SCRIPT '/tmp/fbkp.cmd';
RMANクライアントの起動時には、(ストアド・スクリプトを含む)リカバリ・カタログおよび(スクリプトの実行先の)ターゲット・データベースに接続する必要があります。
ローカル・スクリプトとグローバル・ストアド・スクリプトが同じ名前で定義されている場合、RMANは常にローカル・スクリプトを実行します。
関連項目:
RMANクライアントのコマンドライン構文の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この項では、様々な管理タスクおよびメンテナンス・タスクについて説明します。この項の内容は、次のとおりです。
リカバリ・カタログを作成してターゲット・データベースを登録した後、このカタログをメンテナンスする必要があります。たとえば、RMANメンテナンス・コマンド(「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
の値を減らし、再同期化の頻度を高くします。
関連項目:
CONTROL_FILE_RECORD_KEEP_TIMEパラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
制御ファイル管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
制御ファイル・レコードの上書きを監視する方法については、「制御ファイル・レコードの消失の防止」を参照してください。
ターゲット・データベースの制御ファイルを使用してリカバリ・カタログの完全再同期化を強制実行するには、RESYNC
CATALOG
を使用します。Data Guard環境で特定のデータベースを再同期化するか、またはすべてのデータベースを再同期化するかに応じて、RESYNC CATALOG FROM DB_UNIQUE_NAME
またはALL
を使用してデータベースの一意の名前を指定できます。DB_UNIQUE_NAME ALL
を使用するには、パスワード・ファイル認証を使用してSYS
ユーザーとしてターゲット・データベースに接続する必要があります。通常、この操作は、スタンバイ・データベースに対するCONFIGURE
コマンドを実行した後、そのスタンバイ・データベースに接続していない場合に実行します。
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を変更した後にリカバリ・カタログを更新する手順
UNREGISTER DATABASE
コマンドを使用すると、リカバリ・カタログからデータベースの登録を解除できます。データベースがリカバリ・カタログから登録解除されると、RMANのすべてのリポジトリ・レコードが消失します。データベースは再度登録できますが、このデータベースのリカバリ・カタログ・レコードは、再登録時の制御ファイルの内容に基づきます。ターゲット・データベースの制御ファイル内のCONTROLFILE_RECORD_KEEP_TIME
設定より古いレコードは消失します。また、制御ファイルに格納されていないストアド・スクリプトも消失します。
この項の内容は、次のとおりです。
この例では、リカバリ・カタログを使用せずにプライマリ・データベースとスタンバイ・データベースのメタデータを格納すると想定しています。
データベースの登録を解除する手順
UNREGISTER
コマンドでは、Data Guard環境での使用のためにDB_UNIQUE_NAME
句がサポートされています。この句を使用すると、特定のデータベースのメタデータを削除できます。
リカバリ・カタログによって、バックアップは特定のデータベースに関連付けられます。データベースの登録を解除すると、RMANは、これらのバックアップ・ファイルのデータベース名をNULL
に更新します。そのため、バックアップは記録されていますが、バックアップの所有者は存在しなくなります。CHANGE ... RESET DB_UNIQUE_NAME
コマンドを実行すると、現在所有者が存在しないバックアップの所有権を別のデータベースに関連付けることができます。UNREGISTER
コマンドにINCLUDING BACKUPS
を指定した場合、RMANは、登録を解除されたデータベースのバックアップ・メタデータも削除します。
この例では、プライマリ・データベースlnx3
に、関連付けられたスタンバイ・データベースstandby1
があると想定しています。このスタンバイ・データベースの登録を解除します。
スタンバイ・データベースの登録を解除する手順
Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)環境では、UNREGISTER DATABASE
コマンドを使用してリカバリ・アプライアンス・カタログから保護されたデータベースを登録解除することはできません。かわりに、DBMS_RA.DELETE_DB
プロシージャを使用します。
リカバリ・アプライアンス・リカバリ・カタログからターゲット・データベースの登録を解除するには、次の手順を実行します。
関連項目:
DBMS_RA.DELETE_DB
プロシージャの詳細は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。
「データベース・インカネーションについて」で説明されているように、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
を使用してリカバリする場合にデータベース・インカネーションをリセットする方法について説明します。
リカバリ・カタログをメディア・リカバリの古いインカネーションにリセットする手順
Oracle Database 12cリリース1 (12.1.0.2)にアップグレードする場合、リカバリ・カタログ・データベースではOracle DatabaseのEnterprise Editionを使用する必要があります。
RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。RMANのバージョンと互換性があるスキーマ・バージョンについては、『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表を参照してください。たとえば、Oracle Database 11gのRMANクライアントでリリース10.2のリカバリ・カタログ・スキーマを使用する場合、そのカタログをアップグレードする必要があります。
Oracle Database 10gリリース1バージョンのリカバリ・カタログ・スキーマには、CREATE TYPE
権限が必要です。10gR1より前のリリースでリカバリ・カタログの所有者を作成し、CREATE TYPE
権限が含まれていないRECOVERY_CATALOG_OWNER
ロールを付与した場合は、カタログのアップグレードの前に、明示的にこの所有者にCREATE TYPE
を付与する必要があります。
RMANクライアントで要求されるバージョンより新しいバージョンのリカバリ・カタログを使用している場合、UPGRADE
CATALOG
を発行するとエラーが表示されます。RMANでは、リカバリ・カタログが現行のバージョンでアップグレードが必要ない場合でもUPGRADE
CATALOG
コマンドを実行できます。このコマンドを実行すると、必要に応じていつでもパッケージを再作成できます。アップグレード中に生成されたエラー・メッセージを、メッセージ・ログで確認してください。
Data Guard環境で、リカバリ・カタログ・スキーマをOracle Database 11gにアップグレードすると想定します。RMANは、スタンバイ・データベースに接続する際に、新しいデータベース情報を自動的に登録し、再同期化してファイル名を制御ファイルから取得します。
再同期化中に、RMANは名前をターゲット・データベース名に関連付けます。リカバリ・カタログには、履歴メタデータが含まれているため、制御ファイルで認識されないレコードもあります。たとえば、standby1
制御ファイルでは、primary1
に作成されたすべてのバックアップについては認識されません。これらの古いレコードのデータベースの一意の名前はNULL
です。「リカバリ・カタログのメンテナンス」で説明されているように、CROSSCHECK
を使用してこれらのレコードを修正できます。
リカバリ・カタログのスキーマ・バージョンは、リカバリ・カタログ自体に格納されます。この情報は、本番システムにバージョンの異なる複数のデータベースが存在し、カタログのスキーマ・バージョンが特定のターゲット・データベース・バージョンで使用可能かどうかを確認する必要がある場合に重要です。
リカバリ・カタログのスキーマ・バージョンを確認する手順
RCVER
表に複数の行が表示される場合、この表内で最上位のバージョンが、現行のカタログ・スキーマ・バージョンです。この表に格納されるのはメジャー・バージョン番号のみであり、パッチ番号は格納されません。たとえば、rcver
表に次の行が表示されたと想定します。
VERSION ------------ 10.02.00 11.02.00 12.01.00.01
これらの行は、カタログがリリース10.2.0の実行可能ファイルによって作成され、リリース11.2.0にアップグレードされ、最後にリリース12.1.0.1にアップグレードされたことを示しています。カタログ・スキーマの現行バージョンは12.1.0.1です。
関連項目:
RMAN環境で適用される互換性規則の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
この例では、リカバリ・カタログ・スキーマを現行のバージョンにアップグレードすると想定しています。
注意:
Oracle Database 12cリリース1 (12.1.0.2)以降、リカバリ・カタログ・データベースではOracle DatabaseのEnterprise Editionを使用する必要があります。リカバリ・カタログをOracle Database 12cリリース1 (12.1.0.1)にアップグレードするには、次の手順を実行します。
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
確認のためにUPGRADE
CATALOG
コマンドを再度実行します。
RMAN> UPGRADE CATALOG; recovery catalog upgraded to version 12.01.00.01 DBMS_RCVMAN package upgraded to version 12.01.00.01 DBMS_RCVCAT package upgraded to version 12.01.00.01
リカバリ・カタログをOracle Database 12cリリース1 (12.1.0.2)にアップグレードするには、次の手順を実行します。
リカバリ・カタログ・データベースのOracleパーティション化を有効にします。
リカバリ・カタログ・データベースでStandard Editionを使用する場合、次のいずれかの方法を使用します。
リカバリ・カタログ・データベースをStandard EditionからEnterprise Editionに移行します。
注意:
Enterprise Editionへの移動の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してくださいリカバリ・カタログをOracle Enterprise Editionデータベースに移動し、IMPORT CATALOG
コマンドを使用して、リカバリ・カタログをこのデータベースにインポートします。
SQL*Plusを使用して、SYSDBA
権限を持つSYS
ユーザーとしてリカバリ・カタログ・データベースに接続します。
dbmsrmansys.sql
スクリプトを実行して、RECOVERY_CATALOG_OWNER
ロールに必要なその他の権限を付与します。
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrmansys.sql
SQL*Plusを終了します。
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 12.01.00.01 DBMS_RCVMAN package upgraded to version 12.01.00.01 DBMS_RCVCAT package upgraded to version 12.01.00.01
関連項目:
UPGRADE CATALOGコマンドの構文については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』
を参照してください。
リカバリ・カタログの互換性については、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
互換性および移行の詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
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
のパターンを繰り返します。
リカバリ・アプライアンス環境では、リカバリ・アプライアンス上に存在する単一の中央管理されたリカバリ・アプライアンス・カタログは、保護されたすべてのデータベースによって共有されます。このカタログは、リカバリ・アプライアンスにバックアップを送信する保護されたすべてのデータベースによって使用される必要があります。
リカバリ・アプライアンスを使用するデータ保護方針に保護されたデータベースを移動する場合、既存のバックアップおよびバックアップ・メタデータをリカバリ・アプライアンスに移行することを選択できます。バックアップ・メタデータを移行するには、RMANリカバリ・カタログをリカバリ・アプライアンス・カタログにインポートする必要があります。
関連項目:
リカバリ・アプライアンス・カタログの概要は、『Zero Data Loss Recovery Appliance管理者ガイド』を参照してください。
バックアップおよびバックアップ・メタデータを移行する手順は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。
『Oracle Databaseバックアップおよびリカバリ・リファレンス』の互換性の表に示されているように、ターゲット・データベース、リカバリ・カタログ・データベースおよびリカバリ・カタログ・スキーマのデータベース・バージョンが異なっている場合があります。最新のバージョンのリカバリ・カタログ・スキーマで、既存のすべてのリカバリ・カタログを1つのリカバリ・カタログにインポートすることをお薦めします。カタログのバージョンを確認する方法については、「リカバリ・カタログのスキーマ・バージョンの確認」を参照してください。互換性の表を確認し、使用している環境内で互換性があるスキーマ・バージョンを判別します。
IMPORT CATALOG
を使用する場合、ソース・リカバリ・カタログ・スキーマのバージョンは、このコマンドの実行に使用するRMAN実行可能ファイルの現行のバージョンと一致している必要があります。ソース・カタログ・スキーマのバージョンのほうが低い場合は、スキーマをインポートする前に現行のバージョンにアップグレードします。アップグレード方法については、「リカバリ・カタログのアップグレード」を参照してください。ソース・リカバリ・カタログ・スキーマのバージョンのほうが高い場合は、より高いバージョンのRMAN実行可能ファイルを使用してインポートを再試行します。
ソース・カタログ・スキーマと宛先カタログ・スキーマの両方にデータベースを登録することはできません。現在、データベースが両方のカタログ・スキーマに登録されている場合は、インポートを実行する前にソース・カタログ・スキーマからデータベースを登録解除します。
リカバリ・カタログを別のリカバリ・カタログにインポートする場合、ターゲット・データベースへの接続は必要ありません。RMANは、ソース・カタログおよび宛先カタログにのみ接続する必要があります。
次の例では、データベースsrcdb
にユーザー102cat
が所有する10.2リカバリ・カタログ・スキーマが含まれており、データベースdestdb
にユーザー111cat
が所有する11.1リカバリ・カタログ・スキーマが含まれています。
リカバリ・カタログをインポートする手順
DROP
CATALOG
コマンドを使用すると、CREATE CATALOG
コマンドによって作成されたオブジェクトが削除されます。リカバリ・カタログを所有するユーザーが、CREATE CATALOGで作成されなかった
オブジェクトも所有している場合、これらのオブジェクトはDROP CATALOG
コマンドでは削除されません。
リカバリ・カタログ・スキーマのバックアップが存在しない場合にリカバリ・カタログを削除すると、このカタログに登録されているすべてのターゲット・データベースのバックアップが使用できなくなる可能性があります。ただし、すべてのターゲット・データベースの制御ファイルには、そのデータベースの最近のバックアップのレコードが保持されます。
DROP
CATALOG
コマンドは、複数のターゲット・データベースが登録されたリカバリ・カタログから1つのデータベースを登録解除する場合には使用しないことをお薦めします。リカバリ・カタログを削除すると、そのカタログに登録されたすべてのターゲット・データベースのバックアップのリカバリ・カタログ・レコードが削除されます。
リカバリ・カタログ・スキーマを削除する手順