1. データベース・バックアップおよびリカバリ・ユーザーズ・ガイド
  2. 障害の診断および対応
  3. データベースの完全リカバリの実行

17 データベースの完全リカバリの実行

この章では、1つ以上のデータファイルが消失した後、RMANを使用してデータベースを通常の稼働状態に戻す方法について説明します。この章のトピックは、次のとおりです:

17.1 データベースの完全リカバリの概要

この項では、データベースの完全リストアおよびリカバリの目的およびこの章の概要について説明します。

この項では、次の項目について説明します。

17.1.1 データベースの完全リカバリの目的

この章では、データファイルの一部またはすべてが消失または破損したと想定しています。通常、この状況は、メディア障害または誤った削除によって発生します。破損したファイルをRMANバックアップからリストアし、すべてのデータベース変更をリカバリすることによって、データベースを通常の稼働状態に戻す必要があります。

17.1.2 この章の概要

この章では、完全リカバリを使用して最も一般的なデータベースの問題を解決する方法について説明します。この章では、次のことを想定しています。

  • 一部またはすべてが消失したデータファイルがあり、すべての変更をリカバリすることが目標です。ただし、現行のすべての制御ファイルまたはオンラインREDOログ・グループ全体は消失していません。

  • データベースでは、現行のサーバー・パラメータ・ファイルが使用されています。

  • データファイルのバックアップのリカバリに必要なすべてのアーカイブREDOログおよび増分バックアップが存在します。すべてのデータファイルには、バックアップ、またはバックアップなしでデータファイルを作成した時点からのすべてのオンラインおよびアーカイブREDOログが存在します。

    RMANは、リストアおよびリカバリ時に、消失したデータファイルを処理できます。ユーザーが手動で操作を行う必要はありません。データファイルが消失している場合、次のような状況が考えられます。

    • 制御ファイルにデータファイルのレコードが含まれている(データファイルの作成後に制御ファイルをバックアップしているが、データファイル自体はバックアップしていない)。 データファイルのレコードが制御ファイルに含まれている場合、RESTOREを実行すると、元の場所またはユーザーが指定する場所にデータファイルが作成されます。その後、RECOVERコマンドを実行すると、必要なログをデータファイルに適用できます。

    • 制御ファイルにデータファイルのレコードが含まれていない(データファイルの作成後に制御ファイルをバックアップしていない)。 リカバリ時に、データベースは、欠落しているデータファイルを検出してRMANに報告し、RMANは、データファイルを作成し、残りのログを適用してリカバリを続行します。データファイルが親インカネーション内に作成されている場合は、必要に応じて、リストアまたはリカバリ・フェーズ中にデータファイルが作成されます。

  • 暗号化された表領域は、リストアおよびリカバリしません。

    暗号化された表領域でメディア・リカバリを実行する場合は、この表領域のメディア・リカバリの実行時に、Oracleキーストアをオープンする必要があります。

  • データベースは、シングル・インスタンス構成で実行されています。

    RMANは、Oracle RACおよびData Guard構成でデータベースをリストアおよびリカバリできますが、このマニュアルではこれらの例については説明しません。

  • Oracle Enterprise ManagerではなくRMANクライアントを使用しています。

関連項目:

17.1.3 リカバリ・アプライアンスのリアルタイムREDOトランスポートについて

Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)では、連続するアーカイブ・ログの各バックアップの間に存在する潜在的なデータ損失の期間を大幅に短縮できます。リアルタイムREDOトランスポートを使用すると、データベース障害から最大で数秒以内にターゲット・データベースをリカバリできます。

注意:

リアルタイムREDOトランスポートは、リカバリ・アプライアンスでのみ使用できます。

リアルタイムREDOトランスポートがターゲット・データベースに対して構成されている場合、現在のREDOログ・グループのREDOデータが生成時にリカバリ・アプライアンスに非同期に書き込まれます。REDOストリームが受信されると、REDOストリームは完全なRMANのアーカイブREDOログとして格納されます。ターゲット・データベースがクラッシュすると、クラッシュ時点までに現在のREDOログ・グループから受信したREDOデータがリストアおよびリカバリ操作時に使用されます。

ターゲット・データベースに対するリアルタイムREDOトランスポートを有効にするには、特定の構成手順を実行する必要があります。

関連項目:

リアルタイムREDOトランスポートの構成手順は、『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』を参照してください。

17.2 データベースの完全リカバリの準備

RMANによってデータベースのほとんどのリストアおよびリカバリ・タスクは簡単になりますが、データベースのリストアおよびリカバリ計画は、消失したデータベース・ファイルおよびリカバリの目標に基づいて作成する必要があります。この項では、次の項目について説明します。

17.2.1 リストアまたはリカバリするデータファイルの識別

リストアまたはリカバリが必要なファイルを判別する方法は、消失したファイルのタイプによって異なります。

この項では、次の項目について説明します。

17.2.1.1 消失した制御ファイルの識別

通常、データベースの制御ファイルが消失した日時は明らかです。多重制御ファイルのいずれかがアクセス不可能になると、データベースは即時に停止します。また、CONTROL_FILES初期化パラメータに指定された有効な制御ファイルがそれぞれの場所に存在しない状態でデータベースを起動しようとした場合も、データベースによってエラーがレポートされます。

制御ファイルのコピーのすべてではなく一部が消失した場合は、バックアップから制御ファイルをリストアする必要はありません。影響を受けていない制御ファイルが1つ以上存在する場合は、影響を受けていない制御ファイルを破損または消失した制御ファイルにコピーするか、または破損または消失した制御ファイルを参照しないように初期化パラメータ・ファイルを更新することができます。存在し、影響を受けていない制御ファイルのコピーのみをCONTROL_FILESパラメータが参照するようにした後で、データベースを再起動できます。

制御ファイルをバックアップからリストアする場合は、データファイルをリストアする必要がない場合でも、データベース全体のメディア・リカバリを実行してから、OPEN RESETLOGSオプションを使用してデータベースをオープンする必要があります。この方法については、「バックアップ制御ファイルを使用したリカバリの実行」を参照してください。

17.2.1.2 メディア・リカバリが必要なデータファイルの識別

リカバリを実行するタイミングと方法の決定は、データベースの状態とデータファイルの場所によって異なります。

RMANまたはSQL*Plusを使用して、メディア・リカバリを必要とするデータファイルを識別します。

関連項目:

17.2.1.2.1 RMANによるデータファイルの識別

欠落しているデータファイルを判別する簡単な方法は、指定したすべてのデータファイルの読取りを試行するVALIDATE DATABASEコマンドを実行することです。例17-1では、データベースを検証します(出力例も示します)。

例17-1 VALIDATE DATABASE

RMAN> VALIDATE DATABASE;

Starting validate at 20-OCT-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=90 device type=DISK
could not read file header for datafile 7 error reason 4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 10/20/2013 13:05:43
RMAN-06056: could not access datafile 7
例17-1の出力は、データファイル7がアクセス不可能であることを示しています。この場合は、REPORT SCHEMAコマンドを次のように実行して、データファイル7の表領域名およびファイル名を取得できます(出力例も示します)。
RMAN> REPORT SCHEMA;
 
Report of database schema for database with db_unique_name RDBMS
 
List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    450      SYSTEM               ***     +DATAFILE/tbs_01.f
2    86       SYSAUX               ***     +DATAFILE/tbs_ax1.f
3    15       UD1                  ***     +DATAFILE/tbs_undo1.f
4    2        SYSTEM               ***     +DATAFILE/tbs_02.f
5    2        TBS_1                ***     +DATAFILE/tbs_11.f
6    2        TBS_1                ***     +DATAFILE/tbs_12.f
7    2        TBS_2                ***     +DATAFILE/tbs_21.f
 
List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    40       TEMP                 32767       +DATAFILE/tbs_tmp1.f
17.2.1.2.2 SQLによるデータファイルの識別

VALIDATE DATABASEはファイルがアクセス不可能かどうかを確認する場合の最適な方法ですが、SQL問合せを使用してより詳細な情報を取得する必要がある場合があります。

データファイルにメディア・リカバリが必要かどうかを確認する手順

  1. SQL*Plusを起動し、管理者権限でターゲット・データベース・インスタンスに接続します。
  2. 次のSQL問合せを実行して、データベースのステータスを確認します。
    SELECT STATUS FROM V$INSTANCE;

    状態がOPENの場合、データベースはオープン状態です。ただし、一部のデータファイルにメディア・リカバリが必要な場合があります。

  3. V$DATAFILE_HEADERを問い合せて、データファイルのステータスを確認します。次のSQL文を実行して、データファイルのヘッダーを確認します。 
    SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME 
FROM   V$DATAFILE_HEADER 
WHERE  RECOVER = 'YES' 
OR     (RECOVER IS NULL AND ERROR IS NOT NULL);

    戻される各行は、メディア・リカバリが必要なデータファイルまたはリストアが必要なエラー発生しているデータファイルを表します。RECOVERおよびERROR列を確認します。RECOVERには、ファイルにメディア・リカバリが必要かどうかが示され、ERRORには、データファイルのヘッダーの読取り時および検証時にエラーが発生したかどうかが示されます。

    ERRORがNULLでない場合は、データファイルのヘッダーの読取りおよび検証は実行できません。エラーの原因となるハードウェアまたはオペレーティング・システムの一時的な問題がないかどうかを確認します。問題がない場合は、ファイルをリストアするか、コピーに切り替える必要があります。

    ERROR列がNULLで、RECOVER列がYESの場合、ファイルにはメディア・リカバリが必要です(バックアップからリストアする必要がある場合もあります)。

    注意:

    V$DATAFILE_HEADERは各データファイルのヘッダー・ブロックのみを読み取るため、データファイルのリストアが必要となるすべての問題を検出するわけではありません。たとえば、このビューではデータファイルに破損したデータ・ブロックが含まれているかどうかは確認できません。

  4. 必要に応じて、V$RECOVER_FILEを問い合せて、リカバリが必要なデータファイルをそのステータス情報およびエラー情報とともにデータファイル番号で表示します。たとえば、次の問合せを実行します。
    SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME 
FROM   V$RECOVER_FILE;

    注意:

    V$RECOVER_FILEは、バックアップからリストアされた制御ファイル、またはデータファイルに影響を及ぼすメディア障害の発生後に再作成された制御ファイルには使用できません。リストアされた制御ファイルまたは再作成された制御ファイルには、V$RECOVER_FILEを正確に更新するために必要な情報が含まれていません。

    データファイルおよび表領域の名前を取得するために、次の例に示すとおり、データファイル番号、V$DATAFILEビューおよびV$TABLESPACEビューを使用して、結合を実行することもできます。 

    SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, 
       d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;

    ERROR列で、リカバリが必要な各ファイルに関する問題を識別します。

関連項目:

17.2.2 データベースのDBIDの確認

自動バックアップからのサーバー・パラメータ・ファイルまたは制御ファイルのリカバリが必要な状況では、DBIDがわかっている必要があります。DBIDは、データベースに関する他の基本情報とともに記録するようにしてください。

データベースのDBIDの記録がない場合は、データベースをオープンせずに次の場所で参照することができます。

  • DBIDは、制御ファイルの自動バックアップのファイル名の一部に使用されています。制御ファイルを検索した後、「制御ファイルの自動バックアップ書式の構成」を参照して、ファイル名のどこにDBIDが表示されるかを確認します。

  • RMANセッションからの出力を保持するテキスト・ファイルがある場合、DBIDは、RMANクライアントが起動してデータベースに接続する際に表示されます。通常の出力を次に示します。

    % rman TARGET /

Recovery Manager: Release 12.1.0.1.0 - Production on Wed Jan 16 17:51:30 2013
 
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.
 
connected to target database: PROD (DBID=36508508)

17.2.3 リストア操作で使用されるバックアップのプレビュー

RESTORE ... PREVIEWを任意のRESTORE操作に適用すると、要求されたRESTORE操作で使用されるすべてのバックアップ、およびRESTORE操作完了後のリカバリに必要な目的のSCNの詳細なリストを作成できます。このコマンドは、RMANリポジトリにアクセスしてバックアップ・メタデータを問い合せますが、実際にバックアップ・ファイルを読み取ってリストア可能であることは確認しません。

RESTORE ... PREVIEWの代替として、RESTORE ... VALIDATE HEADERコマンドを使用できます。RESTORE ... VALIDATE HEADERコマンドは、リストアおよびリカバリに必要なファイルを一覧表示する以外に、バックアップ・ファイル・ヘッダーを検証して、ディスク上またはメディア管理カタログ内のファイルが、RMANリポジトリのメタデータに対応しているかどうかを確認します。

リストアおよびリカバリ操作を計画する場合は、RESTORE ... PREVIEWまたはRESTORE ... VALIDATE HEADERを使用して、必要なすべてのバックアップが使用可能であることを確認するか、または特定のバックアップの使用または回避をRMANに指示する必要がある状況を識別します。

リストア操作で使用されるバックアップをプレビューする手順

  1. PREVIEWオプションを指定してRESTOREコマンドを実行します。

    たとえば、次のいずれかのコマンドを実行します。

    RESTORE DATABASE PREVIEW;
RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW;

    RESTORE ... PREVIEWによって生成されるレポートの情報が多すぎる場合は、次の例に示すようにSUMMARYオプションを指定します。 

    RESTORE DATABASE PREVIEW SUMMARY;

    出力が適切である場合は、ここで停止します。一時的に使用できないことがわかっているテープからのバックアップをRMANが要求することが出力に示された場合は、この手順を続行します。バックアップがオフサイトに格納されていることが出力に示された場合は、「オフサイト・バックアップのリコール」に進みます。

  2. 必要に応じて、CHANGEコマンドを使用して、一時的に使用できないバックアップのバックアップ・ステータスをUNAVAILABLEに設定します。

    このタスクの実行方法については、「AVAILABLEまたはUNAVAILABLEへのバックアップのステータスの更新」を参照してください。

  3. 必要に応じて、RESTORE ... PREVIEWを再度実行して、使用できないバックアップがリストア操作で使用されないことを確認します。

関連項目:

RESTORE ... PREVIEWの出力(LISTコマンドの出力と同じ書式)の解釈の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

17.2.3.1 オフサイト・バックアップのリコール

一部のメディア・マネージャは、オフサイトにあるバックアップに関するステータス情報をRMANに提供します。オフサイト・バックアップは、安全なストレージ設備などのリモートの場所に格納され、メディア・マネージャがメディアを取り込まないかぎりリストアできません。

バックアップをリストアする前にストレージからメディアを取り込む必要がある場合でも、オフサイト・バックアップは、RMANリポジトリでAVAILABLEとマークが付けられます。RMANがオフサイト・バックアップのリストアを試みると、リストア・ジョブに失敗します。

オフサイト・バックアップをリコールする手順

  1. (オプション) RESTORE ... PREVIEWコマンドを使用して、オフサイト・バックアップを識別します。次の例のサンプル出力の後のテキストに示すように、コマンドの出力には、バックアップがオフサイトに格納されたかどうかが示されます。
    List of Backup Sets
===================


BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
9       2.25M      SBT_TAPE    00:00:00     21-MAY-13
        BP Key: 9   Status: AVAILABLE  Compressed: NO  Tag: TAG20130521T144258
        Handle: 0aii9k7i_1_1   Media: 0aii9k7i_1_1
 
  List of Archived Logs in backup set 9
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    1       392314     21-MAY-13 392541     21-MAY-13
  1    2       392541     21-MAY-13 392545     21-MAY-13
  1    3       392545     21-MAY-13 392548     21-MAY-13
  1    4       392548     21-MAY-13 395066     21-MAY-13
  1    5       395066     21-MAY-13 395095     21-MAY-13
  1    6       395095     21-MAY-13 395355     21-MAY-13
 
List of remote backup files
============================
        Handle: aii9k7i_1_1   Media: 0aii9k7i_1_1
validation succeeded for backup piece
Finished restore at 21-MAY-13
released channel: dev1

    RESTORE ... PREVIEW RECALLを使用すると、オフサイト・バックアップを使用可能にするようにメディア・マネージャに指示できます。

  2. バックアップがオフサイトに格納されている場合、RECALLオプションを指定してRESTORE ... PREVIEWコマンドを実行します。

    次の例では、前の手順に示されているオフサイト・アーカイブ・ログのバックアップのリコールを開始します(出力例も示します)。

    RESTORE ARCHIVELOG ALL PREVIEW RECALL;

    次のサンプル出力は、RMANがリコールを開始したことを示しています。

    List of Backup Sets
===================
 
 
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
9       2.25M      SBT_TAPE    00:00:00     21-MAY-13
        BP Key: 9   Status: AVAILABLE  Compressed: NO  Tag: TAG20130521T144258
        Handle: VAULT0aii9k7i_1_1   Media: /tmp,VAULT0aii9k7i_1_1
 
  List of Archived Logs in backup set 9
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    1       392314     21-MAY-13 392541     21-MAY-13
  1    2       392541     21-MAY-13 392545     21-MAY-13
  1    3       392545     21-MAY-13 392548     21-MAY-13
  1    4       392548     21-MAY-13 395066     21-MAY-13
  1    5       395066     21-MAY-13 395095     21-MAY-13
  1    6       395095     21-MAY-13 395355     21-MAY-13
 
Initiated recall for the following list of remote backup files
==========================================================
        Handle: VAULT0aii9k7i_1_1   Media: /tmp,VAULT0aii9k7i_1_1
validation succeeded for backup piece
Finished restore at 21-MAY-13
released channel: dev1
  3. RESTORE ... PREVIEWコマンドを実行します。必要に応じて、リストア操作に必要なバックアップがオフサイトとしてレポートされなくなるまで、前の手順に戻ります。

17.2.4 リストアする前のバックアップの検証

「リストア操作で使用されるバックアップのプレビュー」の手順では、リストアされるバックアップは示されますが、それらのバックアップが実際に使用可能であることは検証されません。RMANコマンドを実行して、RESTORE操作で使用可能なバックアップの可用性またはRESTORE操作で使用される特定のバックアップの内容をテストできます。バックアップの内容が実際に読み取られ、破損が確認されます。次の検証オプションがあります。

  • RESTORE ... VALIDATEを実行すると、RMANで特定のオブジェクトをバックアップからリストアできるかどうかがテストされます。RMANによって、使用するバックアップが選択されます。

  • VALIDATE BACKUPSETは、指定するバックアップ・セットの妥当性をテストします。

    関連項目:

    データベース・ファイルおよびバックアップの検証

17.2.5 リカバリに必要なアーカイブREDOログのリストア

RMANは、リカバリを実行するために、必要に応じてアーカイブREDOログ・ファイルをバックアップから自動的にリストアします。また、後でRECOVERコマンド中にこれらのファイルのリストアに必要となる時間を節約するために、またはリストアされたアーカイブREDOログ・ファイルを新しい場所に格納する場合に、アーカイブREDOログを手動でリストアすることもできます。RMANでは、すべてのアーカイブREDOログ・ファイル、現行のREDOログ・ファイルまたは指定されたデータベースの以前のインカネーションからのアーカイブREDOログ・ファイルをリストアすることもできます。

アーカイブREDOログが障害時リカバリ中に見つからない場合に備えて、RMANでは、UNTIL AVAILABLE REDOオプションを使用して、使用可能な最後のアーカイブREDOログまでデータベース・リカバリを自動化できます。このオプションは、データベース全体のリカバリを実行するときにのみ使用できます。データファイル、表領域またはプラガブル・データベースへのこのオプションの使用は、サポートされません。プラガブル・データベースに対してPoint-in-Timeリカバリを実行するには、リカバリのポイントとしてSCN番号を指定する必要があります。

デフォルトでは、RMANは、ターゲット・データベースのLOG_ARCHIVE_FORMATおよび最大のLOG_ARCHIVE_DEST_nパラメータを使用して構成された名前でアーカイブREDOログをリストアします。これらのパラメータがプラットフォーム固有の形式で組み合され、リストアされたアーカイブ・ログの名前が構成されます。

この項では、次の項目について説明します。

17.2.5.1 新しい場所へのアーカイブREDOログのリストア

SET ARCHIVELOG DESTINATIONコマンドを使用すると、リストアしたアーカイブREDOログのデフォルトの名前を上書きできます。このコマンドによって、アーカイブ・ログは、データベースのリストア操作中に別の場所に手動でステージングされます。リカバリ中、RMANは新しくリストアされたアーカイブ・ログを検索する場所を認識するため、初期化パラメータ・ファイルで指定された場所にアーカイブ・ログが存在している必要はありません。

アーカイブREDOログを新しい場所へリストアする手順

  1. RMANを起動し、ターゲット・データベースに接続します。

    関連項目:

    「RMANによるデータベース接続の確立」

  2. データベースがマウントまたはオープンされていることを確認します。

  3. RUNコマンド内で、次の操作を実行します。

    1. SET ARCHIVELOG DESTINATIONを使用して、リストアするアーカイブREDOログの新しい場所を指定します。

    2. アーカイブREDOログを明示的にリストアするか、またはログを自動的にリストアするコマンドを実行します。

    次の例のRUNコマンドは、すべてのバックアップ・アーカイブ・ログを新しい場所に明示的にリストアします。 

    RUN
{ 
  SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
  RESTORE ARCHIVELOG ALL;
  # restore and recover data files as needed
  .
  .
  .
}

    次の例では、アーカイブ・ログの宛先を設定し、RECOVER DATABASEを使用してアーカイブ・ログをこの宛先から自動的にリストアします。 

    RUN
{ 
  SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore';
  RESTORE DATABASE;
  RECOVER DATABASE; # restores and recovers logs automatically
}
17.2.5.2 複数の場所へのアーカイブREDOログのリストア

アーカイブ・ログのリストア先を1つのRUNブロックに複数回指定して、リストアしたログを複数のリストア先に分散できます。(ただし、同時に複数のリストア先を指定して、リストア操作時に同じログの複数のコピーを生成することはできません。)この機能を使用して、リストアしたログを格納するために使用するディスク領域を管理できます。

次の例では、バックアップから300のアーカイブREDOログをリストアし、ログをディレクトリ/fs1/tmp、/fs2/tmpおよび/fs3/tmpに分散します。 

RUN 
{ 
  # Set a new location for logs 1 through 100.
  SET ARCHIVELOG DESTINATION TO '/fs1/tmp';
  RESTORE ARCHIVELOG FROM SEQUENCE 1 UNTIL SEQUENCE 100;
  # Set a new location for logs 101 through 200.
  SET ARCHIVELOG DESTINATION TO '/fs2/tmp';
  RESTORE ARCHIVELOG FROM SEQUENCE 101 UNTIL SEQUENCE 200;
  # Set a new location for logs 201 through 300.
  SET ARCHIVELOG DESTINATION TO '/fs3/tmp';
  RESTORE ARCHIVELOG FROM SEQUENCE 201 UNTIL SEQUENCE 300;
  # restore and recover data files as needed
  .
  .
  .
}

RECOVERコマンドを発行すると、リストアした必要なアーカイブ・ログがリストア先で自動的に検出され、データファイルに適用されます。

17.2.6 暗号化バックアップの復号化に必要なパスワードの指定

バックアップが暗号化されている場合、RMANはコンテンツのリストア中にこれらのバックアップを複合化します。暗号化バックアップの作成に使用した暗号化モードによっては、これらの暗号化バックアップをリストアする前に、追加手順の実行が必要になることがあります。

自動ログイン・キーストアを使用し、透過的暗号化を使用して暗号化されたバックアップの場合、キーストアが使用可能であれば、リストアにユーザーの介入は不要です。パスワードベースのソフトウェア・キーストアを使用して暗号化されたバックアップの場合、キーストアが使用可能であることが必要なことに加え、キーストア・パスワードを指定する必要があります。キーストア・パスワードはキーストアをオープンするために使用され、リストア操作を実行する前に指定する必要があります。DECRYPTION WALLET OPEN IDENTIFIED BYオプションを指定してSETコマンドを使用し、キーストアをオープンするために使用するパスワードを指定します。

次のコマンドでは、パスワードベースのソフトウェア・キーストアのキーストア・パスワードを設定します(passwordは、入力する実際のパスワードのプレースホルダ)。 

SET DECRYPTION WALLET OPEN IDENTIFIED BY password;

パスワードモード暗号化を使用して作成されたバックアップの場合、リストアする前に正しいパスワードを入力する必要があります。SET DECRYPTIONコマンドを使用し、バックアップの復号化に使用するパスワードを指定します。異なるパスワードを使用して作成されたバックアップのグループからリストアを行う場合は、SET DECRYPTIONコマンドで、必要なパスワードをすべて指定します。各バックアップ・セットで正しいパスワードが自動的に使用されます。SETコマンドは、RESTOREおよびRECOVERコマンドを実行する前に使用する必要があります。

次のコマンドは、バックアップを復号化するために使用するパスワードを設定します(passwordは、入力する実際のパスワードのプレースホルダ)。 

SET DECRYPTION IDENTIFIED BY password;

関連項目:

暗号化バックアップを使用したリストア操作の実行の詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。

17.3 データベースの完全リカバリの実行

完全なリカバリ中、RMANでは1つ以上のデータファイルをリストアし、バックアップのリストア後に生成されたすべてのREDOを適用します。

この項では、広範囲の様々な例に対応することを目的としているデータベースの完全リカバリの概要について説明します。

この項では、次の項目について説明します。

17.3.1 データベースの完全リカバリ

データベースをリストアおよびリカバリするには、RESTOREおよびRECOVERコマンドを使用します。リカバリ中、RMANは、必要なアーカイブREDOログのバックアップを自動的にリストアします。バックアップがメディア・マネージャに格納されている場合は、チャネルを事前に構成しておくか、またはALLOCATE CHANNELコマンドを含むRUNブロックを使用して、そこに格納されているバックアップへのアクセスを有効にする必要があります。

RMANは、リカバリ中にアーカイブREDOログを高速リカバリ領域にリストアする場合、リストアしたログを、データファイルに適用した後で自動的に削除します。そうでない場合は、リストアしたアーカイブREDOログがリカバリに必要でなくなった後、DELETE ARCHIVELOGコマンドを使用して、それらのアーカイブREDOログをディスクから削除できます。たとえば、次のコマンドを入力できます。 

RECOVER DATABASE DELETE ARCHIVELOG;
17.3.1.1 デフォルト以外の場所へのデータファイルのリストアについて

データファイルをデフォルトの場所にリストアできない場合は、データファイルの新しい場所が反映されるように、制御ファイルを更新する必要があります。RMANのSET NEWNAMEコマンドをRUNコマンド内で使用して、新しいファイル名を指定します。その後、SQL文ALTER DATABASE RENAME FILEと同じ動作をするSWITCHコマンドを使用し、制御ファイル内のデータファイルの名前を更新します。SWITCH DATAFILE ALLを実行すると、制御ファイルに、RUNコマンドでSET NEWNAMEが発行されているすべてのデータファイルの新しい名前が反映されます。

関連項目:

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

17.3.2 データベース全体の完全リカバリの実行

この例では、データベースtrgtのほとんどまたはすべてのデータファイルが消失したと想定しています。また、データベースで高速リカバリ領域が使用されているとも想定しています。

データベース全体のリストアおよびリカバリの後で、データベースがオープンされると、制御ファイルに記録された欠落している一時表領域は、以前の作成サイズ、AUTOEXTENDおよびMAXSIZE属性で再作成されます。欠落している一時表領域のみが再作成されます。RMANリポジトリに記録された場所に存在する一時ファイルのヘッダーが無効な場合、RMANは一時ファイルを再作成しません。

一時ファイルがOracle Managed Filesとして作成されていた場合は、現在のDB_CREATE_FILE_DESTの場所に再作成されます。そうでない場合は、以前の場所で再作成されます。RMANがI/Oエラーまたは他の原因でファイルを再作成できない場合、エラーがアラート・ログにレポートされ、データベースのオープン操作が続行されます。

関連項目:

リカバリ手順で使用されるいくつかの前提の「この章の概要」

データベース全体をリストアおよびリカバリする手順

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します。
  2. RMANを開始し、「RMANによるデータベース接続の確立」の説明に従ってターゲット・データベースに接続します。

    RMANは、接続時にnot started、not mounted、not open(データベースはマウントされているがオープンされていない場合)またはnone(データベースがオープンされている場合)のいずれかのデータベース・ステータスを表示します。

  3. データベースがマウントされていない場合は、データベースをマウントします。ただし、オープンはしません。

    たとえば、次のコマンドを入力します。

    STARTUP MOUNT;
  4. SHOWコマンドを使用して、事前構成済のチャネルを確認します。

    たとえば、次のコマンドを入力します(出力例も示します)。

    SHOW ALL;

 
RMAN configuration parameters for database with db_unique_name PROD1 are:
.
.
.
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS "SBT_
LIBRARY=/usr/local/oracle/backup/lib/libobk.so";

    必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

  5. パスワード保護された暗号化バックアップをリストアする場合は、パスワードを指定します。

    次の例に示すように、SET DECRYPTION IDENTIFIED BYコマンドを使用して、パスワード保護されたバックアップのパスワードを指定します(passwordは実際に入力するパスワードを表します)。 

    SET DECRYPTION IDENTIFIED BY password;

    異なるパスワードでバックアップを作成した場合は、バックアップのリストアに必要となる可能性のあるすべてのパスワードを指定してSET DECRYPTION IDENTIFIED BY passwordコマンドを複数回実行できます。

  6. データベースをリストアおよびリカバリします。次の内の1つを実行します。

    • すべてのデータファイルを元の場所にリストアする場合は、RMANプロンプトでRESTORE DATABASEとRECOVER DATABASEを順に実行します。

      たとえば、自動チャネルが構成されている場合は、次のコマンドを入力します(出力例も示します)。

      RMAN> RESTORE DATABASE;

Starting restore at 20-JUN-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=35 device type=DISK
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /disk1/oracle/dbs/tbs_01.f
channel ORA_DISK_1: restoring datafile 00002 to /disk1/oracle/dbs/tbs_ax1.f
.
.
.
Finished restore at 20-JUN-13

      RMAN> RECOVER DATABASE;

Starting recover at 20-JUN-13
using channel ORA_DISK_1
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
starting media recovery
 
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=6
.
.
.
channel ORA_DISK_1: reading from backup piece
 /disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp
channel ORA_DISK_1: piece
 handle=/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp tag=TAG20130620T113128
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
20/o1_mf_1_5_29jhv47k_.arc thread=1 sequence=5
channel default: deleting archived log(s)
.
.
.
media recovery complete, elapsed time: 00:00:15
Finished recover at 20-JUN-13

      チャネルを手動で割り当てる場合は、RESTOREおよびRECOVERコマンドをRUNブロック内で同時に発行する必要があります。次に例を示します。 

      RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
  RESTORE DATABASE;
  RECOVER DATABASE;
}

    • 一部のデータファイルを新しい場所にリストアする場合は、RUNコマンドでRESTORE DATABASEとRECOVER DATABASEを順に実行します。「デフォルト以外の場所へのデータファイルのリストアについて」で説明するように、SET NEWNAMEコマンドを使用して、データファイルの名前を変更します。

      次の例では、データベースをリストアし、3つのデータファイルに新しい名前を指定してから、データベースをリカバリします。

      RUN
{  
  SET NEWNAME FOR DATAFILE 2 TO '/disk2/df2.dbf';
  SET NEWNAME FOR DATAFILE 3 TO '/disk2/df3.dbf';
  SET NEWNAME FOR DATAFILE 4 TO '/disk2/df4.dbf';
  RESTORE DATABASE;
  SWITCH DATAFILE ALL;
  RECOVER DATABASE;
}
  7. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、データベースをオープンします。

    たとえば、次のコマンドを入力します。

    ALTER DATABASE OPEN;

17.3.3 表領域の完全リカバリの実行

TABLESPACEオプションとともにRESTOREおよびRECOVERコマンドを使用して、表領域の完全リカバリを実行します

リカバリ手順で使用されるいくつかの前提の「この章の概要」

基本的な例では、データベースはオープンされており、データファイルのすべてではなく一部が破損しています。データベースの残りの部分を使用可能にしておくために、データベースはオープンしたままで、破損した表領域をリストアおよびリカバリします。この例では、データベースTRGTの表領域USERSが消失したと想定しています。

表領域をリストアおよびリカバリする手順

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します。
  2. RMANを開始し、「RMANによるデータベース接続の確立」の説明に従ってターゲット・データベースに接続します。
  3. データベースがオープンされている場合は、リカバリが必要な表領域をオフラインにします。

    たとえば、次のコマンドを入力してUSERSをオフラインにします。 

    ALTER TABLESPACE users OFFLINE IMMEDIATE;
  4. SHOWコマンドを使用して、事前構成済のチャネルを確認します。

    たとえば、次のコマンドを入力します(出力例も示します)。

    SHOW ALL;

RMAN configuration parameters for database with db_unique_name PROD1 are:
.
.
.
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  "SBT_
LIBRARY=/usr/local/oracle/backup/lib/libobk.so";

    必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

  5. パスワード保護された暗号化バックアップをリストアする場合は、パスワードを指定します。

    次の例に示すように、SET DECRYPTION IDENTIFIED BYコマンドを使用して、パスワード保護されたバックアップのパスワードを指定します(passwordは実際に入力するパスワードを表します)。 

    SET DECRYPTION IDENTIFIED BY password;
  6. 表領域をリストアおよびリカバリします。次の内の1つを実行します。

    • データファイルを元の場所にリストアする場合は、RMANプロンプトでRESTORE TABLESPACEとRECOVER TABLESPACEコマンドを実行します。

      たとえば、自動チャネルが構成されている場合は、次のコマンドを入力します(出力例も示します)。

      RMAN> RESTORE TABLESPACE users;
 
Starting restore at 20-JUN-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=37 device type=DISK
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=38 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Oracle Secure Backup
 
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00012 to /disk1/oracle/dbs/users01.f
channel ORA_DISK_1: restoring datafile 00013 to /disk1/oracle/dbs/users02.f
channel ORA_DISK_1: restoring datafile 00021 to /disk1/oracle/dbs/users03.f
channel ORA_DISK_1: reading from backup piece
 /disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_nnndf_
TAG20130620T105435_29jflwor_.bkp
channel ORA_DISK_1: piece
 handle=/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_nnndf_
TAG20130620T105435_29jflwor_.bkp tag=TAG20130620T105435
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 20-JUN-13

      RMAN> RECOVER TABLESPACE users;
 
Starting recover at 20-JUN-13
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1
 
starting media recovery
 
archived log for thread 1 with sequence 27 is on disk as file
 /disk1/oracle/work/orcva/TKRM/archivelog/2013_06_20/o1_mf_1_27_29jjmtc9_.arc
archived log for thread 1 with sequence 28 is on disk as file
 /disk1/oracle/work/orcva/TKRM/archivelog/2013_06_20/o1_mf_1_28_29jjnc5x_.arc
.
.
.
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=5
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=6
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=7
.
.
.
channel ORA_DISK_1: reading from backup piece
 /disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp
channel ORA_DISK_1: piece
 handle=/disk1/oracle/work/orcva/TKRM/backupset/2013_06_20/o1_mf_annnn_
TAG20130620T113128_29jhr197_.bkp tag=TAG20130620T113128
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
20/o1_mf_1_5_29jkdvjq_.arc thread=1 sequence=5
channel default: deleting archived log(s)
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
20/o1_mf_1_5_29jkdvjq_.arc RECID=91 STAMP=593611179
archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2013_06_
20/o1_mf_1_6_29jkdvbz_.arc thread=1 sequence=6
channel default: deleting archived log(s)
.
.
.
media recovery complete, elapsed time: 00:00:01
Finished recover at 20-JUN-13

    • 一部のデータファイルを新しい場所にリストアする場合は、RUNコマンドでRESTORE TABLESPACEとRECOVER TABLESPACEを実行します。「デフォルト以外の場所へのデータファイルのリストアについて」で説明するように、SET NEWNAMEコマンドを使用して、データファイルの名前を変更します。

      次の例では、表領域users内のデータファイルを新しい場所にリストアした後、リカバリを実行します。古いデータファイルは/disk1パスに格納されており、新しいデータファイルは/disk2パスに格納されると想定しています。 

      RUN
{
  # specify the new location for each datafile
  SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users01.f' TO 
                           '/disk2/users01.f';
  SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users02.f' TO 
                           '/disk2/users02.f';
  SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users03.f' TO 
                           '/disk2/users03.f';
  RESTORE TABLESPACE users;
  SWITCH DATAFILE ALL;   # update control file with new file names
  RECOVER TABLESPACE users;
}
  7. 出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、リカバリした表領域をオンラインに戻します。

    たとえば、次のコマンドを入力します。

    ALTER TABLESPACE users ONLINE;

17.3.4 コピーへの切替え後の完全リカバリの実行

アクセスできないデータファイルのイメージ・コピーが高速リカバリ領域に存在する場合、SWITCH DATAFILE ... TO COPYコマンドを使用して制御ファイルをデータファイルのコピーにポイントしてからRECOVERを使用すると、消失した変更をリカバリできます。SWITCH DATABASE TO COPYコマンドを使用して、制御ファイルをデータベース全体のコピーにポイントすることもできます。バックアップをリストアする必要がないため、このリカバリ方法は従来のリストアおよびリカバリより時間がかかりません。

注意:

SWITCH TABLESPACE ... TO COPYコマンドは、表領域のすべてのデータファイルが消失し、すべてのデータファイルのコピーが存在する場合でもサポートされます。SWITCH DATABASE TO COPYについても同じ制限があります。

この項では、次の項目について説明します。

17.3.4.1 データファイルのコピーへの切替え

破損したデータファイルをリストアするかわりに、データファイルの既存のイメージ・コピーに切り替えることができます。

リカバリ手順で使用されるいくつかの前提の「この章の概要」

基本的な例では、データベースはオープンされており、データファイルのすべてではなく一部が破損しています。1日の中で、あるデータファイルがストレージ障害によって欠落します。このファイルを修復する必要がありますが、バックアップからリストアおよびリカバリする時間はありません。最新のイメージ・コピー・バックアップを新しいファイルとして使用して、リストア時間をなくします。この例では、データベースtrgtのデータファイル4が消失したと想定しています。

データファイルのコピーに切り替えてリカバリを実行する手順

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します。
  2. RMANを開始し、「RMANによるデータベース接続の確立」の説明に従ってターゲット・データベースに接続します。
  3. データベースがオープンされている場合は、リカバリが必要な表領域をオフラインにします。

    次のコマンドを入力してデータファイル4をオフラインにします。

    ALTER DATABASE DATAFILE 4 OFFLINE;
  4. オフラインのデータファイルを最新のコピーに切り替えます。

    次のコマンドを入力して、制御ファイルをデータファイル4の最新のイメージ・コピーにポイントします。

    SWITCH DATAFILE 4 TO COPY;
  5. RECOVER DATAFILEコマンドで、データファイルをリカバリします。

    次のコマンドを入力します。

    RECOVER DATAFILE 4;

    RMANは、アーカイブREDOログおよび増分バックアップを自動的にリストアします。データベースでは高速リカバリ領域が使用されるため、RMANは、これらを、適用した後に自動的に削除します。

  6. 出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、リカバリしたデータファイルをオンラインに戻します。

    次のコマンドを入力してデータファイル4をオンラインにします。

    ALTER DATABASE DATAFILE 4 ONLINE;
17.3.4.2 データベースのコピーへの切替え

これらのデータファイルをリストアするかわりに破損したデータファイルのイメージ・コピーに切り替えて、データベースの完全リカバリを実行できます。

リカバリ手順で使用されるいくつかの前提の「この章の概要」

この例では、データベースは停止しており、すべてのデータファイルが破損しています。すべての破損したデータファイルのイメージ・コピーを保有し、新しいデータファイルとして既存のイメージ・コピーを使用するため、リストア時間がなくなります。

データベースのコピーに切り替えてリカバリを実行する手順

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します。
  2. RMANを開始し、「RMANによるデータベース接続の確立」の説明に従ってターゲット・データベースに接続します。
  3. データベースをマウントします。
  4. データベースを最新のコピーに切り替えます。

    次のコマンドを入力して、制御ファイルをデータベースの最新のイメージ・コピーにポイントします。

    SWITCH DATABASE TO COPY;
  5. RECOVER DATABASEコマンドで、データベースをリカバリします。

    次のコマンドを入力します。

    RECOVER DATABASE;

    RMANは、アーカイブREDOログおよび増分バックアップを自動的にリストアします。データベースでは高速リカバリ領域が使用されるため、RMANは、これらを、適用した後に自動的に削除します。

  6. 出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、データベースをオープンします。

    データベースをオープンするには、次のコマンドを入力します。

    ALTER DATABASE OPEN;

17.4 CDBの完全リカバリの実行

RMANおよびOracle Enterprise Manager Cloud Control (Cloud Control)によって、マルチテナント環境でのバックアップとリカバリが完全にサポートされます。マルチテナント・コンテナ・データベース(CDB)全体、rootのみ、または1つ以上のプラガブル・データベース(PDB)をバックアップおよびリカバリできます。

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

17.4.1 CDB全体の完全リカバリの実行

CDB全体をリカバリする手順

CDB全体をリカバリする場合は、rootとすべてのPDBを1つの操作でリカバリします。

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します

  2. 「ターゲットとしてのrootへの接続」の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。

  3. データベースがマウントされていない場合は、データベースをマウントします。ただし、オープンはしません。次のgコマンドを使用します。

    STARTUP MOUNT;

  4. SHOWコマンドを使用して、事前構成済のチャネルを確認します。

    必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

  5. データベースをリストアおよびリカバリします。次の内の1つを実行します。

    • すべてのデータファイルを元の場所にリストアする場合は、RMANプロンプトでRESTORE DATABASEとRECOVER DATABASEを順に実行します。

      たとえば、自動チャネルが構成されている場合は、次のコマンドを入力します。

      RESTORE DATABASE;
RECOVER DATABASE;

      チャネルを手動で割り当てる場合は、RESTOREおよびRECOVERコマンドをRUNブロック内で同時に発行する必要があります。次に例を示します。 

      RUN
{
  ALLOCATE CHANNEL c1 DEVICE TYPE sbt;
  RESTORE DATABASE;
  RECOVER DATABASE;
}

    • 一部のデータファイルを新しい場所にリストアする場合は、RUNコマンドでRESTORE DATABASEとRECOVER DATABASEを順に実行します。SET NEWNAMEコマンドを使用して、データファイルの名前を変更します。

      次の例では、データベースをリストアし、3つのデータファイルに新しい名前を指定してから、データベースをリカバリします。

      RUN
{  
  SET NEWNAME FOR DATAFILE 2 TO '/disk2/df2.dbf';
  SET NEWNAME FOR DATAFILE 3 TO '/disk2/df3.dbf';
  SET NEWNAME FOR DATAFILE 4 TO '/disk2/df4.dbf';
  RESTORE DATABASE;
  SWITCH DATAFILE ALL;
  RECOVER DATABASE;
}

  6. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、データベースをオープンします。

    たとえば、次のコマンドを入力します。

    ALTER DATABASE OPEN;

関連項目:

「デフォルト以外の場所へのデータファイルのリストアについて」

17.4.2 rootの完全リカバリの実行

rootのみに影響するデータ破損またはユーザー・エラーが発生した場合、rootのみのリカバリを検討する場合があります。ただし、rootとPDBの間でメタデータが一貫性が失われるのを防ぐために、rootをリカバリした後にすべてのPDBをリカバリすることを強くお薦めします。この場合、CDB全体の完全リカバリを実行することが望ましい場合があります。

関連項目:

リカバリ手順で使用されるいくつかの前提の「この章の概要」

rootをリカバリする手順

  1. RMANを開始し、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。

    関連項目:

    「CDBへのRMAN接続の確立」

  2. CDBをマウント・モードにします。

    SHUTDOWN IMMEDIATE
STARTUP MOUNT

  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。

  4. 次のコマンドでrootをリストアし、リカバリします。

    RESTORE DATABASE ROOT;
RECOVER DATABASE ROOT;

  5. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次の手順に進みます。

  6. CDBシードを含む、すべてのPDBをリカバリします(強く推奨)。

    1. RESTORE PLUGGABLE DATABASEおよびRECOVER PLUGGABLE DATABASEコマンドを発行します。

      次の例では、PDB salesおよびhrをリカバリします。 

      RESTORE PLUGGABLE DATABASE 'PDB$SEED', sales, hr;
RECOVER PLUGGABLE DATABASE 'PDB$SEED', sales, hr;

    2. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次の手順に進みます。

  7. CDBおよびすべてのPDBを開きます。

    ALTER DATABASE OPEN;
ALTER PLUGGABLE DATABASE ALL OPEN;

関連項目:

17.4.3 RMANによるPDBの完全リカバリの実行

他の開いているPDBの操作に影響を与えずに、1つ以上のPDBの完全リカバリを実行できます。

関連項目:

リカバリ手順で使用されるいくつかの前提の「この章の概要」

RMANを使用してPDBをリカバリするには、次の2つの方法があります。

  • rootに接続し、RESTORE PLUGGABLE DATABASEおよびRECOVER PLUGGABLE DATABASEコマンドを使用します。この方法では、1つのコマンドで複数のPDBをリカバリできます。

  • PDBに接続し、RESTORE DATABASEおよびRECOVER DATABASEコマンドを使用します。この方法では、単一のPDBのみがリカバリされ、CDB以外のデータベースのリカバリの場合と同じコマンドを使用できます。

ビデオ:

プラガブル・データベースのリカバリ

rootへの接続中に1つ以上のPDBをリカバリする手順

  1. RMANを開始し、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。

    関連項目:

    「CDBへのRMAN接続の確立」

  2. リカバリするPDBを閉じます。

    ALTER PLUGGABLE DATABASE sales, hr CLOSE;

    データファイルが欠落している場合は、エラーが発生し、PDBを閉じることができません。欠落したデータファイルが属するPDBに接続してその欠落したデータファイルをオフラインにしてから、PDBを閉じる必要があります。

    次のコマンドでデータファイル12をオフラインにします。

    ALTER PLUGGABLE DATABASE DATAFILE 12 OFFLINE;

    注意:

    PDBのSYSTEM表領域を格納するデータファイルが欠落している場合、「RMANによるPDBの表領域またはデータファイルの完全リカバリの実行」で説明されているリカバリ手順に従います。

  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。

  4. RESTORE PLUGGABLE DATABASEおよびRECOVER PLUGGABLE DATABASEコマンドを発行します。

    次の例では、CDBシードPDB$SEEDとPDBのsalesとhrをリカバリします。 

    RESTORE PLUGGABLE DATABASE 'pdb$seed', sales, hr;
RECOVER PLUGGABLE DATABASE 'pdb$seed', sales, hr;

  5. 手順2でオフラインにされたデータファイルがある場合は、それらのデータファイルをオンラインにします。

    欠落したデータファイルが属するPDBに接続して、そのデータファイルをオンラインにします。次のコマンドでデータファイル12をオフラインにします。

    ALTER DATABASE DATAFILE 12 ONLINE;

  6. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、PDBを開きます。

    ALTER PLUGGABLE DATABASE sales, hr OPEN;

1つのPDBに接続してリカバリする手順

  1. RMANを起動し、SYSDBAシステム権限を持つローカル・ユーザーとしてPDBに接続します。
  2. PDBをクローズします。
    ALTER PLUGGABLE DATABASE CLOSE;

    データファイルが欠落している場合は、エラーが発生するため、そのPDBを閉じることができません。欠落したデータファイルをオフラインにしてから、PDBを閉じる必要があります。

    次のコマンドでデータファイル12をオフラインにします。

    ALTER DATABASE DATAFILE 12 OFFLINE;

    注意:

    PDBのSYSTEM表領域を格納するデータファイルが欠落している場合、「RMANによるPDBの表領域またはデータファイルの完全リカバリの実行」で説明されているリカバリ手順に従います。

  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。
  4. RESTORE DATABASEおよびRECOVER DATABASEコマンドを発行します。
    RESTORE DATABASE;
RECOVER DATABASE;
  5. 手順2でオフラインにされたデータファイルがある場合は、それらのデータファイルをオンラインにします。

    次のコマンドでデータファイル12をオフラインにします。

    ALTER DATABASE DATAFILE 12 ONLINE;
  6. PDBをオープンします。
    ALTER PLUGGABLE DATABASE OPEN;

関連項目:

17.4.4 Cloud ControlによるPDBの完全リカバリの実行

Oracle Enterprise Manager Cloud Control (Cloud Control)を使用して、1つ以上のPDBをリカバリするには、次の手順を実行します。

  1. 「データベース・ホーム」ページの「可用性」メニューから「バックアップとリカバリ」を選択し、「リカバリの実行」を選択します。

  2. その前にデータベースにログインしていなければ、「データベース・ログイン」ページが表示されます。「named」または「新規」資格証明を使用してログインし、「ログイン」をクリックします。

    Cloud Controlによって、リカバリの実行ページが表示されます。

  3. 「ユーザー指示のリカバリ」セクションで、「リカバリの有効範囲」ドロップダウン・リストから「プラガブル・データベース」を選択し、「リカバリ」をクリックします。

    「プラガブル・データベースのリカバリの実行」ウィザードが表示され、「プラガブル・データベース」ページが表示されます。

  4. 次の手順を実行して、リカバリするPDBを選択します。

    1. 「追加」をクリックして、使用可能なプラガブル・データベース・ページを表示します。

    2. 表示されたPDBのリストから、「選択」列で、リカバリするPDBをクリックして指定します。オプションで「すべて選択」をクリックして、使用可能なすべてのPDBに対し「選択」オプションをオンにします。「選択解除」をクリックすると、すべてのPDBの選択が解除されます。

    3. 「選択」ボタンをクリックして、プラガブル・データベース・ページに戻ります。

    4. オプションで、削除する各PDBの「選択」列をクリックし、「削除」をクリックすると、表からPDBを削除できます。

  5. PDBをリカバリするページの残りの部分を移動して、ウィザードを完了します。ウィザードの各ページの詳細を表示するには、「ヘルプ」をクリックします。

関連項目:

「Cloud Controlを使用したデータベースのホーム・ページへのアクセス」

17.4.5 RMANによるPDBの表領域またはデータファイルの完全リカバリの実行

異なるPDBの表領域に同じ名前を付けることができるため、1つ以上のPDBの表領域をリカバリするには、曖昧さを排除するため、PDBに直接接続する必要があります。対照的に、データファイル番号とパスはCDB全体で一意であるため、rootまたはPDBのどちらに接続しても、PDBデータファイルをリカバリすることができます。

rootに接続する場合は、単一のコマンドで複数のPDBからデータファイルをリカバリできます。PDBに接続する場合は、そのPDBのデータファイルのみをリカバリできます。

PDBのSYSTEM以外の表領域をリストアおよびリカバリするには、次の手順を実行します。

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します。

  2. RMANを開始し、「RMANによるデータベース接続の確立」の説明に従ってターゲット・データベースに接続します。

  3. データベースがオープンされている場合は、リカバリが必要な表領域をオフラインにします。

    たとえば、次のコマンドを入力してUSERSをオフラインにします。 

    ALTER TABLESPACE users OFFLINE IMMEDIATE;

  4. SHOWコマンドを使用して、事前構成済のチャネルを確認します。

    必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

  5. パスワード保護された暗号化バックアップをリストアする場合は、パスワードを指定します。

    次の例に示すように、SET DECRYPTION IDENTIFIED BYコマンドを使用して、パスワード保護されたバックアップのパスワードを指定します(passwordは実際に入力するパスワードを表します)。 

    SET DECRYPTION IDENTIFIED BY password;

  6. 表領域をリストアおよびリカバリします。次の内の1つを実行します。

    • データファイルを元の場所にリストアする場合は、RMANプロンプトでRESTORE TABLESPACEとRECOVER TABLESPACEコマンドを実行します。

      たとえば、自動チャネルが構成されている場合は、次のコマンドを入力します。

      RMAN> RESTORE TABLESPACE users;
RMAN> RECOVER TABLESPACE users;

    • 一部のデータファイルを新しい場所にリストアする場合は、RUNコマンドでRESTORE TABLESPACEとRECOVER TABLESPACEを実行します。SET NEWNAMEコマンドを使用して、データファイルの名前を変更します。

  7. 出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、リカバリした表領域をオンラインに戻します。

    たとえば、次のコマンドを入力します。

    ALTER TABLESPACE users ONLINE;

PDBのSYSTEM表領域をリストアおよびリカバリするには、次の手順を実行します。

  1. RMANを開始し、「ターゲットとしてのrootへの接続」の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。

  2. CDBを停止し、マウント・モードで再起動します。

    SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

  3. 影響を受けたPDBのSYSTEM表領域を格納するデータファイルをリストアおよびリカバリします。 

    RESTORE DATAFILE 2,3;
RECOVER DATAFILE 2,3;

  4. CDB内のすべてのPDBを開きます。

    ALTER PLUGGABLE DATABASE ALL OPEN READ WRITE;

PDBのSYSTEM以外のデータファイルをリカバリするには、次の手順を実行します。

  1. 次のいずれかを行います:
  2. RESTORE DATAFILEおよびRECOVER DATAFILEコマンドを発行します。
    RESTORE DATAFILE 10, 13;
RECOVER DATAFILE 10, 13;

関連項目:

「デフォルト以外の場所へのデータファイルのリストアについて」

17.4.6 Cloud ControlによるPDBの表領域の完全リカバリの実行

Oracle Enterprise Manager Cloud Control (Cloud Control)によるPDBの表領域の完全リカバリを実行するには、次の手順を完了します。

  1. 「データベース・ホーム」ページの「可用性」メニューから「バックアップとリカバリ」を選択し、「リカバリの実行」を選択します。

  2. その前にデータベースにログインしていなければ、「データベース・ログイン」ページが表示されます。「named」または「新規」資格証明を使用してログインし、「ログイン」をクリックします。

    Cloud Controlによって、リカバリの実行ページが表示されます。

  3. 「ユーザー指示のリカバリ」セクションで、「リカバリの有効範囲」ドロップダウン・リストから「表領域」を選択し、「リカバリ」をクリックします。

  4. 「オブジェクト・レベルのリカバリの実行: Point-in-Time」ページで、「現在の時間へのリカバリ」が選択されていることを確認し、「次へ」をクリックします。

  5. 「オブジェクト・レベルのリカバリの実行: 表領域」ページで、次の手順を完了して、リカバリする表領域を選択します。

    1. 「追加」をクリックして、使用可能な表領域ページを表示します。

      「検索結果」表に使用可能なすべての表領域が表示され、これには各表領域が属するPDBの名前が含まれています。

    2. 「選択」をクリックして、リカバリする表領域を指定します。オプションで「すべて選択」をクリックして、使用可能なすべての表領域に対し「選択」オプションをオンにします。「選択解除」をクリックすると、すべての表領域の選択が解除されます。

    3. 「選択」ボタンをクリックして、「オブジェクト・レベルのリカバリの実行: 表領域」ページに戻ります。

    4. オプションで、削除する各表領域に対し「選択」オプションをオンにして、「削除」をクリックすると、表から表領域を削除できます。

  6. ウィザードの次の手順に進むには「次へ」をクリックします。

  7. PDB表領域をリカバリするためにページの残りの部分を移動して、ウィザードを完了します。ウィザードの各ページの詳細を表示するには、「ヘルプ」をクリックします。

関連項目:

「Cloud Controlを使用したデータベースのホーム・ページへのアクセス」

17.4.7 コピーへの切替え後のCDBの完全リカバリの実行

CDBまたはPDB内にアクセスできないデータファイルのイメージ・コピーがある場合、SWITCHコマンドを使用して制御ファイルをデータファイル・コピーにポイントすることで、失われた変更をリカバリできます。「コピーへの切替え後の完全リカバリの実行」の情報は、次の相違点を除いて、CDBおよびPDBに当てはまります。

関連項目:

リカバリ手順で使用されるいくつかの前提の「この章の概要」

CDB内のデータファイルを切り替えるには、「データファイルのコピーへの切替え」の説明に従って、rootに接続し、CDB以外の場合と同じ手順を使用します。

PDB内のデータファイルを切り替えるには、次の方法のいずれかを使用します。

  • rootに接続し、SWITCH ... PLUGGABLE DATABASEまたはSWITCH DATAFILEコマンドを使用します。この方法では、1つ以上のPDBのデータファイルを切り替えることができます。

  • PDBに接続し、SWITCH DATABASEまたはSWITCH DATAFILEコマンドを使用してそのPDB内のデータファイルを切り替えます。

関連項目:

「CDBへのRMAN接続の確立」

17.5 アプリケーション・コンテナの完全リカバリの実行

RMANでは、RESTOREおよびRECOVERコマンドを使用して、CDB内の他のコンテナに影響を与えずにアプリケーション・コンテナの完全リカバリを実行できます。

注意:

17.5.1 アプリケーション・ルートの完全リカバリの実行

RESTOREおよびRECOVERコマンドを使用して、アプリケーション・ルートの完全リカバリを実行します。

次のいずれかの方法で、アプリケーション・ルートの完全リカバリを実行します。

  • アプリケーション・ルートに接続し、RESTORE DATABASEおよびRECOVER DATABASEコマンドを使用します。

  • CDBのrootに接続し、RESTORE PLUGGABLE DATABASEおよびRECOVER PLUGGABLE DATABASEコマンドを使用します。

CDBのCOMPATIBLEパラメータは、12.2以上に設定する必要があります。
アプリケーション・ルートに接続してリカバリする手順

  1. RMANを起動し、SYSDBAまたはSYSBACKUP権限を持つアプリケーションの共通ユーザーとしてアプリケーション・ルートに接続します。

    アプリケーション・ルートには固有のサービス名があり、PDBに接続するのと同じ方法でアプリケーション・ルートに接続できます。

  2. アプリケーション・ルートのリカバリが必要なアプリケーション・コンテナをクローズします。

    ALTER DATABASE CLOSE;

  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。

  4. 次のコマンドを使用して、アプリケーション・ルートをリストアし、リカバリします。

    RESTORE DATABASE ROOT;
RECOVER DATABASE ROOT;

  5. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次の手順に進みます。

  6. アプリケーション・ルートをオープンします。

    ALTER DATABASE OPEN;

CDBのrootに接続している場合にアプリケーション・ルートをリカバリする手順

  1. RMANを起動し、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてCDBのrootに接続します。
  2. リカバリが必要なアプリケーション・コンテナをクローズします。

    次のコマンドは、hr_appcontというアプリケーション・ルートを持つアプリケーション・コンテナをクローズします。 

    ALTER PLUGGABLE DATABASE hr_appcont CLOSE;
  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。
  4. アプリケーション・ルートをリストアし、リカバリします。

    次のコマンドは、hr_appcontという名前のアプリケーション・ルートをリストアし、リカバリします。

    RESTORE PLUGGABLE DATABASE hr_appcont;
RECOVER PLUGGABLE DATABASE hr_appcont;
  5. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次の手順に進みます。
  6. アプリケーション・ルートをオープンします。
    ALTER PLUGGABLE DATABASE hr_appcont OPEN;

関連項目:

CDBへのRMAN接続の確立

17.5.2 アプリケーション・ルートおよびアプリケーションPDBの完全リカバリの実行

アプリケーション・ルートおよびそのアプリケーションPDBすべてを含むアプリケーション・コンテナの完全リカバリを、CDB内の他のPDBに影響を与えずに実行できます。

CDBのCOMPATIBLEパラメータは、12.2以上に設定する必要があります。

アプリケーション・ルートとそのアプリケーションPDBすべての完全リカバリを実行する手順

  1. RMANを起動し、SYSDBAまたはSYSBACKUP権限を持つアプリケーションの共通ユーザーとしてアプリケーション・ルートに接続します。
    アプリケーション・ルートには固有のサービス名があり、PDBに接続するのと同じ方法でアプリケーション・ルートに接続できます。
  2. リカバリが必要なアプリケーション・コンテナをクローズします。
    ALTER DATABASE CLOSE;
  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。
  4. 次のコマンドを使用して、アプリケーション・コンテナ(アプリケーション・ルートおよびすべてのアプリケーションPDB)をリストアし、リカバリします。
    RESTORE DATABASE;
RECOVER DATABASE;
  5. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次の手順に進みます。
  6. アプリケーション・ルートとすべてのアプリケーションPDBをオープンします。
    ALTER DATABASE OPEN;
ALTER PLUGGABLE DATABASE ALL OPEN;

関連項目:

CDBへのRMAN接続の確立

17.5.3 アプリケーションPDBの完全リカバリの実行

RESTOREおよびRECOVERコマンドを使用して、1つ以上のアプリケーションPDBの完全リカバリを実行します。

CDBのCOMPATIBLEパラメータは、12.2以上に設定する必要があります。
アプリケーションPDBの完全リカバリを実行する手順
  1. RMANを起動して、次の接続タイプのいずれかを確立します。

    • SYSDBAまたはSYSBACKUP権限を持つアプリケーションの共通ユーザーとしてアプリケーション・ルートに接続します。

      アプリケーション・ルートには固有のサービス名があり、PDBに接続するのと同じ方法でアプリケーション・ルートに接続できます。

    • SYSDBA権限またはSYSBACKUP権限を持つ共通ユーザーとして、CDBのrootに接続します。

  2. 完全リカバリが必要なアプリケーションPDBをクローズします。

    次のコマンドは、hr_appcont_pdb1というアプリケーションPDBをクローズします。 

    ALTER PLUGGABLE DATABASE hr_appcont_pdb1 CLOSE;
  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。
  4. アプリケーションPDBをリストアし、リカバリします。

    次のコマンドは、hr_appcont_pdb1というアプリケーションPDBの完全リカバリを実行します。

    RESTORE PLUGGABLE DATABASE hr_appcont_pdb1;
RECOVER PLUGGABLE DATABASE hr_appcont_pdb1;
  5. 出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次の手順に進みます。
  6. アプリケーションPDBをオープンします。

    次のコマンドは、hr_appcont_pdb1というアプリケーションPDBをオープンします。 

    ALTER PLUGGABLE DATABASE hr_appcont_pdb1 OPEN;

関連項目:

CDBへのRMAN接続の確立

17.6 RMANを使用したスパース・データベースの完全リカバリの実行

この項では、次の項目について説明します。

注意:

スパース・データベースのベース(読取り専用)データファイルは、暗号化されていません。基本データファイルは、保護されたストレージに保存し、安全な通信を使用してアクセスするようにします。

17.6.1 スパース・データベースの完全リカバリの実行

スパース・データファイルが含まれるデータベースのリカバリの実行は、データベース全体のリカバリの実行と非常に似ています。

RMANは、最初に、データベースのデルタ記憶領域からバックアップされた論理データをリストアし、次に、REDOログから読取り論理データファイル・ブロックを適用してデータベースをリカバリします。スパース・データベース、表領域またはデータファイルの完全リカバリまたはPoint-in-Timeリカバリを実行できます。

スパース・データベースをリカバリする手順

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します。
  2. RMANを開始し、「RMANによるデータベース接続の確立」の説明に従ってターゲット・データベースに接続します。
  3. データベースがマウントされていない場合は、データベースをマウントします。ただし、オープンはしません。

    たとえば、次のコマンドを入力します。

    STARTUP MOUNT;
  4. SHOWコマンドを使用して、事前構成済のチャネルを確認します。

    必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

  5. スパース・データベースをリストアおよびリカバリします。次のコマンドは、スパース・データベースの完全リカバリを実行します。
    RESTORE FROM SPARSE DATABASE;
RECOVER DATABASE;
  6. スパース・データファイルが含まれる特定の表領域をリカバリするには、その表領域に対してRESTOREおよびRECOVERコマンドを使用します。
    次の例では、MY_TBSという表領域をリストアおよびリカバリします。
    RESTORE FROM SPARSE TABLESPACE MY_TBS;
RECOVER TABLESPACE MY_TBS;

17.6.2 スパースCDBの完全リカバリの実行

スパースCDBのリカバリの実行は、スパース・データベースの完全リカバリの実行と非常に似ています。

スパースCDBをリカバリする手順

  1. 「データベースの完全リカバリの準備」の説明に従って、シナリオに必要な準備ステップを完了します。
  2. RMANを開始し、「RMANによるデータベース接続の確立」の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。
  3. CDBがマウントされていない場合は、CDBをマウントします。ただし、オープンはしません。

    たとえば、次のコマンドを入力します。

    STARTUP MOUNT;
  4. SHOWコマンドを使用して、事前構成済のチャネルを確認します。

    必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。

  5. スパースCDBをリストアおよびリカバリします。次のコマンドは、スパースCDBの完全リカバリを実行します。
    RESTORE FROM SPARSE DATABASE;
RECOVER DATABASE;
  6. スパース・データファイルが含まれる特定の表領域をリカバリするには、その表領域に対してRESTOREおよびRECOVERコマンドを使用します。
    次の例では、MY_TBSという表領域をリストアおよびリカバリします。
    RESTORE FROM SPARSE TABLESPACE MY_TBS;
RECOVER TABLESPACE MY_TBS;

17.6.3 RMANを使用したスパースPDBのリカバリの実行

スパースPDBのリカバリ手順は、標準のPDBをリカバリするために実行する手順に似ています。rootレベルまたはCDBレベルで接続中にスパースPDBをリカバリできます。リカバリ操作を行うための手順を次に示します。

rootへの接続中に1つ以上のスパースPDBをリカバリする手順

  1. RMANを開始し、「CDBへのRMAN接続の確立」の説明に従って、SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。

  2. リカバリするPDBを閉じます。

     ALTER PLUGGABLE DATABASE sales, hr CLOSE;

    データファイルが欠落している場合は、エラーが発生し、PDBを閉じることができません。欠落したデータファイルが属するPDBに接続してその欠落したデータファイルをオフラインにしてから、PDBを閉じる必要があります。

    次のコマンドでデータファイル12をオフラインにします。

    ALTER PLUGGABLE DATABASE DATAFILE 12 OFFLINE;

    注意:

    PDBのSYSTEM表領域を格納するデータファイルが欠落している場合、「RMANによるPDBの表領域またはデータファイルの完全リカバリの実行」で説明されているリカバリ手順に従います。

  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。

  4. RESTOREおよびRECOVERコマンドをプラガブル・データベースに対して実行します。

    次の例では、rootに接続しているときに、HR_PDBというPDBの完全リカバリを実行します。
    RESTORE FROM SPARSE PLUGGABLE DATABASE HR_PDB;
RECOVER PLUGGABLE DATABASE HR_PDB;

1つのスパースPDBに接続してリカバリする手順

  1. RMANを開始し、「CDBへのRMAN接続の確立」の説明に従って、SYSDBAまたはSYSBACKUPシステム権限を持つローカル・ユーザーとしてPDBに接続します。
  2. PDBをクローズします。
    ALTER PLUGGABLE DATABASE CLOSE;

    データファイルが欠落している場合は、エラーが発生するため、そのPDBを閉じることができません。欠落したデータファイルをオフラインにしてから、PDBを閉じる必要があります。

    次のコマンドでデータファイル12をオフラインにします。

    ALTER DATABASE DATAFILE 12 OFFLINE;

    注意:

    PDBのSYSTEM表領域を格納するデータファイルが欠落している場合、「RMANによるPDBの表領域またはデータファイルの完全リカバリの実行」で説明されているリカバリ手順に従います。

  3. (オプション) CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。
  4. RESTOREおよびRECOVERコマンドを発行します。
    次の例では、USERS_PDBというPDBをリストアおよびリカバリします。
    RESTORE FROM SPARSE DATABASE FROM USERS_PDB;
RECOVER DATABASE USERS_PDB;