12 RMANを使用したファイルのバックアップおよびリストア

Oracle Data Guardおよびスタンバイ・データベースとともにOracle Recovery Manager(RMAN)を使用するバックアップ対策を作成できます。RMANを使用すると、最小限の労力でプライマリ・データベースのバックアップを実行し、個々のデータファイルの消失またはデータベース全体をすばやくリカバリできます。RMANとOracle Data Guardをともに使用すると、Oracle Data Guard構成の管理がシンプルになります。

次のトピックを参照してください。

• Oracle Data Guard構成でのRMANファイル管理について

• Oracle Data Guard環境でのRMAN構成について

• 推奨されるRMAN構成およびOracle Database構成

• バックアップ手順

• Oracle Data Guard環境でのデータベースの登録および登録解除

• Oracle Data Guard環境におけるレポート生成

• Oracle Data Guard環境におけるバックアップ・メンテナンスの実行

• Oracle Data Guard環境におけるリカバリ例

• その他のバックアップ状況

• ネットワークを介したファイルのリストアおよびリカバリ

• Oracle Data Guard環境でのCDBに対するRMANサポート

注意:

ロジカル・スタンバイ・データベースはプライマリ・データベースのブロック単位のコピーではないため、ロジカル・スタンバイ・データベースを使用してプライマリ・データベースをバックアップすることはできません。

関連項目:

• RMANの概念と、Oracle Data Guard環境でのRMANの使用方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

12.1 Oracle Data Guard構成でのRMANファイル管理について

RMANでは、リカバリ・カタログを使用して、Oracle Data Guard環境のすべてのデータベース・ファイルについてファイル名を追跡管理します。リカバリ・カタログは、1つ以上のOracleデータベースに関するメタデータを格納するためにRMANで使用されるデータベース・スキーマです。また、カタログには、オンラインREDOログ、スタンバイREDOログ、テンプレート、アーカイブREDOログ、バックアップ・セットおよびイメージ・コピーが作成される場所も記録されます。

12.1.1 Oracle Data Guard環境でのバックアップの互換性

RMANコマンドは、リカバリ・カタログのメタデータを使用して、Oracle Data Guard環境の様々なフィジカル・データベースにわたって透過的に動作します。たとえば、フィジカル・スタンバイ・データベースで表領域のバックアップを作成し、プライマリ・データベースでリストアおよびリカバリできます。同様に、プライマリ・データベースで表領域のバックアップを作成し、フィジカル・スタンバイ・データベースでリストアおよびリカバリできます。

注意:

ロジカル・スタンバイ・データベースのバックアップは、プライマリ・データベースでは使用できません。

スタンバイ制御ファイルとスタンバイ以外の制御ファイルのバックアップには互換性があります。たとえば、スタンバイ制御ファイルをプライマリ・データベースでリストアしたり、プライマリ制御ファイルをフィジカル・スタンバイ・データベースでリストアできます。この互換性は、制御ファイルのバックアップをOracle Data Guard環境の1つのデータベースにオフロードできることを意味します。RMANは、データベースでのリストアおよびリカバリ時に、データベース・ファイルのファイル名を自動的に更新します。

12.1.2 Oracle Data Guard環境でのバックアップの関連付け

リカバリ・カタログでは、すべてのデータベース・ファイル(バックアップ・ファイル)をDB_UNIQUE_NAMEに関連付けて、Oracle Data Guard環境のファイルを追跡管理します。ファイルを作成するデータベースは、そのファイルに関連付けられます。たとえば、RMANでstandby1という一意の名前を持つデータベースをバックアップすると、standby1がこのバックアップに関連付けられます。バックアップは、CHANGE ... RESET DB_UNIQUE_NAMEを使用して別のデータベースに関連付けないかぎり、作成元のデータベースに関連付けられたままです。

12.1.3 Oracle Data Guard環境でのバックアップのアクセシビリティについて

バックアップのアクセシビリティは、その関連付けとは異なります。Oracle Data Guard環境では、関連付けられたデータベースのみがディスク・バックアップにアクセスできるとリカバリ・カタログによってみなされますが、1つのデータベースに作成されたテープ・バックアップにはすべてのデータベースがアクセスできます。バックアップ・ファイルがいずれのデータベースにも関連付けられていない場合、リカバリ・カタログ・ビュー内のバックアップ・ファイルに関する行のSITE_KEY列にnullが表示されます。デフォルト設定では、RMANはターゲット・データベースにSITE_KEYがnullのファイルを関連付けます。

BACKUP、RESTORE、CROSSCHECKなどのRMANコマンドは、アクセス可能なバックアップに対して作用します。たとえば、RECOVER COPY操作の場合、RMANはデータベースに関連付けられているイメージ・コピーのみをリカバリ対象とみなします。また、ディスクおよびテープ上の増分バックアップをイメージ・コピーのリカバリ対象とみなします。データベース・リカバリでは、RMANは、データベースに関連付けられたディスク・バックアップのみとテープ上のすべてのファイルをリストアの対象とみなします。

バックアップのアクセス可能性における差異を示すため、データベースprodおよびstandby1が異なるホスト上に存在すると仮定します。RMANは、PROD上のデータファイル1を本番ホスト上の/prmhost/disk1/df1.dbfおよびテープにバックアップします。RMANは、standby1上のデータファイル1をスタンバイ・ホスト上の/sbyhost/disk2/df1.dbfおよびテープにバックアップします。RMANがデータベースprodに接続されると、RMANコマンドを使用してスタンバイ・ホスト上にある/sbyhost/disk2/df1.dbfバックアップで操作を実行することはできません。しかし、RMANはstandby1で作成したテープ・バックアップをリストア対象とみなします。

注意:

スタンバイ・ホストからプライマリ・ホスト(またはその逆)にバックアップをFTP転送し、対象のホスト上のデータベースにTARGETとして接続した後、バックアップに対してCATALOGを実行することができます。ファイルは、ターゲット・データベースによってカタログに追加された後に、ターゲット・データベースに関連付けられます。

12.2 Oracle Data Guard環境でのRMAN構成について

Oracle Data Guard構成では、制御ファイル、データファイルおよびアーカイブ・ログのバックアップ処理をスタンバイ・システムにオフロードできるため、バックアップが本番システムに与える影響は最小限に抑えられます。これらのバックアップを使用すると、プライマリ・データベースまたはスタンバイ・データベースをリカバリできます。

RMANでは、DB_UNIQUE_NAME初期化パラメータを使用してデータベース・サイトどうしを区別します。そのため、DB_UNIQUE_NAMEの一意性がOracle Data Guard構成で維持されることは不可欠なことです。

RMANのREGISTER DATABASEコマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、RMANをリカバリ・カタログに接続し、ターゲットとしてプライマリ・データベースに接続した後に行います。

RMAN構成を設定するには、RMANのCONFIGUREコマンドを使用します。CONFIGUREコマンドがFOR DB_UNIQUE_NAMEオプションを指定して使用されると、指定したDB_UNIQUE_NAMEのデータベースに対してRMANサイト固有の構成が設定されます。

たとえば、リカバリ・カタログへの接続後、次のコマンドをRMANプロンプトで使用して、DBIDが1625818158のBOSTONデータベースに対してデフォルト・デバイス・タイプをSBTに設定できます。RMANのSET DBIDコマンドは、ターゲットとしてデータベースに接続していない場合にのみ必要です。

SET DBID 1625818158;
CONFIGURE DEFAULT DEVICE TYPE TO SBT FOR DB_UNIQUE_NAME BOSTON;

12.3 推奨されるRMAN構成およびOracle Database構成

この項では、次のRMAN構成およびOracle Database構成について説明します。各構成によってバックアップ操作およびリカバリ操作を簡略化できます。

• プライマリおよびスタンバイ・データベースでのOracle Database構成

• プライマリ・データベースでのRMAN構成

• バックアップが実行されるスタンバイ・データベースでのRMAN構成

• バックアップが実行されないスタンバイでのRMAN構成

構成の前提

この項で説明する構成は、次の前提に基づいています。

• スタンバイ・データベースはフィジカル・スタンバイ・データベースで、バックアップはスタンバイ・データベースでのみ作成されます。プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成する場合の手順の変更は、「スタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない場合」を参照してください。

• 1つのデータベース・サーバーで作成されたバックアップを別なデータベース・サーバーにリストアできるようにするには、RMANリカバリ・カタログが必要です。プライマリ・データベースはスタンバイ・データベースでバックアップが作成されたことを知らないため、RMANリポジトリとして制御ファイルのみを使用するのでは不十分です。

  RMANのリカバリ・カタログは、バックアップ履歴および他のリカバリ関連のメタデータを一元化された場所に編成します。リカバリ・カタログは、データベース内に構成され、バックアップ・メタデータが格納されます。リカバリ・カタログには、制御ファイルに関する領域の制限がないため、バックアップに関する履歴データをより多く格納できます。

  カタログ・サーバーは、プライマリ・サイトおよびスタンバイ・サイトと物理的に切り離されていますが、Oracle Data Guard構成内に置くことをお薦めします。これは、いずれのサイトで障害が発生しても最新のバックアップをリカバリする機能に影響しないためです。

  関連項目:

  リカバリ・カタログの管理の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

• 構成内のすべてのデータベースには、Oracle Database 11gリリース1 (11.1)以上を使用します。

• Oracle Secure Backupソフトウェアまたはサード・パーティのメディア管理ソフトウェアは、バックアップをテープに取るようにRMANで構成します。

12.3.1 プライマリおよびスタンバイ・データベースでのOracle Database構成

次のOracle Database構成は、Oracle Data Guard環境におけるすべてのプライマリ・データベースおよびスタンバイ・データベースで推奨されます。

• データベースごとに高速リカバリ領域を構成する(リカバリ領域はデータベースに対してローカル)。

  高速リカバリ領域は、ファイル・システムまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループ上にある、リカバリに必要なすべてのファイルが存在する唯一の格納場所です。これらのファイルには、制御ファイル、アーカイブ・ログ、オンラインREDOログ、フラッシュバック・ログおよびRMANバックアップがあります。新しいバックアップおよびアーカイブ・ログが高速リカバリ領域に作成されると、古いファイル(保存期間を超過しているまたは三次記憶域にバックアップされている)は自動的に削除され、新しいファイル用の領域が作成されます。さらに、高速リカバリ領域の領域使用量が事前に定義された制限に近づいている場合に、DBAにアラートを送信するように通知を設定できます。DBAは、リカバリ領域の領域制限を上げる、ディスク・ハードウェアを追加する、あるいは保存期間を短縮するなどの処置を取ることができます。

  次の初期化パラメータを設定して、高速リカバリ領域を構成します。

  DB_RECOVERY_FILE_DEST = <mount point or Oracle ASM Disk Group>
  DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>

  関連項目:

  高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

• サーバー・パラメータ・ファイル(SPFILE)を使用して、インスタンス・パラメータがバックアップに保存されるようにバックアップを作成できるようにする。

• プライマリ・データベースおよびスタンバイ・データベースでフラッシュバック・データベースを有効にする。

  フラッシュバック・データベースを有効に設定すると、Oracle Databaseによってフラッシュバック・ログが高速リカバリ領域に保持されます。これらのログを使用すると、完全にリストアしなくても、前の時点までデータベースをロールバックできます。

  関連項目:

  フラッシュバック・データベースの有効化に関する詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12.3.2 プライマリ・データベースでのRMAN構成

RMANの継続的な使用を簡略化するために、多くの永続的な構成設定をOracle Data Guard環境のデータベースごとに設定できます。これらの設定により、RMANの動作を多面的に制御します。たとえば、バックアップの保存ポリシー、デフォルトのバックアップ先(テープまたはディスク)、デフォルトのバックアップ・デバイス・タイプなどを構成できます。CONFIGUREコマンドを使用すると、RMAN構成を設定および変更できます。次のRMAN構成は、プライマリ・データベースにおいて推奨されます。

1. RMANをプライマリ・データベースおよびリカバリ・カタログに接続します。
2. データベースの保存ポリシーをn日間として構成します。

   CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS;
   

   この構成により、任意の時点までのデータベース・リカバリの実行に必要なバックアップを指定した日数の間保存できます。

   DELETE OBSOLETEコマンドを使用して、特定日数の間はリカバリを実行する必要がないバックアップ(設定されている保存方針に基づき)を削除します。

3. アーカイブ・ログを削除できる時期をCONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して指定します。たとえば、すべての宛先への送信を確認した後にログを削除する場合は、次の構成を使用します。

   CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
   

   すべてのスタンバイ宛先への適用を確認した後にログを削除するには、次の構成を使用します。

   CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
   

4. RESYNC CATALOG FROM DB_UNIQUE_NAMEコマンドの使用時に、RMANがリモートで接続して、再同期化を行えるように、プライマリ・データベースおよびすべてのスタンバイ・データベースの接続文字列を構成します。ターゲット・インスタンスに接続する際、ネット・サービス名を提供する必要があります。再同期化元の他のデータベースがローカル・ホストにある場合でも、この要件は適用されます。ターゲットおよびリモート・インスタンスは同じSYSDBA(またはSYSBACKUP)パスワードを使用する必要があります。したがって、両方のインスタンスにパスワード・ファイルがなければなりません。単一のパスワードでパスワード・ファイルを作成し、そのパスワード・ファイルですべてのデータベース・インスタンスを起動することができます。たとえば、ボストンにあるスタンバイへの接続用TNS別名がboston_conn_strの場合、次のコマンドを使用してBOSTONデータベース・サイトの接続識別子を構成することができます。

   CONFIGURE DB_UNIQUE_NAME BOSTON CONNECT IDENTIFIER 'boston_conn_str';
   

   'boston_conn_str'にはユーザー名とパスワードが含まれていない点に注意してください。任意のデータベース・サイトからBOSTONデータベース・サイトに接続するために使用できる、Oracle Netサービス名だけが含まれています。

   すべてのスタンバイ・データベースについて接続識別子が構成されたら、LIST DB_UNIQUE_NAME OF DATABASEコマンドを使用してスタンバイのリストを確認できます。

関連項目:

• RMAN構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

12.3.3 バックアップが実行されるスタンバイ・データベースでのRMAN構成

次のRMAN構成は、バックアップが実行されるスタンバイ・データベースで推奨されます。

1. RMANをターゲットとして(バックアップが実行される)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。
2. 制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを有効にします。

   CONFIGURE CONTROLFILE AUTOBACKUP ON;
   

3. 同じチェックポイントで有効なバックアップがすでに存在するデータファイルのバックアップをスキップします。

   CONFIGURE BACKUP OPTIMIZATION ON;
   

4. メディア管理ソフトウェアによる要求に応じて、バックアップを作成するためのテープ・チャネルを構成します。

   CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '<channel parameters>';
   

5. アーカイブ・ログがスタンバイ・データベースでバックアップされるため、ログ削除ポリシーにBACKED UPオプションを構成することをお薦めします。

   CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP n TIMES TO DEVICE TYPE SBT;

関連項目:

アーカイブREDOログの削除方針の有効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12.3.4 バックアップが実行されないスタンバイでのRMAN構成

次のRMAN構成は、バックアップが実行されないスタンバイ・データベースで推奨されます。

1. RMANをターゲットとしてスタンバイ・データベースに接続し、リカバリ・カタログに接続します。
2. アーカイブ・ログの自動削除を、スタンバイ・データベースで適用されたらすぐに有効にします(カスケードまたは遠隔同期インスタンス機能が使用されている場合に、これはすべてのターミナル・データベースにも適用可能です)。

   CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

12.4 バックアップ手順

この項では、Oracle Data Guard構成内のOracle Databaseのバックアップに使用されるRMANスクリプトおよび手順について説明します。次の項目で構成されています。

• テープ・バックアップ用キャッシュとしてのディスクの使用

• テープへの直接バックアップの実行

注意:

OracleのMaximum Availability Architecture(MAA)ベスト・プラクティスでは、プライマリ・データベースとスタンバイ・データベースの両方が停止した場合や、スイッチオーバーおよびフェイルオーバーについてサイトのプラクティスを新たに導入しなくてもよいようにする場合に、プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成してMTTRを短縮することをお薦めしています。

サーバー・パラメータ・ファイルのバックアップ

SPFILEのバックアップを除いたすべてのバックアップ操作は、単一のスタンバイ・データベースにオフロードできます。SPFILEのバックアップは、バックアップ元のデータベースにのみリストアできます。

バックアップされていないデータベースの場合、少なくともSPFILEを既知のローカル・ディスクの場所にバックアップすることをお薦めします。SPFILEバックアップをさらにテープにバックアップする必要がある場合、テープへのバックアップが構成済のデータベース・サイトへコピーすることができます。さらに次のRMANコマンドを使用して、SPFILEバックアップをそのデータベースでカタログ化することができます。

CATALOG START WITH '<SPFILE backup directory>';

次に、SPFILEバックアップをテープにバックアップします。

BACKUP BACKUPSET ALL;

SPFILEが特定のデータベースにリストアされる必要があるときは、適切なSPFILEバックアップがディスクまたはテープからリストアされます。

12.4.1 テープ・バックアップ用キャッシュとしてのディスクの使用

スタンバイ・データベースの高速リカバリ領域は、テープ・バックアップ用のディスク・キャッシュとして機能できます。ディスクはバックアップ用の一次記憶域として使用され、テープは長期間のアーカイブ記憶域となります。テープの増分バックアップは毎日、テープの全体バックアップは毎週作成されます。これらのバックアップの実行に使用されるコマンドは、次の各項を参照してください。

12.4.1.1 ディスクをキャッシュとして使用する日次テープ・バックアップ用のコマンド

バックアップ計画を決定する際に、日次増分バックアップを利用することをお薦めします。データファイル・イメージ・コピーは、最新の増分バックアップを使用してロールフォワードできるため、常に最新のデータファイル・イメージ・コピーを提供できます。RMANでは、そのシステム変更番号(SCN)で取得された全体イメージ・コピーを使用するように、結果のイメージ・コピーをメディア・リカバリに使用するため、データベースの全体イメージ・コピーを毎日実行するオーバーヘッドはありません。もう1つのメリットは、イメージ・コピーが最新のブロック変更で更新され、現在の状態にデータベースを戻すのに必要なREDOログが少なくなるため、リカバリ時間が短縮されることです。

日次増分バックアップを実施するには、1日目にデータベースの全体バックアップを作成し、2日目に増分バックアップを作成します。アーカイブREDOログを使用すると、いずれの日のどの時点についてもデータベースをリカバリできます。3日目以降は、前日の増分バックアップをデータファイル・コピーとマージし、当日の増分バックアップを作成して、最終日までのどの時点についても高速リカバリを可能にします。REDOログを使用すると、当日のどの時点についてもデータベースをリカバリできます。

日次バックアップを実行するスクリプトは次のとおりです(最終行DELETE ARCHIVELOG ALLは、高速リカバリ領域をログの格納に使用しない場合にのみ必要です)。

RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
RECOVER COPY OF DATABASE WITH TAG 'OSS';
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE;
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL;
BACKUP BACKUPSET ALL;
DELETE ARCHIVELOG ALL;

スタンバイ制御ファイルは、制御ファイルの自動バックアップが有効に設定されているため、バックアップ操作の最後に自動的にバックアップされます。

次に、スクリプトの各コマンドの動作について説明します。

• RESYNC CATALOG FROM DB_UNIQUE_NAME ALL

  Oracle Data Guard設定で、リカバリ・カタログが把握しているその他すべてのデータベース・サイト(プライマリおよびその他のスタンバイ・データベース)からの情報を再同期化します。RESYNC CATALOG FROM DB_UNIQUE_NAMEが機能するためには、Oracle Netサービス名を使用してRMANをターゲットに接続し、すべてのデータベースで同じパスワード・ファイルを使用する必要があります。

• RECOVER COPY OF DATABASE WITH TAG 'OSS'

  前日に取得したレベル1の増分バックアップを適用して、データベースのレベル0のコピーをロールフォワードします。この例のスクリプトでは、前日のレベル1の増分にはOSSタグが付けられています。その増分は、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。このコマンドが実行された1日目には、レベル1の増分がまだないため、ロールフォワードはありません。レベル0の増分が、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。2日目にも、レベル0の増分しかないため、ロールフォワードはありません。OSSタグが付けられたレベル1の増分が、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。3日目以降には、前日に作成されたOSSタグ付きのレベル1の増分を使用して、ロールフォワードが実行されます。

• BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE

  新しいレベル1の増分バックアップを作成します。このコマンドが実行された1日目は、レベル0の増分となります。2日目以降は、レベル1の増分となります。

• BACKUP DEVICE TYPE SBT ARCHIVELOG ALL

  所定の削除ポリシーに従って、アーカイブ・ログをテープにバックアップします。

• BACKUP BACKUPSET ALL

  増分バックアップの作成結果として作成されるバックアップ・セットをバックアップします。

• DELETE ARCHIVELOG ALL

  CONFIGURE ARCHIVELOG DELETION POLICYコマンドで設定されたログ削除ポリシーに従って、アーカイブ・ログを削除します。アーカイブ・ログが高速リカバリ領域にある場合は、空きディスク領域がさらに必要になると自動的に削除されます。そのため、毎日ログを明示的に削除する場合にのみ、このコマンドを使用する必要があります。

12.4.1.2 ディスクをキャッシュとして使用する週次テープ・バックアップ用のコマンド

すべてのリカバリ関連ファイルをテープにバックアップするには、次のコマンドを週1回使用します。

BACKUP RECOVERY FILES;

これにより、ディスク上にある最新の増分バックアップ、イメージ・コピー・バックアップおよびアーカイブ・ログ・バックアップがすべてテープにバックアップされます。

12.4.2 テープへの直接バックアップの実行

OracleのMedia Management Layer(MML)APIにより、サード・パーティ・ベンダーは、メディア・マネージャ、RMANと連動して機能するソフトウェア、テープ・ドライブなどの順次メディア・デバイスへのバックアップを可能にするベンダーのハードウェアを構築できます。メディア・マネージャは、テープなどの順次メディアのロード、アンロードおよびラベル付けを処理します。RMANを順次メディア・デバイスとともに使用するには、Oracle Secure Backupまたはサード・パーティのメディア管理ソフトウェアをインストールする必要があります。

デフォルトでは、次の手順を実行してテープへの直接バックアップを実行します。

1. RMANを(ターゲット・データベースとして)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。
2. 次のように、CONFIGUREコマンドを実行します。

   CONFIGURE DEFAULT DEVICE TYPE TO SBT;
   

この例では、スタンバイ・データベースで全体バックアップが毎週、増分バックアップが毎日作成されます。

関連項目:

メディア・マネージャ用のRMANの構成方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12.4.2.1 テープに直接実行する日次バックアップ用のコマンド

次の手順を実行して、テープに日次バックアップを直接実行します。

1. RMANをスタンバイ・データベース(ターゲット・データベースとして)、およびリカバリ・マネージャに接続します。
2. 次のRMANコマンドを実行します。

   RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
   BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG; 
   DELETE ARCHIVELOG ALL;
   

これらのコマンドは、Oracle Data Guard環境内のその他すべてのデータベースの情報を再同期化します。また、すべてのアーカイブ・ログを含むデータベースのレベル1の増分バックアップを作成します。このスクリプトが実行された1日目に、レベル0のバックアップが検出されなければ、レベル0のバックアップが作成されます。

DELETE ARCHIVELOG ALLコマンドは、すべてのアーカイブ・ログ・ファイルが高速リカバリ領域にない場合にのみ必要です。

12.4.2.2 テープに直接実行する週次バックアップ用のコマンド

週1日、次の手順を実行してテープに週次バックアップを直接実行します。

1. RMANを(ターゲット・データベースとして)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。
2. 次のRMANコマンドを実行します。

   RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
   BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
   DELETE ARCHIVELOG ALL;
   

これらのコマンドは、Oracle Data Guard環境内のその他すべてのデータベースの情報を再同期化し、すべてのアーカイブ・ログを含むレベル0のデータベース・バックアップを作成します。

DELETE ARCHIVELOG ALLコマンドは、すべてのアーカイブ・ログ・ファイルが高速リカバリ領域にない場合にのみ必要です。

12.5 Oracle Data Guard環境でのデータベースの登録および登録解除

REGISTER DATABASEコマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、RMANをリカバリ・カタログに接続し、TARGETとしてプライマリ・データベースに接続した後に行います。

新しいスタンバイは、スタンバイ・データベースに接続するか、またはCONFIGURE DB_UNIQUE_NAMEコマンドを使用して接続識別子を構成すると、リカバリ・カタログに自動的に登録されます。

特定のスタンバイ・データベースに関する情報を登録解除するには、UNREGISTER DB_UNIQUE_NAMEコマンドを使用できます。スタンバイ・データベースをOracle Data Guard環境から完全に削除すると、同じOracle Data Guard環境内の別のデータベースに接続した後に、リカバリ・カタログのデータベース情報も削除できます。登録解除されたデータベースと関連付けられたバックアップは、そのまま他のデータベースで使用できます。これらのバックアップは、CHANGE BACKUP RESET DB_UNIQUE_NAMEコマンドを使用して既存の他のデータベースに関連付けることができます。

INCLUDING BACKUPSオプションを指定してUNREGISTER DB_UNIQUE_NAMEコマンドを使用すると、登録解除中のデータベースに関連付けられたすべてのバックアップ・ファイルのメタデータもリカバリ・カタログから登録解除されます。

12.6 Oracle Data Guard環境におけるレポート生成

FOR DB_UNIQUE_NAME句を指定してRMANのLIST、REPORTおよびSHOWの各コマンドを使用すると、特定のデータベースに関する情報を表示できます。

たとえば、リカバリ・カタログに接続した後、次のコマンドを使用してDBIDが1625818158のデータベースに関する情報を表示し、Oracle Data Guard環境内のデータベースを出力できます。SET DBIDコマンドは、TARGETとしてデータベースに接続していない場合にのみ必要です。最後の3つのコマンドは、DB_UNIQUE_NAMEがBOSTONのデータベースについて、アーカイブ・ログ、データベース・ファイル名およびRMANの構成情報を出力します。

SET DBID 1625818158;
LIST DB_UNIQUE_NAME OF DATABASE;
LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME BOSTON;
REPORT SCHEMA FOR DB_UNIQUE_NAME BOSTON;
SHOW ALL FOR DB_UNIQUE_NAME BOSTON;

12.7 Oracle Data Guard環境におけるバックアップ・メンテナンスの実行

Oracle Data Guard環境のファイル(データファイル、アーカイブ・ログ、バックアップ・ピース、イメージ・コピー、プロキシ・コピー)は、DB_UNIQUE_NAMEパラメータを使用してデータベースに関連付けられます。そのため、Oracle Data Guard環境のデータベースごとに、DB_UNIQUE_NAMEに指定された値は一意であることが重要です。この情報は、ファイル共有属性とともに、RMANの様々な操作の際にアクセスできるファイルを判別するのに使用されます。

ファイル共有属性は、ディスク上のファイルは関連付けられたデータベースでのみアクセス可能で、テープ上のすべてのファイルはすべてのデータベースでアクセス可能に設定されています。BACKUPおよびRESTOREなどのRMANコマンド、およびその他のメンテナンス・コマンドは、この想定で機能しています。たとえば、データベースでのイメージ・コピーのロールフォワード操作中は、そのデータベースに関連付けられたイメージ・コピーだけがロールフォワードされます。そのデータベースに関連付けられたディスクでの増分バックアップおよびテープでの増分バックアップは、イメージ・コピーのロール転送に使用されます。また、リカバリ操作中は、データベースに関付けられたディスク・バックアップとテープ上のファイルのみがバックアップ元と見なされます。

関連項目:

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

12.7.1 リカバリ・カタログのメタデータの変更

次のリストに、様々なオペランドを指定してRMANのCHANGEコマンドを使用して、リカバリ・カタログのメタデータを変更する方法を示します。

• スタンバイ・データベース間でのファイルの関連付けの変更

  RESET DB_UNIQUE_NAMEオプションを指定してCHANGEコマンドを使用すると、Oracle Data Guard環境内のあるデータベースから別のデータベースにファイルの関連付けを変更できます。CHANGEコマンドは、ディスク・バックアップまたはアーカイブ・ログをあるデータベースから別のデータベースに転送し、転送先のデータベースでそれらのファイルを使用するときに役立ちます。また、CHANGEコマンドは、FOR DB_UNIQUE_NAMEオプションとRESET DB_UNIQUE_NAME TOオプションを使用すると、いずれのデータベースに直接接続しなくてもデータベース間でファイルの関連付けを変更できます。

• データベースのDB_UNIQUE_NAME初期化パラメータの変更

  データベースのDB_UNIQUE_NAME初期化パラメータの値を変更すると、Oracle Data Guard環境でも同じ変更を行う必要があります。そのデータベース・インスタンスへの接続後、RMANのリカバリ・カタログはDB_UNIQUE_NAMEの新旧両方の値を認識します。リカバリ・カタログ・スキーマ内で新旧の値に関する情報をマージするには、RMANのCHANGE DB_UNIQUE_NAMEコマンドを使用する必要があります。データベースのDB_UNIQUE_NAME初期化パラメータの値を変更すると、新しいDB_UNIQUE_NAMEを認識させるために、RMANでも同じ変更を行う必要があります。たとえば、次の手順を実行し、DB_UNIQUE_NAMEをBOSTON_AからBOSTON_Bに変更することでデータベースを変更します。

  1. 初期化パラメータ・ファイルまたはSQLで、DB_UNIQUE_NAME初期化パラメータをBOSTON_AからBOSTON_Bに変更します。

  2. RMANで、Oracle Data Guard environment環境のデータベースにターゲット・データベースとして接続し、リカバリ・カタログに接続します。続いて、CHANGEコマンドを実行します。

     CHANGE DB_UNIQUE_NAME FROM BOSTON_A TO BOSTON_B;

• バックアップの使用不可化またはメタデータの削除

  AVAILABLE、UNAVAILABLE、KEEP、UNCATALOGなどのオプションを指定してCHANGEコマンドを使用すると、バックアップをリストアおよびリカバリの目的で使用可能または使用不可能にしたり、そのメタデータを保存または削除することができます。

  関連項目:

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

12.7.2 アーカイブ・ログまたはバックアップの削除

DELETEコマンドを使用して、バックアップ・セット、イメージ・コピー、アーカイブ・ログ、プロキシ・コピーを削除します。特定のデータベースに関連付けられているファイルのみを削除するには、FOR DB_UNIQUE_NAMEオプションをDELETEコマンドとともに使用する必要があります。

ファイルのメタデータは、現行のターゲット・データベースに関連付けられ、正常に削除されたすべてのファイル(またはどの既知のデータベースにも関連付けられていないファイル)について削除されます。ファイルが正常に削除できなかった場合は、FORCEオプションを使用してファイルのメタデータを削除します。

別のデータベースに関連付けられているファイルが正常に削除された場合、リカバリ・カタログのそのメタデータも削除されます。他のデータベースに関連付けられているファイルおよび正常に削除できなかったファイルは、DELETEコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはデータベースごとにグループ化されます)。FORCEオプションを使用して、この動作を上書きすることはできません。削除不可のファイルのメタデータを削除しても問題ないことが明確である場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、FORCEオプションを指定してDELETEコマンドを使用し、ファイルのメタデータを削除します。

関連項目:

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

12.7.3 リカバリ・カタログのメタデータの検証

CROSSCHECKコマンドを使用してリカバリ・カタログ・スキーマのファイル・ステータスを検証および更新します。

現行のターゲット・データベースに関連付けられたすべてのファイル(またはどのデータベースにも関連付けられていないあらゆるファイル)のメタデータは、CROSSCHECK操作の結果に応じてAVAILABLEまたはEXPIREDのマークが付けられます。

別のデータベースに関連付けられているファイルが正常に検査された場合、リカバリ・カタログのそのメタデータもAVAILABLEに変更されます。他のデータベースに関連付けられているファイルおよび正常に検査できなかったファイルは、CROSSCHECKコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはサイトごとにグループ化されます)。確認し、それでも使用不可のファイルのステータス・メタデータを変更する場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、CROSSCHECKコマンドを実行してステータス・メタデータをEXPIREDに更新します。

関連項目:

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

12.8 Oracle Data Guard環境におけるリカバリ例

この項では、次のリカバリ例について説明します。

• プライマリまたはスタンバイ・データベースでのファイルの損失からのリカバリ

• オンラインREDOログ・ファイルの損失からのリカバリ

• プライマリ・データベースの不完全リカバリ

• プライマリでのTSPITRまたは表領域プラグイン後のスタンバイで必要なアクション

12.8.1 プライマリまたはスタンバイ・データベースでのファイルの損失からのリカバリ

Oracle Database 12cリリース1 (12.1)では、必要なファイルが含まれるフィジカル・スタンバイ・データベースへネットワークを介して接続し、ファイルをリストアおよびリカバリできます。これは、プライマリ・データベースで失われたデータファイル、制御ファイルまたは表領域を、フィジカル・スタンバイ・データベース上の対応するファイルを使用してリストアする必要がある場合に有用です。同じプロセスを使用して、プライマリ・データベースを使用してフィジカル・スタンバイ・データベース上のファイルをリストアすることもできます。

ネットワーク経由での接続によるファイルのリストアおよびリカバリ方法の例については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

注意:

Oracle Database 12cより前のリリースでは、プライマリのファイルの損失からリカバリするには、RMANリカバリ・カタログ、RMAN BACKUP、CATALOG DATAFILEおよびSWITCH DATAFILEコマンドを使用しました。スタンバイのファイルの損失からリカバリするには、RESTOREおよびRECOVERコマンドを使用しました。これらの方法は、Oracle Database 12cでは不要になりました。これらの使用についての情報が必要な場合は、Oracle Database 11gのドキュメントを参照してください。

関連項目:

• ネットワークを介してファイルをリストアおよびリカバリする場合のRMANの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12.8.2 オンラインREDOログ・ファイルの損失からのリカバリ

現行のACTIVEグループまたはアーカイブされていない非アクティブ・グループのオンライン・ログ・メンバーすべてが消失した場合、スタンバイ・データベースにフェイルオーバーする必要があります。フェイルオーバー手順の詳細は「ロールの推移」を参照してください。

その他の状況でのオンラインREDOログ・ファイルの損失からのリカバリ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12.8.3 プライマリ・データベースの不完全リカバリ

プライマリ・データベースの不完全リカバリを実行するのは、通常、データベースが論理的に(ユーザーまたはアプリケーションが原因で)破損した場合や、表領域またはデータファイルがデータベースから意図せずに削除された場合などです。

スタンバイ・データベース・インスタンス上の現在のデータベース・チェックポイントSCNに応じて、次のいずれかの手順でプライマリ・データベースの不完全リカバリを実行できます。すべての手順は、最も所要時間が短いものから優先順位順になっています。

データベースのフラッシュバックの使用

ラッシュバック・データベースの使用は、プライマリ・データベースでフラッシュバック・データベース機能が使用可能で、データベース・ファイルが1つも消失しておらず、Point-in-Timeリカバリが最も古いフラッシュバックSCNより大きいか、最も早いフラッシュバック時間よりも後の場合の推奨手順です。フラッシュバック・データベースを使用してPoint-in-Timeリカバリを実行する手順の詳細は、「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。

スタンバイ・データベース・インスタンスの使用

これは、スタンバイ・データベースが必要な不完全リカバリ時間より後のもので、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用可能でない場合の推奨手順です。

1. スタンバイ・データベースを必要な時点までリカバリします。次のコマンドを発行する前に、管理されているREDOプロセス(MRP)が停止していることを確認します。

   RECOVER DATABASE UNTIL TIME 'time';
   

   あるいは、SCNまたはログ順序番号を使用して不完全リカバリ時間を指定できます。

   RECOVER DATABASE UNTIL SCN incomplete recovery SCN';
   RECOVER DATABASE UNTIL LOGSEQ incomplete recovery log sequence number THREAD thread number;
   

2. スタンバイ・データベースを読取り専用モードでオープンし、データベースの状態を確認します。

   必要な状態になっていない場合は、LogMinerユーティリティを使用してアーカイブREDOログ・ファイルを調べ、不完全リカバリに適切なターゲット時刻またはSCNを確認します。または、ターゲット時刻より前の判明している時点までスタンバイ・データベースをリカバリしてから、データベースを読取り専用モードでオープンし、データの状態を検査することもできます。データベースの状態が正常であると確認されるまで、このプロセスを繰り返します。データベースのリカバリ終了時点が遅すぎると(エラーが発生したSCNより後までリカバリすると)、それより前のSCNに戻せません。

3. SQL ALTER DATABASE ACTIVATE STANDBY DATABASE文を使用してスタンバイ・データベースをアクティブ化します。これにより、スタンバイ・データベースがプライマリ・データベースに変換されて、新しいリセットログ・ブランチが作成され、データベースがオープンします。スタンバイ・データベースが新しいリセットログ・ブランチにどのように対処するかは、「OPEN RESETLOGS文を使用したリカバリ」を参照してください。

プライマリ・データベース・インスタンスの使用

すべてのスタンバイ・データベース・インスタンスがすでに必要な時点より後までリカバリされており、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用できない場合は、この方法で操作する必要があります。

次の手順に従ってプライマリ・データベースで不完全リカバリを実行します。

1. LogMinerまたは他の手段を使用して、データベースのすべてのデータが正常と判明している時点またはSCNを識別します。
2. その時点またはSCNを使用して次のRMANコマンドを発行し、不完全データベース・リカバリを実行し、RESETLOGSオプションを使用して(カタログ・データベースとMOUNT状態のプライマリ・インスタンスに接続した後で)データベースをオープンします。

   RUN 
   {
   SET UNTIL TIME 'time';
   RESTORE DATABASE;
   RECOVER DATABASE;
   }
   ALTER DATABASE OPEN RESETLOGS;
   

この処理の後に、Oracle Data Guard構成内ですべてのスタンバイ・データベース・インスタンスを再確立する必要があります。

12.8.4 プライマリでのTSPITRまたは表領域プラグイン後のスタンバイで必要なアクション

RMAN表領域Point-in-Timeリカバリ(TSPITR)がプライマリで実行された後、修復されたデータファイルは新しいシステム変更番号(SCN)を持つので、プライマリで新しいデータファイルのように扱われます。これらのデータファイルはスタンバイで自動的に作成することはできません。

同様に、新しいプラグイン表領域がプライマリ・データベースに追加されると、データファイルはプライマリで新しいデータファイルのように扱われます。

Redo Applyプロセスがこれらの新しいファイルの作成を検出すると、スタンバイでの管理されたREDOプロセス(MRP)は停止します。必要な新しいデータファイルはコピーされ、スタンバイにリストアされる必要があります。バックアップまたはプライマリからの直接コピーのいずれかを使用してこれを行うことができます。たとえば、RMAN TSPITRが行われた表領域に属するすべてのファイルをコピーするには、次のRMANコマンドを使用できます。

RMAN> RESTORE TABLESPACE <tbs_name1, tbs_name2> FROM SERVICE <tnsalias-of-primary>

割り当てられるディスク・チャネルの数はRMAN構成ごとです。したがって、CONFIGURE DEVICE TYPE DISK PARALLELISM 4が実行されると、4つのディスク・チャネルを使用してプライマリ・データベースからファイルが取得されます。

新しいデータファイルがスタンバイで使用可能な場合、MRPを再起動してログの適用を継続します。

関連項目:

• RMAN TSPITRの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12.9 その他のバックアップ状況

次の各項では、スタンバイ・データベースとプライマリ・データベースでバックアップ・ファイルを共有できない場合、REDOログ・ファイルのリモート・アーカイブにスタンバイ・インスタンスのみが使用される場合、またはスタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合など、その他の構成にあわせてバックアップ処理を変更する方法について説明します。

12.9.1 スタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない場合

スタンバイ・データベース間の距離が離れている場合、プライマリ・システムや他のスタンバイ・システムからは、これらの上で作成されたバックアップに簡単にアクセスできません。すべてのシステム上でデータベースの完全バックアップを実行して、リカバリ操作を実行します。高速リカバリ領域は、プライマリおよびスタンバイ・システム上にローカルに置くことができます。プライマリ・データベースとスタンバイ・データベースで同一である必要はありません。

この使用例でも、「Oracle Data Guard環境におけるリカバリ例」で説明した一般的な対策を使用できますが、次の例外があります。

• RMANで作成されるバックアップ・ファイルには、タグとしてローカル・システム名を指定し、そのタグをRESTORE操作で使用して、RMANによる同じホスト上で作成されたバックアップの選択を制限する必要があります。つまり、バックアップの作成時に、BACKUPコマンドではTAG system nameオプションを、RESTOREコマンドではFROM TAG system nameオプションを、RECOVERコマンドではFROM TAG system name ARCHIVELOG TAG system nameオプションをそれぞれ使用する必要があります。

• スタンバイ・サイトの障害時リカバリを実行する手順は、次のとおりです。

  1. スタンバイの操作に使用されていたのと同じパラメータ・ファイルを使用して、スタンバイ・インスタンスをNOMOUNT状態で起動します。

  2. プライマリ・インスタンスで、SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename文を使用してスタンバイ制御ファイルを作成し、作成された制御ファイルを使用してスタンバイ・インスタンスをマウントします。

  3. 次のRMANコマンドを発行し、データベース・ファイルをリストアおよびリカバリします。

     RESTORE DATABASE FROM TAG 'system name';
     RECOVER DATABASE FROM TAG 'system name' ARCHIVELOG TAG 'system name';
     

  4. REDO Applyを再開します。

スタンバイ・インスタンスにより残りのアーカイブREDOログ・ファイルがフェッチされます。

12.9.2 FALサーバーとして使用されるスタンバイ・データベースにデータファイルが含まれていない場合

「バックアップ手順」で説明した手順を使用しますが、データベース・ファイルをバックアップするRMANコマンドはFALサーバーに対して実行できません。FALサーバーは、すべてのアーカイブREDOログ・ファイルのバックアップ・ソースとして使用できるため、アーカイブREDOログ・ファイルのバックアップをFALサーバーにオフロードします。

12.9.3 スタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合

注意:

Oracle Database 11g現在、リカバリ・カタログは各スタンバイ・データベース・サイトのファイル名を再同期化できます。しかし、スタンバイ・データベースのファイル名がなんらかの理由でまったく再同期化されていなかった場合は、この項で説明する手順に従って再同期化することが可能です。

まったく再同期化されていなかったプライマリ・データベースとスタンバイ・データベースでデータベース・ファイル名が異なる場合は、使用するRESTOREおよびRECOVERコマンドが若干異なります。スタンバイ・データベースで実際のデータファイル名を取得するには、V$DATAFILEビューを問い合せ、データベース内のすべてのデータファイルにSET NEWNAMEオプションを指定します。

RUN 
{
SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE';
SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE';
…
…
 SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE';
 RESTORE {DATAFILE <n,m,…> | TABLESPACE tbs_name_1, 2, …| DATABASE;
SWITCH DATAFILE ALL; 
RECOVER DATABASE {NOREDO};
}

同様に、RMAN DUPLICATEコマンドのSET NEWNAMEオプションを使用してスタンバイ・データベースの作成時に新しいファイル名を指定します。あるいは、LOG_FILE_NAME_CONVERTおよびDB_FILE_NAME_CONVERTパラメータを設定できます。

関連項目:

DB_FILE_NAME_CONVERTおよびDB_CREATE_FILE_DESTパラメータの両方がスタンバイに設定されている場合の優先ルールの詳細は、「OMFまたはOracle ASMを使用するスタンバイ・データベースの作成」を参照してください。

12.10 ネットワークを介したファイルのリストアおよびリカバリ

Oracle Database 12cでは、RMANを使用すると、必要なファイルが含まれるフィジカル・スタンバイ・データベースへネットワークを介して接続し、ファイルをリストアまたはリカバリできます。データベース全体、データファイル、制御ファイル、spfileまたは表領域をリストアすることができます。プライマリ・データベースおよびスタンバイ・データベースを同期化する必要がある場合、ネットワークを介したファイルのリストアは、非常に有用です。

RMANは、RESTOREコマンドのFROM SERVICE句を使用し、フィジカル・スタンバイ・データベースからネットワークを介してデータベース・ファイルをリストアします。FROM SERVICE句では、ファイルをリストアする必要があるフィジカル・スタンバイ・データベースのサービス名を指定します。リストア操作では、リストアする必要があるファイルのバックアップ・セットがRMANによってフィジカル・スタンバイ・データベース上に作成され、これらのバックアップ・セットがネットワークを介してターゲット・データベースに転送されます。

注意:

Oracle Database 12cより前のリリースでは、ネットワークを介してファイルをリストアまたはリカバリするには、RMANのBACKUP INCREMENTAL FROM SCNコマンドを使用して、プライマリ・データベースでスタンバイの現行SCNから始まるバックアップを作成し、それを使用してスタンバイ・データベースをロールフォワードしました。この手動の、複数の手順による方法は、Oracle Database 12cでは不要です。この方法の使用に関する情報が必要な場合は、Oracle Database 11gのドキュメントを参照してください。

関連項目:

• フィジカル・スタンバイ・データベースをロールフォワードし、プライマリ・データベースと同期化させる場合のRMANの使用例は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

• ネットワークを介してファイルをリストアおよびリカバリする場合のRMANの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

12.11 Oracle Data Guard環境でのCDBに対するRMANサポート

スタンバイでの完全なデータベース・リカバリおよび完全なデータファイル・リカバリのサポートに加えて、RMANではスタンバイでマルチテナント・コンテナ・データベース(CDB)のPoint-in-timeリカバリ(PITR)がサポートされます。

スタンバイでCDB PITRを実行するには、rootとしてCDBに接続し、必要に応じてRMAN BACKUP、RESTOREおよびRECOVERコマンドを発行します。

CDB PITRがスタンバイで実行される場合、無効状態だったプラガブル・データベース(PDB)がCDB PITRの前に有効になることに注意してください。PDBを無効状態に戻すには、PDBに接続し、閉じていることを確認し(V$PDBSビューのOPEN_MODE列がMOUNTEDの値を示す)、SQL文ALTER PLUGGABLE DATABASE DISABLE RECOVERYを実行します。(このSQL文はOracle Database 12cリリース12.1 (12.1.0.2)で使用できます)

ALTER PLUGGABLE DATABASE DISABLE RECOVERY文はPDBに属するすべてのデータ・ファイルをオフラインにし、PDBのリカバリを無効にします。PDBに属するデータ・ファイルはPDBが再度有効になるまで、リカバリ・セッションに含まれません。リカバリが無効な間に作成された新しいデータ・ファイルは、名前なしファイルとして作成され、オフラインにマークされます。

PDBに属するすべてのデータ・ファイルをオフラインに戻し、リカバリを有効にするには、PDBに接続し、閉じていることを確認し(V$PDBSビューのOPEN_MODE列がMOUNTEDの値を示す)、SQL文ALTER PLUGGABLE DATABASE ENABLE RECOVERYを発行します。(このSQL文はOracle Database 12cリリース12.1 (12.1.0.2)で使用できます)

PDBでリカバリが有効か無効かを確認するには、次のようにV$PDBSビューを問い合せます。

SQL> SELECT RECOVERY_STATUS FROM V$PDBS;

注意:

ALTER PLUGGABLE DATABASE [ENABLE | DISABLE] 操作の結果として、オンラインまたはオフラインになったファイルは、その操作が実行される前のポイントにデータベースをフラッシュバックする場合でも、その状態のままです。

関連項目:

• プライマリでのPDB PITR後にスタンバイで必要なアクションの詳細は、「プライマリでのPDB PITR後にスタンバイで必要なアクション」を参照してください

• プライマリでのTSPITRまたは表領域プラグイン後にスタンバイで必要なアクションの詳細は、「プライマリでのTSPITRまたは表領域プラグイン後のスタンバイで必要なアクション」を参照してください