17 データベースの完全リカバリの実行
この章では、1つ以上のデータファイルが消失した後、RMANを使用してデータベースを通常の稼働状態に戻す方法について説明します。この章のトピックは、次のとおりです:
17.1 データベースの完全リカバリの概要
完全リカバリでは、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クライアントを使用しています。
関連項目:
-
すべてのデータベースの変更ではなく、一部の変更をリカバリする詳細については、「フラッシュバックおよびデータベースのPoint-in-Timeリカバリの実行」を参照してください
-
すべての制御ファイルを消失したときにデータベースをリカバリする詳細については、「バックアップ制御ファイルを使用したリカバリの実行」を参照してください
-
バックアップ・サーバー・パラメータ・ファイルのリストアの詳細は、「サーバー・パラメータ・ファイルのリストア」を参照してください
17.1.3 リカバリ・アプライアンスのリアルタイムREDOトランスポートについて
Zero Data Loss Recovery Appliance (リカバリ・アプライアンス)では、連続するアーカイブREDOログ・バックアップ間に存在する潜在的なデータ損失の期間が大幅に削減されます。データベース障害から1秒に満たない時点にターゲット・データベースをリカバリします。
リアルタイムREDOトランスポートがターゲット・データベースに対して構成されている場合、現在のREDOログ・グループのREDOデータが生成時にリカバリ・アプライアンスに非同期に書き込まれます。REDOストリームが受信されると、REDOストリームは完全なRMANのアーカイブREDOログとして格納されます。ターゲット・データベースがクラッシュすると、クラッシュ時点までに現在のREDOログ・グループから受信したREDOデータがリストアおよびリカバリ操作時に使用されます。
ターゲット・データベースに対するリアルタイムREDOトランスポートを有効にするには、特定の構成ステップを実行する必要があります。
ノート:
リアルタイムREDOトランスポートは、リカバリ・アプライアンスでのみ使用できます。
関連項目:
リアルタイムREDOトランスポートの構成ステップは、Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイドを参照してください
17.2 データベースの完全リカバリの準備
リカバリ目標および失われたデータベース・ファイルに基づいて、データベースのリストアおよびリカバリ計画を計画する必要があります。
この項では、次の項目について説明します。
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 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
VALIDATE DATABASEコマンドの出力は、データ・ファイル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問合せを使用してより詳細な情報を取得する必要がある場合があります。
データファイルにメディア・リカバリが必要かどうかを確認するには:
関連項目:
-
Oracle Databaseリファレンスの
V$DATAFILE_HEADER -
Oracle Databaseリファレンスの
V$RECOVER_FILE -
Oracle Databaseリファレンスの
V$DATAFILE -
Oracle Databaseリファレンスの
V$TABLESPACE
17.2.2 データベースのDBIDの確認
データベースの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に指示する必要がある状況を識別します。
リストア操作で使用されるバックアップをプレビューするには:
関連項目:
RESTORE ... PREVIEWの出力(LISTコマンドの出力と同じ書式)の解釈の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください
17.2.3.1 オフサイト・バックアップのリコール
オフサイト・バックアップは、安全なストレージ設備などのリモートの場所に格納され、メディア・マネージャがメディアを取り込まないかぎりリストアできません。
一部のメディア・マネージャは、オフサイトにあるバックアップに関するステータス情報をRMANに提供します。バックアップをリストアする前にストレージからメディアを取り込む必要がある場合でも、オフサイト・バックアップは、RMANリポジトリでAVAILABLEとマークが付けられます。RMANがオフサイト・バックアップのリストアを試みると、リストア・ジョブに失敗します。
オフサイト・バックアップをリコールするには:
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ログのリストア
RMANでは、リストアされたアーカイブREDOログ・ファイルのデフォルトの場所を上書きできます。
SET ARCHIVELOG DESTINATIONコマンドによって、アーカイブ・ログは、データベースのリストア操作中に別の場所に手動でステージングされます。リカバリ中、RMANは新しくリストアされたアーカイブ・ログを検索する場所を認識するため、初期化パラメータ・ファイルで指定された場所にアーカイブ・ログが存在している必要はありません。
アーカイブREDOログを新しい場所へリストアするには:
-
RMANを開始し、RMANによるデータベース接続の確立の説明に従ってターゲット・データベースに接続します。
-
データベースがマウントまたはオープンされていることを確認します。
-
RUNコマンド内で、次の操作を実行します。-
SETARCHIVELOGDESTINATIONを使用して、リストアするアーカイブREDOログの新しい場所を指定します。 -
アーカイブ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;SYSBACKUP権限があるユーザーがリカバリを実行しており、パスワード保護されたキーストアが使用されている場合は、このユーザーにSYSKM権限を付与します。 -
パスワードモード暗号化を使用して作成されたバックアップの場合、リストアする前に正しいパスワードを入力する必要があります。
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コマンド内で使用して、新しいファイル名を指定します。その後、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エラーまたは他の原因でファイルを再作成できない場合、エラーがアラート・ログにレポートされ、データベースのオープン操作が続行されます。
関連項目:
リカバリ手順で使用されるいくつかの前提のこの章の概要
データベース全体をリストアおよびリカバリするには:
17.3.3 表領域の完全リカバリの実行
TABLESPACEオプションとともにRESTOREおよびRECOVERコマンドを使用して、表領域の完全リカバリを実行します
リカバリ手順で使用されるいくつかの前提の「この章の概要」
基本的な例では、データベースはオープンされており、データファイルのすべてではなく一部が破損しています。データベースの残りの部分を使用可能にしておくために、データベースはオープンしたままで、破損した表領域をリストアおよびリカバリします。この例では、データベースTRGTの表領域USERSが消失したと想定しています。
表領域をリストアおよびリカバリするには:
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つ以上のデータファイルが破損している場合は、破損したデータファイルの既存のイメージ・コピーに切り替えてリカバリを実行できます。
リカバリ手順で使用されるいくつかの前提のこの章の概要
基本的な例では、データベースはオープンされており、データファイルのすべてではなく一部が破損しています。1日の中で、あるデータファイルがストレージ障害によって欠落します。このファイルを修復する必要がありますが、バックアップからリストアおよびリカバリする時間はありません。最新のイメージ・コピー・バックアップを新しいファイルとして使用して、リストア時間をなくします。この例では、データベースtrgtのデータファイル4が消失したと想定しています。
データファイルのコピーに切り替えてリカバリを実行するには:
17.3.4.2 データベース・コピーへの切替え後の完全リカバリの実行
これらのデータファイルをリストアするかわりに破損したデータファイルのイメージ・コピーに切り替えて、データベースの完全リカバリを実行できます。
リカバリ手順で使用されるいくつかの前提のこの章の概要
この例では、データベースは停止しており、すべてのデータファイルが破損しています。すべての破損したデータファイルのイメージ・コピーを保有し、新しいデータファイルとして既存のイメージ・コピーを使用するため、リストア時間がなくなります。
データベースのコピーに切り替えてリカバリを実行するには:
17.4 CDBの完全リカバリの実行
RMANおよびOracle Enterprise Manager Cloud Control (Cloud Control)によって、マルチテナント環境でのバックアップとリカバリが完全にサポートされます。
マルチテナント・コンテナ・データベース(CDB)全体、rootのみ、または1つ以上のプラガブル・データベース(PDB)をバックアップおよびリカバリできます。
この項の内容は次のとおりです。
17.4.1 CDB全体の完全リカバリの実行
CDB全体をリカバリする場合は、rootとすべてのPDBを1つの操作でリカバリします。
CDB全体をリカバリするには:
-
データベースの完全リカバリの準備の説明に従って、シナリオに必要な準備ステップを完了します
-
ターゲットとしてのrootへの接続の説明に従って、
SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootおよびリカバリ・カタログ(使用している場合)に接続します。 -
データベースがマウントされていない場合は、データベースをマウントします。ただし、オープンはしません。次のgコマンドを使用します。
STARTUP MOUNT;
-
SHOWコマンドを使用して、事前構成済のチャネルを確認します。必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、
CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。 -
データベースをリストアおよびリカバリします。次の内の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; }
-
-
出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、データベースをオープンします。
たとえば、次のコマンドを入力します。
ALTER DATABASE OPEN;
17.4.2 rootの完全リカバリの実行
rootのみに影響するデータ破損またはユーザー・エラーが発生した場合、rootのみのリカバリを検討する場合があります。
ただし、rootとPDBの間でメタデータが一貫性が失われるのを防ぐために、rootをリカバリした後にすべてのPDBをリカバリすることを強くお薦めします。この場合、CDB全体の完全リカバリを実行することが望ましい場合があります。
関連項目:
リカバリ手順で使用されるいくつかの前提のこの章の概要
rootをリカバリするには:
-
データベースの完全リカバリの準備の説明に従って、リカバリ・シナリオに必要な準備ステップを完了します。
-
RMANを開始し、ターゲットとしてのrootへの接続の説明に従って、
SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。 -
CDBをマウント・モードにします。
SHUTDOWN IMMEDIATE; STARTUP MOUNT;
-
(オプション)
CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。 -
次のコマンドでrootをリストアし、リカバリします。
RESTORE DATABASE ROOT; RECOVER DATABASE ROOT;
-
出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次のステップに進みます。
-
CDBシードを含む、すべてのPDBをリカバリします(強く推奨)。
-
RESTORE PLUGGABLE DATABASEおよびRECOVER PLUGGABLE DATABASEコマンドを発行します。次の例では、PDB
salesおよびhrをリカバリします。RESTORE PLUGGABLE DATABASE 'PDB$SEED', sales, hr; RECOVER PLUGGABLE DATABASE 'PDB$SEED', sales, hr;
-
出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次のステップに進みます。
-
-
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をリカバリするには:
-
データベースの完全リカバリの準備の説明に従って、リカバリ・シナリオに必要な準備ステップを完了します。
-
RMANを開始し、ターゲットとしてのrootへの接続の説明に従って、
SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。 -
リカバリするPDBを閉じます。
ALTER PLUGGABLE DATABASE sales, hr CLOSE;
データファイルが欠落している場合は、エラーが発生し、PDBを閉じることができません。欠落したデータファイルが属するPDBに接続してその欠落したデータファイルをオフラインにしてから、PDBを閉じる必要があります。
次のコマンドでデータファイル12をオフラインにします。
ALTER PLUGGABLE DATABASE DATAFILE 12 OFFLINE;
ノート:
PDBの
SYSTEM表領域を格納するデータファイルが欠落している場合、RMANによるPDBの表領域またはデータファイルの完全リカバリの実行で説明されているリカバリ・ステップに従います。 -
(オプション)
CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。 -
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;
-
ステップ2でオフラインにされたデータファイルがある場合は、それらのデータファイルをオンラインにします。
欠落したデータファイルが属するPDBに接続して、そのデータファイルをオンラインにします。次のコマンドでデータファイル12をオフラインにします。
ALTER DATABASE DATAFILE 12 ONLINE;
-
出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、PDBを開きます。
ALTER PLUGGABLE DATABASE sales, hr OPEN;
1つのPDBに接続してリカバリするには:
17.4.4 Cloud ControlによるPDBの完全リカバリの実行
Enterprise Manager Cloud Control (Cloud Control)は、PDBをリカバリするためのインタフェースを提供します。
Cloud Controlを使用して1つ以上のPDBをリカバリするには:
-
「データベース・ホーム」ページの「可用性」メニューから「バックアップとリカバリ」を選択し、「リカバリの実行」を選択します。
-
その前にデータベースにログインしていなければ、「データベース・ログイン」ページが表示されます。「named」または「新規」資格証明を使用してログインし、「ログイン」をクリックします。
Cloud Controlによって、リカバリの実行ページが表示されます。
-
「ユーザー指示のリカバリ」セクションで、「リカバリの有効範囲」ドロップダウン・リストから「プラガブル・データベース」を選択し、「リカバリ」をクリックします。
「プラガブル・データベースのリカバリの実行」ウィザードが表示され、「プラガブル・データベース」ページが表示されます。
-
次のステップを実行して、リカバリするPDBを選択します。
-
「追加」をクリックして、使用可能なプラガブル・データベース・ページを表示します。
-
表示されたPDBのリストから、「選択」列で、リカバリするPDBをクリックして指定します。オプションで「すべて選択」をクリックして、使用可能なすべてのPDBに対し「選択」オプションをオンにします。「選択解除」をクリックすると、すべてのPDBの選択が解除されます。
-
「選択」ボタンをクリックして、プラガブル・データベース・ページに戻ります。
-
オプションで、削除する各PDBの「選択」列をクリックし、「削除」をクリックすると、表からPDBを削除できます。
-
-
PDBをリカバリするページの残りの部分を移動して、ウィザードを完了します。ウィザードの各ページの詳細を表示するには、「ヘルプ」をクリックします。
17.4.5 プリプラグイン・バックアップを使用した完全リカバリの実行
RECOVERコマンドを使用して、プリプラグイン・バックアップを使用した完全リカバリを実行します。
この項では、次の項目について説明します。
17.4.5.1 プリプラグイン・バックアップを使用したPDBの完全リカバリについて
プリプラグイン・バックアップは、PDBが現在のCDBに組み込まれる前の過去の時点での状態にPDBをリストアおよびリカバリするために使用されます。
プリプラグイン・バックアップを使用した完全リカバリを実行するには、RESTOREおよびRECOVERコマンドのFROM PREPLUGIN句を使用します。RMANは、プリプラグイン・バックアップを使用してデータファイルをリストアしてから、プリプラグイン増分バックアップおよびアーカイブREDOログを使用して、PDBが宛先CDBに組み込まれる前の時点にデータファイルをリカバリします。
プリプラグイン・バックアップのメタデータは、PDBを切断するか、非CDBでDBMS_PDB.EXPORTRMANBACKUP()プロシージャを使用すると、宛先CDBに移行されます。プリプラグイン・バックアップは宛先CDBに自動的に移行されません。宛先CDBが、ソース・データベースで作成されたバックアップにアクセスできることを確認する必要があります。
RMANがプリプラグイン・アーカイブREDOログをリストアする場所は、高速リカバリ領域が宛先CDBで構成されているかどうかによって異なります。高速リカバリ領域が、CDBのアーカイブREDOログ・ファイルのデフォルトの宛先でない場合は、RMANによって、プリプラグイン・アーカイブREDOログが高速リカバリ領域にリストアされます。高速リカバリ領域が、CDBのアーカイブREDOログ・ファイルのデフォルトの宛先である場合は、SET ARCHIVELOG DESTINATIONコマンドを使用して、プリプラグイン・アーカイブREDOログ・ファイルの場所を指定する必要があります。
17.4.5.2 プリプラグイン・バックアップを使用したPDBの完全リカバリの実行
RMANは、プリプラグイン・バックアップを使用してPDBの完全リカバリを実行します。これらのプリプラグイン・バックアップは、PDBが現在のターゲットCDBに移行される前にソース非CDBまたはソースCDBで作成されました。
ノート:
PDBがRESETLOGSオプションでオープンされる前にプリプラグイン・バックアップが作成された場合は、プリプラグイン・バックアップを使用してPDBをリカバリすることはできません。
プリプラグイン・バックアップを使用したPDBの完全リカバリを実行するには:
17.4.5.3 例: プリプラグイン・バックアップを使用したPDBの完全リカバリの実行
この例では、プリプラグイン・バックアップを使用して、宛先CDB prod_cdbでPDB my_pdbの完全リカバリを実行します。
PDB my_pdbは、CDB test_cdbから切断されてから、CDB prod_cdbに組み込まれました。このPDBがtest_cdbから切断されたときに、そのメタデータがファイルmypdb.xmlに保存されました。このメタデータは、my_pdbをprod_cdbに組み込むために使用されました。ソースCDB test_cdbで作成されたmy_pdbのバックアップは、共有場所/oracle/database/backupsに格納されます。CDB prod_cdbは、アーカイブREDOログ・ファイルを格納するために高速リカバリ領域を使用します。
17.4.6 RMANによるPDBの表領域またはデータファイルの完全リカバリの実行
異なるPDBの表領域に同じ名前を付けることができるため、1つ以上のPDBの表領域をリカバリするには、曖昧さを排除するため、PDBに直接接続する必要があります。対照的に、データファイル番号とパスはCDB全体で一意であるため、rootまたはPDBのどちらに接続しても、PDBデータファイルをリカバリできます。
rootに接続する場合は、単一のコマンドで複数のPDBからデータファイルをリカバリできます。PDBに接続する場合は、そのPDBのデータファイルのみをリカバリできます。
PDBのSYSTEM以外の表領域をリストアおよびリカバリするには:
-
データベースの完全リカバリの準備の説明に従って、リカバリ・シナリオに必要な準備ステップを完了します。
-
RMANを開始し、RMANによるデータベース接続の確立の説明に従ってターゲット・データベースに接続します。
-
データベースがオープンされている場合は、リカバリが必要な表領域をオフラインにします。
たとえば、次のコマンドを入力して
USERSをオフラインにします。ALTER TABLESPACE users OFFLINE IMMEDIATE; -
SHOWコマンドを使用して、事前構成済のチャネルを確認します。必要なデバイスおよびチャネルが構成されている場合、操作は必要ありません。そうでない場合は、
CONFIGUREコマンドを使用して自動チャネルを構成するか、またはRUNブロック内にALLOCATE CHANNELコマンドを含めます。 -
表領域をリストアおよびリカバリします。次の内の1つを実行します。
-
データファイルを元の場所にリストアする場合は、RMANプロンプトで
RESTORE TABLESPACEとRECOVER TABLESPACEコマンドを実行します。たとえば、自動チャネルが構成されている場合は、次のコマンドを入力します。
RMAN> RESTORE TABLESPACE users; RMAN> RECOVER TABLESPACE users; -
一部のデータファイルを新しい場所にリストアする場合は、
RUNコマンドでRESTORE TABLESPACEとRECOVER TABLESPACEを実行します。SET NEWNAMEコマンドを使用して、データファイルの名前を変更します。
-
-
出力を調べて、リカバリが正常に実行されたことを確認します。正常に実行された場合は、リカバリした表領域をオンラインに戻します。
たとえば、次のコマンドを入力します。
ALTER TABLESPACE users ONLINE;
PDBのSYSTEM表領域をリストアおよびリカバリするには:
-
データベースの完全リカバリの準備の説明に従って、リカバリ・シナリオに必要な準備ステップを完了します。
-
RMANを開始し、ターゲットとしてのrootへの接続の説明に従って、
SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。 -
CDBを停止し、マウント・モードで再起動します。
SHUTDOWN IMMEDIATE; STARTUP MOUNT; -
影響を受けたPDBの
SYSTEM表領域を格納するデータファイルをリストアおよびリカバリします。RESTORE DATAFILE 2,3; RECOVER DATAFILE 2,3; -
CDB内のすべてのPDBを開きます。
ALTER PLUGGABLE DATABASE ALL OPEN READ WRITE;
PDBのSYSTEM以外のデータファイルをリカバリするには:
17.4.7 Cloud ControlによるPDBの表領域の完全リカバリの実行
Oracle Enterprise Manager Cloud Control (Cloud Control)は、PDB内の表領域をリカバリするためのインタフェースを提供します。
Cloud Controlを使用してPDBの表領域の完全リカバリを実行するには:
-
「データベース・ホーム」ページの「可用性」メニューから「バックアップとリカバリ」を選択し、「リカバリの実行」を選択します。
-
その前にデータベースにログインしていなければ、「データベース・ログイン」ページが表示されます。「named」または「新規」資格証明を使用してログインし、「ログイン」をクリックします。
Cloud Controlによって、リカバリの実行ページが表示されます。
-
「ユーザー指示のリカバリ」セクションで、「リカバリの有効範囲」ドロップダウン・リストから「表領域」を選択し、「リカバリ」をクリックします。
-
「オブジェクト・レベルのリカバリの実行: Point-in-Time」ページで、「現在の時間へのリカバリ」が選択されていることを確認し、「次へ」をクリックします。
-
「オブジェクト・レベルのリカバリの実行: 表領域」ページで、次のステップを完了して、リカバリする表領域を選択します。
-
「追加」をクリックして、使用可能な表領域ページを表示します。
「検索結果」表に使用可能なすべての表領域が表示され、これには各表領域が属するPDBの名前が含まれています。
-
「選択」をクリックして、リカバリする表領域を指定します。オプションで「すべて選択」をクリックして、使用可能なすべての表領域に対し「選択」オプションをオンにします。「選択解除」をクリックすると、すべての表領域の選択が解除されます。
-
「選択」ボタンをクリックして、「オブジェクト・レベルのリカバリの実行: 表領域」ページに戻ります。
-
オプションで、削除する各表領域に対し「選択」オプションをオンにして、「削除」をクリックすると、表から表領域を削除できます。
-
-
ウィザードの次のステップに進むには「次へ」をクリックします。
-
PDB表領域をリカバリするためにページの残りの部分を移動して、ウィザードを完了します。ウィザードの各ページの詳細を表示するには、「ヘルプ」をクリックします。
17.4.8 コピーへの切替え後のCDBの完全リカバリの実行
コピーへの切替えによるCDBのリカバリは、従来のリストアおよびリカバリよりも高速です。
CDBまたはPDB内にアクセスできないデータファイルのイメージ・コピーがある場合、SWITCHコマンドを使用して制御ファイルをデータファイル・コピーにポイントすることで、失われた変更をリカバリできます。
関連項目:
リカバリ手順で使用されるいくつかの前提のこの章の概要
CDB内のデータファイルを切り替えるには:
-
ルートに接続し、データファイル・コピーへの切替え後のリカバリの実行の説明に従って、非CDBに使用するのと同じステップを使用します。
PDB内のデータファイルを切り替えるには、次の方法のいずれかを使用します。
-
rootに接続し、
SWITCH ... PLUGGABLE DATABASEまたはSWITCH DATAFILEコマンドを使用します。この方法では、1つ以上のPDBのデータファイルを切り替えることができます。 -
PDBに接続し、
SWITCH DATABASEまたはSWITCH DATAFILEコマンドを使用してそのPDB内のデータファイルを切り替えます。
関連項目:
17.5 アプリケーション・コンテナの完全リカバリの実行
RMANでは、RESTOREおよびRECOVERコマンドを使用して、CDB内の他のコンテナに影響を与えずにアプリケーション・コンテナの完全リカバリを実行できます。
17.5.1 アプリケーション・ルートの完全リカバリの実行
RESTOREおよびRECOVERコマンドを使用して、アプリケーション・ルートの完全リカバリを実行します。
次のいずれかの方法で、アプリケーション・ルートの完全リカバリを実行します。
-
アプリケーション・ルートに接続し、
RESTORE DATABASEおよびRECOVER DATABASEコマンドを使用します。 -
CDBのrootに接続し、
RESTORE PLUGGABLE DATABASEおよびRECOVER PLUGGABLE DATABASEコマンドを使用します。
COMPATIBLEパラメータは、12.2以上に設定する必要があります。
-
RMANを起動し、
SYSDBAまたはSYSBACKUP権限を持つアプリケーションの共通ユーザーとしてアプリケーション・ルートに接続します。アプリケーション・ルートには固有のサービス名があり、PDBに接続するのと同じ方法でアプリケーション・ルートに接続できます。
-
アプリケーション・ルートのリカバリが必要なアプリケーション・コンテナをクローズします。
ALTER DATABASE CLOSE; -
(オプション)
CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。 -
次のコマンドを使用して、アプリケーション・ルートをリストアし、リカバリします。
RESTORE DATABASE ROOT; RECOVER DATABASE ROOT; -
出力を調べて、メディア・リカバリが正常に実行されたかどうかを確認します。正常に実行された場合は、次のステップに進みます。
-
アプリケーション・ルートをオープンします。
ALTER DATABASE OPEN;
CDBのrootに接続している場合にアプリケーション・ルートをリカバリする手順
関連項目:
17.5.2 アプリケーション・ルートおよびアプリケーションPDBの完全リカバリの実行
アプリケーション・ルートおよびそのアプリケーションPDBすべてを含むアプリケーション・コンテナの完全リカバリを、CDB内の他のPDBに影響を与えずに実行できます。
COMPATIBLEパラメータは、12.2以上に設定する必要があります。
アプリケーション・ルートとそのアプリケーションPDBすべての完全リカバリを実行するには:
関連項目:
17.6 RMANを使用したスパース・データベースの完全リカバリの実行
RESTOREおよびRECOVERコマンドを使用して、スパース・データベースを直近の時点にリカバリできます。
ノート:
スパース・データベースのベース(読取り専用)データファイルは、暗号化されていません。基本データファイルは、保護されたストレージに保存し、安全な通信を使用してアクセスするようにします。
17.6.1 スパース・データベースの完全リカバリの実行
スパース・データファイルが含まれるデータベースのリカバリの実行は、データベース全体のリカバリの実行と非常に似ています。
スパース・データベースをリカバリするには:
17.6.3 RMANを使用したスパースPDBのリカバリの実行
rootレベルまたはCDBレベルで接続中にスパースPDBをリカバリできます。
rootへの接続中に1つ以上のスパースPDBをリカバリするには:
-
データベースの完全リカバリの準備の説明に従って、リカバリ・シナリオに必要な準備ステップを完了します。
-
RMANを開始し、CDBへのRMAN接続の確立の説明に従って、
SYSDBAまたはSYSBACKUP権限を持つ共通ユーザーとしてrootに接続します。 -
リカバリするPDBを閉じます。
ALTER PLUGGABLE DATABASE sales, hr CLOSE;
データファイルが欠落している場合は、エラーが発生し、PDBを閉じることができません。欠落したデータファイルが属するPDBに接続してその欠落したデータファイルをオフラインにしてから、PDBを閉じる必要があります。
次のコマンドでデータファイル12をオフラインにします。
ALTER PLUGGABLE DATABASE DATAFILE 12 OFFLINE;
ノート:
PDBの
SYSTEM表領域を格納するデータファイルが欠落している場合、RMANによるPDBの表領域またはデータファイルの完全リカバリの実行で説明されているリカバリ・ステップに従います。 -
(オプション)
CONFIGUREコマンドを使用して、デフォルトのデバイス・タイプおよび自動チャネルを構成します。 -
RESTOREおよびRECOVERコマンドをプラガブル・データベースに対して実行します。次の例では、rootに接続しているときに、HR_PDBというPDBの完全リカバリを実行します。RESTORE FROM SPARSE PLUGGABLE DATABASE HR_PDB; RECOVER PLUGGABLE DATABASE HR_PDB;
1つのスパースPDBに接続してリカバリするには: