20 RMANのリカバリの実行: 高度な例
基本的なシナリオよりも一般的ではないか複雑なリカバリ・シナリオを実行する方法について説明します。
20.1 増分バックアップを使用したNOARCHIVELOGモードのデータベースのリカバリ
増分バックアップを適用することによって、制限された変更のリカバリをNOARCHIVELOG
モードで実行されているデータベースに実行できます。NOARCHIVELOG
モードで実行されるデータベースのすべてのバックアップと同様に、増分バックアップは一貫性バックアップである必要があります。そのため、データベースのオープン時にデータベースのバックアップは作成できません。
NOARCHIVELOG
モードで実行されているデータベースのリストアは、ARCHIVELOG
モードのデータベースのリストアと類似しています。主な違いは次のとおりです。
-
NOARCHIVELOG
モードでのデータベースのリストアでは、一貫性バックアップのみを使用できます。 -
アーカイブREDOログが存在しないため、メディア・リカバリは実行できません。
NOARCHIVELOG
データベースをリカバリする場合は、RECOVER
コマンドでNOREDO
オプションを指定し、RMANがアーカイブREDOログの適用を試行しないように指定します。そうしない場合、RMANによってエラーが戻されます。
増分バックアップを使用して NOARCHIVELOG データベースをリカバリする手順
20.2 サーバー・パラメータ・ファイルのリストア
RMANは、失われたサーバー・パラメータ・ファイルをデフォルトの場所または選択した場所にリストアできます。制御ファイルが消失した場合とは異なり、サーバー・パラメータ・ファイルが消失した場合、インスタンスはすぐに停止しません。インスタンスは継続して実行できます。ただし、サーバー・パラメータ・ファイルをリストアした後、インスタンスを停止して再起動する必要があります。
サーバー・パラメータ・ファイルをリストアする場合は、次の考慮事項に注意してください。
-
インスタンスがサーバー・パラメータ・ファイルを使用してすでに起動されている場合、既存のサーバー・パラメータ・ファイルを上書きすることはできません。
-
リストア・コマンドで
TO
句を使用せずにクライアント側の初期化パラメータ・ファイルを使用してインスタンスを起動すると、RMANによってサーバー・パラメータ・ファイルがデフォルトの場所にリストアされます。デフォルトの場所はプラットフォーム固有です。たとえば、Linuxでは?
/dbs/spfile.ora
です。 -
リカバリ・カタログを使用すると、DBIDの記録および記憶を省略できるため、リカバリ手順が簡単になります。次の手順では、リカバリ・カタログを使用していないと想定しています。
自動バックアップからサーバー・パラメータ・ファイルをリストアする手順
関連項目:
DBIDを決定する方法の詳細は、データベースのDBIDの確認を参照してください
20.2.1 制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア
制御ファイルの自動バックアップが構成されている場合は、自動バックアップが実行されるたびに、制御ファイルとともにサーバー・パラメータ・ファイルが常にバックアップされます。
制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルをリストアする手順
-
データベースのDBIDを設定します。
-
RESTORE SPFILE FROM AUTOBACKUP
コマンドを使用します。自動バックアップがデフォルト以外の書式である場合は、最初に
SET CONTROLFILE AUTOBACKUP FORMAT
コマンドを使用して書式を指定します。
例20-1 制御ファイルの自動バックアップからのサーバー・パラメータ・ファイルのリストア
この例では、DBIDを設定し、デフォルト以外の場所にある制御ファイルの自動バックアップから、サーバー・パラメータをリストアします。RMANでは、自動バックアップの書式およびDBIDを使用して、制御ファイルの自動バックアップが検索されます。制御ファイルの自動バックアップが検出されると、RMANによってサーバー・パラメータ・ファイルがバックアップからデフォルトの場所にリストアされます。
SET DBID 320066378;
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE SPFILE FROM AUTOBACKUP;
}
関連項目:
-
autobackup_format
の適切な値を判断する方法の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスのCONFIGURE
コマンドのエントリで、CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
の説明を参照してください -
DBIDを決定する方法の詳細は、「データベースのDBIDの確認」を参照してください。
20.2.2 RMANを使用した初期化パラメータ・ファイルの作成
サーバー・パラメータ・ファイルは、TO PFILE 'filename'
句を使用してクライアント側の初期化パラメータ・ファイルとしてリストアすることもできます。
指定するファイル名は、RMANクライアントが実行されているホストからアクセス可能なファイル・システム上にあることを示している必要があります。このファイルは、インスタンスが実行されているホストから直接アクセス可能である必要はありません。
次のRMANコマンドを実行すると、RMANクライアントが実行されているシステム上に/tmp/initTEMP.ora
という名前の初期化パラメータ・ファイルが作成されます。
RESTORE SPFILE TO PFILE '/tmp/initTEMP.ora';
初期化パラメータ・ファイルを使用してインスタンスを再起動するには、次のコマンドを使用して、同じクライアント・ホスト上でRMANを再度実行します。
STARTUP FORCE PFILE='/tmp/initTEMP.ora';
20.3 バックアップ制御ファイルを使用したリカバリの実行
現行の制御ファイルがすべて消失した場合は、バックアップ制御ファイルをリストアする必要があります。
この項では、次の項目について説明します。
20.3.1 バックアップ制御ファイルを使用したリカバリの実行
現行のすべての制御ファイルのコピーが消失したか、または破損した場合は、バックアップ制御ファイルをリストアおよびマウントする必要があります。リストアされたデータファイルがない場合でも、RECOVER
コマンドを実行し、RESETLOGS
オプションを指定してデータベースをオープンする必要があります。
RMANは、リカバリ時にRMANリポジトリに記録されていないオンライン・ログおよびアーカイブ・ログを自動的に検索し、検出したログをカタログに追加します。RMANは、現行のアーカイブ先で、現行のログ・フォーマットを持つすべての有効なアーカイブREDOログの検索を試行します。現行のフォーマットは、このインスタンス(またはOracle RAC構成のすべてのインスタンス)の起動に使用される初期化パラメータで指定されます。同様に、RMANは、制御ファイルに示されたファイル名を使用して、オンラインREDOログの検索を試行します。
リカバリ時にアーカイブ先またはフォーマットを変更したり、制御ファイルのバックアップの後に新しいオンライン・ログ・メンバーを追加すると、RMANで、必要なオンライン・ログまたはアーカイブ・ログを自動的にカタログに追加できなくなる場合があります。RMANでは、UNTIL
時間を指定しなかった場合にオンラインREDOログを検出できないと、次のようなエラーが通知されます。
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 08/29/2013 14:23:09 RMAN-06054: media recovery requesting unknown log: thread 1 scn 86945
この場合、リカバリを続行するには、CATALOG
コマンドを使用して必要なREDOログをリポジトリに手動で追加する必要があります。
注意:
ただし、現行の制御ファイルのいくつかのコピーを使用できる場合は、「現行の制御ファイルのサブセットが消失した場合の対応」の手順を実行し、リカバリおよびRESETLOGS
操作の実行を回避できます。
関連項目:
様々なシナリオ(リカバリ・カタログの使用または特定のバックアップからのリストアなど)でRESTORE CONTROLFILE
を使用する場合の制限の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスのRESTORE CONTROLFILE
の説明を参照してください
20.3.1.1 RMANリストア時の制御ファイルの場所について
制御ファイルをリストアする場合、デフォルトのリストア先は、CONTROL_FILES
初期化パラメータに定義されているすべての場所です。CONTROL_FILES
初期化パラメータを設定しない場合、データベースは、CONTROL_FILES
パラメータが設定されていないときに制御ファイルを作成する場合と同じ規則を使用して、リストアされた制御ファイルの格納先を決定します。
1つ以上の新しい場所に制御ファイルをリストアするには、CONTROL_FILES
初期化パラメータを変更した後、引数を指定せずにRESTORE CONTROLFILE
を実行して制御ファイルをデフォルトの場所にリストアする方法があります。たとえば、CONTROL_FILES
に定義されている場所の一部がディスク障害によって使用できなくなった後に制御ファイルをリストアする場合は、CONTROL_FILES
で障害ディスクへの参照を別のディスクへのパス名に置き換えた後、引数を指定せずにRESTORE CONTROLFILE
を実行します。
RESTORE CONTROLFILE TO ' filename'
という形式を使用して、CONTROL_FILES
に定義されている以外の任意の場所に制御ファイルをリストアすることもできます。
RESTORE CONTROLFILE TO '/tmp/my_controlfile';
現在使用中の制御ファイルは上書きされないため、この操作は、NOMOUNT
、MOUNT
またはOPEN
の状態のデータベースで実行できます。'filename'
という名前のすべての既存ファイルが上書きされます。制御ファイルを新しい場所にリストアした後、CONTROL_FILES
初期化パラメータを更新して新しい場所を追加定義できます。
関連項目:
-
リストアされた制御ファイルの宛先を決定する規則については、Oracle Database SQL言語リファレンスの
CREATE CONTROLFILE
文の説明を参照してください。 -
RESTORE CONTROLFILE
の構文の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスを参照してください
20.3.1.2 RMANのリカバリ・カタログを使用したリカバリおよび使用しないリカバリについて
制御ファイルのリカバリ・プロセスは、リカバリ・カタログを使用するかどうかによって異なります。
RMANがリカバリ・カタログに接続している場合、バックアップ制御ファイルを使用したリカバリ手順は、現行の制御ファイルを使用したリカバリと同様になります。バックアップ制御ファイルで欠落しているRMANメタデータは、リカバリ・カタログで入手可能です。唯一の例外は、データベース名がカタログ内で一意でない場合です。この場合は、SET DBID
コマンドを使用してから制御ファイルをリストアする必要があります。
リカバリ・カタログを使用していない場合は、自動バックアップから制御ファイルをリストアする必要があります。自動バックアップから制御ファイルをリストアするには、データベースがNOMOUNT
状態である必要があります。まずデータベースのDBIDを設定し、次にRESTORE CONTROLFILE FROM AUTOBACKUP
コマンドを使用する必要があります。
例20-2 DBIDの設定および自動バックアップからの制御ファイルのリストア
この例では、RMANは自動バックアップの書式およびDBIDを使用して、制御ファイルの自動バックアップを検索する場所を決定します。制御ファイルの自動バックアップが検出されると、RMANによって、CONTROL_FILES
初期化パラメータに示されているすべての制御ファイルの場所に制御ファイルがリストアされます。
SET DBID 320066378;
RUN
{
SET CONTROLFILE AUTOBACKUP FORMAT
FOR DEVICE TYPE DISK TO 'autobackup_format';
RESTORE CONTROLFILE FROM AUTOBACKUP;
}
関連項目:
-
DBIDを決定する方法の詳細は、データベースのDBIDの確認を参照してください
-
自動バックアップの書式の適切な値を判断する方法の詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスの
CONFIGURE
のエントリで、CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
の説明を参照してください
20.3.1.3 高速リカバリ領域の使用時のRMANリカバリについて
制御ファイルをリストアするコマンドは、データベースで高速リカバリ領域が使用されているかどうかに関係なく同じです。
データベースで高速リカバリ領域が使用されている場合、RMANは、すべてのディスクベースのバックアップおよび制御ファイルに記録されているイメージ・コピーをクロスチェックして、バックアップからリストアされた制御ファイルを更新します。RMANは、リカバリ領域内の記録されていないすべてのバックアップをカタログに追加します。この結果、リストアされた制御ファイルには、リカバリ領域内のすべてのバックアップ、およびバックアップの時点で制御ファイルに認識されたその他のバックアップの完全で正確なレコードが含まれます。
RMANは、制御ファイルをリストアした後、テープ・バックアップのクロスチェックを自動的には実行しません。テープ・バックアップを使用している場合は、制御ファイルをリストアおよびマウントできます。また、必要に応じてテープ上のバックアップをクロスチェックできます。次に例を示します。
CROSSCHECK BACKUP DEVICE TYPE sbt;
20.3.2 バックアップ制御ファイルを使用してリカバリ・カタログを使用しないリカバリの実行
バックアップ制御ファイルを使用してデータベースをリカバリし、リカバリ・カタログを使用しない場合は、自動バックアップから制御ファイルをリストアする必要があります。
この項では、制御ファイルのRMANバックアップを使用し、リカバリ・カタログは使用しないと想定しています。また、ターゲット・データベースの制御ファイルの自動バックアップ機能を有効にして、制御ファイルの自動バックアップをリストアできると想定しています。
自動バックアップでは標準的な書式が使用されるため、使用可能なバックアップを表示するリポジトリが存在しなくても、RMANは自動バックアップをリストアできます。自動バックアップはデフォルトの場所または新しい場所にリストアできます。RMANは、CONTROL_FILES
で指定されたすべての場所に制御ファイルを自動的にレプリケートします。
注意:
(たとえば、メディア・マネージャによって、またはバックアップ・ピースがディスク上に存在するため)制御ファイルを含むバックアップ・ピースの名前がわかっている場合は、RESTORE CONTROLFILE FROM 'filename'
コマンドを使用してバックアップ・ピースの名前を指定できます。データベースは、すべての自動バックアップの場所をアラート・ログに記録します。
リカバリ・カタログに接続していないため、RMANリポジトリには制御ファイルのバックアップの時点で使用可能なバックアップに関する情報のみが含まれます。他の使用可能なバックアップ・セットまたはイメージ・コピーの場所がわかっている場合は、CATALOG
コマンドを使用して制御ファイルのRMANリポジトリに追加します。
NOCATALOG
モードで制御ファイルの自動バックアップを使用してデータベースをリカバリする手順
-
RMANを開始し、RMANによるデータベース接続の確立の説明に従ってターゲット・データベースに接続します。
-
データベースをマウントせずにターゲット・データベース・インスタンスを起動します。次に例を示します。
STARTUP NOMOUNT;
-
SET DBID
コマンドを使用して、ターゲット・データベースのデータベース識別子を設定します。ターゲット・データベースに接続するたびに、DBIDが表示されます。保存されたRMANのログ・ファイルを調べるか、カタログを問い合せるか、または制御ファイルの自動バックアップのファイル名を検索することによって取得することもできます。たとえば、次のコマンドを実行します。
SET DBID 676549873;
-
自動バックアップの制御ファイルをリストアしてリカバリを実行するためのRMANコマンド・ファイルを記述します。
このコマンド・ファイルには、次のステップが含まれています。
-
必要に応じて、最新のバックアップのタイムスタンプを指定します。RMANは、リストアする制御ファイルの自動バックアップの検索時に、このタイムスタンプを使用できます。
-
制御ファイルの自動バックアップの作成時に制御ファイルの自動バックアップの異なる書式が有効になっていたことがわかっている場合は、制御ファイルのリストアにデフォルト以外の書式を指定します。
-
SBTチャネルによって制御ファイルの自動バックアップが作成された場合は、1つ以上のSBTチャネルを割り当てます。使用可能なリカバリ・カタログがないため、事前構成されたチャネルは使用できません。
-
必要に応じて、RMANが検索できる過去の最大日数および最初の日付の検索に使用する最初の順序番号を設定して、制御ファイルの自動バックアップをリストアします。
-
残りのリストア・プロセスに有効な構成済のチャネルに関する情報が制御ファイルに含まれていることがわかっている場合は、RMANを終了し、ステップ4.cで行ったチャネルの手動割当てを解除できます。
RMANクライアントを再起動してデータベースをマウントする場合は、これらの構成済のチャネルを使用できます。制御ファイルに含まれている構成済のチャネルを使用しない場合は、データベースをマウントできます。
-
このステップは、オンラインREDOログが使用可能かどうかによって異なります。ログが使用可能かどうかに関係なく、バックアップ制御ファイルを使用してリカバリを行った後は、常に
OPEN RESETLOGS
オプションが必要となります。オンラインREDOログが使用可能な場合、RMANはこれらのログを検出および適用できます。完全なリストアおよびリカバリを実行します(「データベースの完全リカバリの実行」を参照)。
オンラインREDOログを使用できない場合は、DBPITRを実行します(「データベースのPoint-in-Timeリカバリの実行」を参照)。オンラインREDOログの最初のSCNより前の時点までリカバリする場合の目標時点、SCNまたはログ順序番号を指定するには、
UNTIL
句を使用する必要があります(この句を使用しない場合、RMANはRMAN-6054
エラーを発行します)。バックアップ制御ファイルを使用してDBPITRを実行する場合、
RESETLOGS
を使用してデータベースをオープンする前に、SQL*Plusを使用してデータベースを読取り専用でオープンし、必要に応じて問合せを実行して、論理的な破損の影響が無効にされたことを確認できます。結果が期待どおりだった場合、RESETLOGS
を使用して、データベースをオープンできます。注意:
ログ順序の指定時に、最後に作成されたアーカイブREDOログの順序がnの場合は、RMANがnを適用してから停止するように、
UNTIL SEQUENCE n+1
を指定します。
次の例では、オンラインREDOログ・ファイルが消失しており、最新のアーカイブREDOログの順序番号は13243です。この例は、制御ファイルの自動バックアップをリストアし、最新のログを使用してリカバリする方法を示しています。
RUN { # Optionally, set upper limit for eligible time stamps of control file # backups # SET UNTIL TIME '09/10/2017 13:45:00'; # Specify a nondefault autobackup format only if required # SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK # TO '?/oradata/%F.bck'; ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...'; # allocate manually RESTORE CONTROLFILE FROM AUTOBACKUP MAXSEQ 100 # start at sequence 100 and count down MAXDAYS 180; # start at UNTIL TIME and search back 6 months ALTER DATABASE MOUNT; } # Now use automatic channels configured in restored control file RESTORE DATABASE UNTIL SEQUENCE 13244; RECOVER DATABASE UNTIL SEQUENCE 13244;
-
-
リカバリに成功した場合は、データベースをオープンし、オンライン・ログをリセットします。
ALTER DATABASE OPEN RESETLOGS;
20.4 障害リカバリの実行
障害リカバリには、ターゲット・データベース全体、リカバリ・カタログ・データベース、すべての現行の制御ファイル、すべてのオンラインREDOログ・ファイルおよびすべてのパラメータ・ファイルが消失した後のターゲット・データベースのリストアおよびリカバリが含まれます。
この項では、次の項目について説明します。
20.4.1 障害リカバリの前提条件
RMANを使用して障害時リカバリを実行する前に、特定の前提条件を満たす必要があります。
次のものが必要です。
-
すべてのデータファイルのバックアップ
-
リストアする最も古いバックアップの作成時刻の後に生成されたすべてのアーカイブREDOログ
-
1つ以上の制御ファイルの自動バックアップ
-
データベースのDBIDのレコード
20.4.2 障害発生後のデータベースのリカバリ
データベースが実行されていたLinuxサーバーに修復不可能な破損が発生していると想定します。データベースをOracle Secure Backupにバックアップしてあるため、そのテープを使用できます。これらのバックアップを使用してデータベースをリカバリできます。
障害リカバリの手順は、NOCATALOG
モードでバックアップ制御ファイルを使用してデータベースをリカバリする手順と類似しています。新しいホストにデータベースをリストアする場合は、「新しいホストへのデータベースのリストア」で説明されている考慮事項を参照してください。
この例では、次のことを想定しています。
-
Oracle Databaseが新しいホストにインストールされています。
-
古いホストと同じディレクトリ構造を持つ新しいLinuxホストにデータベースをリストアします。
-
1つのテープ・ドライブを使用します(このテープ・ドライブには、すべてのデータファイルのバックアップ、ログ1124までのアーカイブREDOログおよび制御ファイルとサーバー・パラメータ・ファイルの自動バックアップが含まれています)。
-
データベースでリカバリ・カタログは使用しません。
新しいホストにデータベースをリカバリする手順
-
障害リカバリの前提条件で説明している前提条件を満たしていることを確認します。
-
可能な場合は、
tnsnames.ora
、listener.ora
、パスワード・ファイルなどの関連するすべてのネットワーク・ファイルをリストアまたは再生成します。 -
RMANを開始し、RMANによるデータベース接続の確立の説明に従ってターゲット・データベース・インスタンスに接続します。
この時点では、初期化パラメータ・ファイルは存在しません。
ORACLE_SID
およびORACLE_HOME
を設定すると、オペレーティング・システム認証を使用してSYSDBA
またはSYSBACKUP
として接続できます。 -
SET
DBID
コマンドを使用してターゲット・データベースのDBIDを指定します(「サーバー・パラメータ・ファイルのリストア」を参照)。たとえば、次のコマンドを入力します。
SET DBID 676549873;
-
STARTUP NOMOUNT
コマンドを実行します。サーバー・パラメータ・ファイルを使用できない場合、RMANは仮のサーバー・パラメータ・ファイルを使用してインスタンスの起動を試行します。
-
チャネルをメディア・マネージャに割り当て、自動バックアップからサーバー・パラメータ・ファイルをリストアします。
たとえば、Oracle Secure Backupからサーバー・パラメータ・ファイルをリストアする場合は、次のコマンドを入力します。
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; RESTORE SPFILE FROM AUTOBACKUP; }
-
リストアしたサーバー・パラメータ・ファイルを使用してインスタンスを再起動します。
STARTUP FORCE NOMOUNT;
-
リストアおよびリカバリ操作を実行するためのコマンド・ファイルを記述し、そのコマンド・ファイルを実行します。このコマンド・ファイルでは、次の手順を実行する必要があります。
-
チャネルをメディア・マネージャに割り当てます。
-
制御ファイルの自動バックアップをリストアします(「バックアップ制御ファイルを使用してリカバリ・カタログを使用しないリカバリの実行」を参照)。
-
リストアした制御ファイルをマウントします。
-
CATALOG
コマンドを使用して、リポジトリに記録されていないバックアップをカタログに追加します。 -
データファイルを元の場所にリストアします。 ボリューム名が変更されている場合は、リストア操作の前に
SET
NEWNAME
コマンドを実行し、リストア操作の後にSWITCHを実行して、制御ファイルをデータファイルの新しい場所に更新します。次に例を示します。 -
データファイルをリカバリします。指定したログ順序番号に達すると、RMANによってリカバリが停止されます。
RMAN> RUN { # Manually allocate a channel to the media manager ALLOCATE CHANNEL t1 DEVICE TYPE sbt; # Restore autobackup of the control file. This example assumes that you have # accepted the default format for the autobackup name. RESTORE CONTROLFILE FROM AUTOBACKUP; # The set until command is used in case the database # structure has changed in the most recent backups, and you want to # recover to that point in time. In this way RMAN restores the database # to the same structure that the database had at the specified time. ALTER DATABASE MOUNT; SET UNTIL SEQUENCE 1124 THREAD 1; RESTORE DATABASE; RECOVER DATABASE; }
次の
RUN
コマンドの例は、リストアしたデータファイルに新しいファイル名を使用することを除き、前述の例と同様です。RMAN> RUN { # If you must restore the files to new locations, # use SET NEWNAME commands: SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1'; SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2'; SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3'; ALLOCATE CHANNEL t1 DEVICE TYPE sbt; RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; SET UNTIL SEQUENCE 124 THREAD 1; RESTORE DATABASE; SWITCH DATAFILE ALL; # Update control file with new location of data files. RECOVER DATABASE; }
-
-
リカバリに成功した場合は、データベースをオープンし、オンライン・ログをリセットします。
ALTER DATABASE OPEN RESETLOGS;
20.5 新しいホストへのデータベースのリストア
新しいホストにデータベースをリストアするには、RESTORE
およびRECOVER
コマンドを使用します。新しいホストへのデータベースのリストアは、障害リカバリ手順のテスト実行を行う場合や、データベースを新しいホストに永続的に移動する場合に役立ちます。
この項の手順を実行すると、リストアされるデータベースのDBIDは、元のデータベースのDBIDと同じになります。この方法で作成したテスト・データベースは、ソース・データベースと同じリカバリ・カタログに登録しないでください。2つのデータベースのDBIDが同じであるため、テスト・データベースのメタデータが、ソース・データベースをリストアおよびリカバリするRMANの機能に影響を与える可能性があります。
新しいホストで継続して使用するためにターゲット・データベースのコピーを作成する場合は、この手順ではなく、RMANのDUPLICATE
コマンドを実行します。DUPLICATE
コマンドを実行すると、作成されるデータベースに対して新しいDBIDが割り当てられるため、このデータベースを元のデータベースと同じリカバリ・カタログに追加できます。
新しいホストにデータベースをリストアする手順
-
新しいホストへのデータベースのリストアの準備の説明に従って、データベースをリストアする前に実行する必要があるステップを実行します。
-
新しいホストへのディスク・バックアップのリストアの説明に従って、ターゲット・データベースのバックアップを新しいホストに転送し、バックアップをリストアします。
関連項目:
20.5.1 新しいホストへのデータベースのリストアの準備
新しいホストへのデータベースのリストアを準備するには、特定のステップを実行する必要があります。
次のステップがあります。
-
ソース・データベースのDBIDを記録します。
-
新しいホスト上でソース・データベースの初期化パラメータ・ファイルをアクセス可能にします。オペレーティング・システム・ユーティリティを使用して、古いホストから新しいホストにこのファイルをコピーします。
-
テスト・リストア操作のみを実行する場合は、RMANがリカバリ・カタログに接続されていないことを確認してください。接続されている場合は、RMANによって、リストアされたデータファイルに関するメタデータがリカバリ・カタログに記録されます。このメタデータは、プライマリ・データベースを将来リストアおよびリカバリする場合の障害となります。
リストアする必要があるすべてのバックアップのRMANリポジトリ・データを格納するには制御ファイルのサイズが十分ではないため、リカバリ・カタログを使用する必要がある場合は、Oracle Data Pumpを使用してカタログをエクスポートし、別のスキーマまたはデータベースにインポートします。その後、コピーしたリカバリ・カタログをテスト・リストアに使用します。これを行わない場合、リカバリ・カタログでは、リストアされたデータベースが現行のターゲット・データベースとみなされます。
-
リストア操作に使用されるバックアップがリストア・ホスト上でアクセス可能であることを確認します。たとえば、メディア・マネージャを使用してバックアップを作成した場合は、テープ・デバイスが新しいホストに接続されていることを確認します。ディスクのコピーを使用している場合は、次の項の手順を実行します。
-
本番データベースの試行リストアを実行する場合は、テスト環境でデータベースをリストアする前に、次の操作のいずれかを実行します。
-
本番データベースが使用しているリカバリ領域とは物理的に異なる高速リカバリ領域をテスト・データベースで使用する場合は、テスト・データベース・インスタンスの
DB_RECOVERY_FILE_DEST
を新しい場所に設定します。 -
本番データベースで使用されるリカバリ領域と物理的に同じ高速リカバリ領域をテスト・データベースで使用する場合は、テスト・データベース・インスタンスの
DB_UNIQUE_NAME
を、本番データベースとは異なる名前に設定します。
前述の操作をどちらも実行しないと、RMANでは、本番データベースをリストアしていると判断し、高速リカバリ領域の フラッシュバック・ログを使用不可能とみなして削除します。
-
関連項目:
データベースのDBIDを決定する方法の詳細は、データベースのDBIDの確認を参照してください
20.5.2 新しいホストへのディスク・バックアップのリストア
ディスク上のデータファイルのコピーまたはバックアップ・セットを使用して新しいホストにデータベースを移動するには、新しいホストにそのファイルを手動で転送する必要があります。次の手順では、RMANでリカバリ・カタログが使用されていると想定しています。
バックアップ・ファイルを新しいホストにリストアする方法
-
RMANを開始し、RMANによるデータベース接続の確立の説明に従って、ターゲット・データベースおよびリカバリ・カタログに接続します。
-
LIST
コマンドを実行して、データファイルのバックアップおよび制御ファイルの自動バックアップのリストを表示します。たとえば、次のコマンドを入力してデータファイルのコピーを表示します。
LIST COPY;
たとえば、次のコマンドを入力して制御ファイルのバックアップを表示します。
LIST BACKUP OF CONTROLFILE;
自動バックアップ・ピースの名前には、
%F
置換変数を使用する必要があります。したがって、自動バックアップ・ピースの名前には、文字列c-IIIIIIIIII-YYYYMMDD-QQ
が含まれます。ここで、IIIIIIIIII
はDBIDを表し、YYYYMMDD
はバックアップが生成された日のグレゴリオ暦でのタイムスタンプ、QQ
は16進数の順序です。 -
オペレーティング・システム・ユーティリティを使用して、バックアップを新しいホストにコピーします。
次のコマンドを入力して、すべてのデータファイルのコピーを新しいホストの
?/oradata/trgt
ディレクトリにコピーします。% cp -r /disk1/*dbf /net/new_host/oracle/oradata/trgt
次のコマンドを入力して、自動バックアップのバックアップ・ピースを新しいホストの
/tmp
ディレクトリにコピーします。% cp -r /disk1/auto_bkp_loc/c-1618370911-20130208-00 /net/new_host/tmp
デフォルト以外の場所から自動バックアップをリストアする場合は、
SET CONTROLFILE AUTOBACKUP FORMAT
コマンドを使用する必要があります。
20.5.3 新しいホストへのデータベースのリストアのテスト
データベースを新しいホストにリストアできるかどうかをテストすることをお薦めします。
この例では、ネットワークで接続された2台のLinuxホストhosta
とhostb
を使用します。trgta
という名前のターゲット・データベースがhosta
上に存在し、リカバリ・カタログcatdb
に登録されています。データベースtrgta
が起動され、hosta
上で実行されている間に、hostb
上でtrgta
のリストアおよびリカバリをテストします。
ここで、hostb
のディレクトリ構造はhosta
のディレクトリ構造と異なっていると想定します。ターゲット・データベースは/net/hosta/dev3/oracle/dbs
に存在していますが、このデータベースを/net/hostb/oracle/oradata/test
にリストアします。データファイル、制御ファイル、アーカイブREDOログおよびサーバー・パラメータ・ファイルのテープ・バックアップが、両方のホストからアクセス可能なメディア・マネージャ上にあります。TRGTA
データベースのORACLE_SID
は、TRGTA
であり、リストアされたデータベースでも変更しません。
注意:
テストの目的でデータベースをリストアする場合は、RMANをテスト・データベースおよびリカバリ・カタログに接続しないでください。
新しいホストにデータベースをリストアする手順
-
ターゲット・データベースのバックアップが新しいホスト上でアクセス可能であることを確認します。
障害リカバリをテストするには、ターゲット・データベースのリカバリ可能なバックアップが必要です。障害リカバリ計画を作成する場合は、データファイル、制御ファイルおよびサーバー・パラメータ・ファイルのバックアップが
hostb
上にリストア可能であることを確認します。そのため、hostb
をメディア・マネージャのクライアントにして、hosta
上に作成されたバックアップ・セットを読み取ることができるように、メディア管理ソフトウェアを構成する必要があります。この問題に対するサポートについては、メディア管理ベンダーに問い合せてください。 -
hostb
上でORACLE_SID
を構成します。この例では、RMANクライアントを
hostb
上で起動し、オペレーティング・システムを介して自分を認証すると想定しています。ただし、ローカルで、またはネット・サービス名を介して、hostb
に接続する必要があります。管理者権限を使用して
hostb
にログインした後、自分がDBAグループに含まれるように/etc/group
ファイルを編集します。dba:*:614:<your_user_name>
hostb
上で、環境変数ORACLE_SID
をhosta
上で使用した値と同じ値に設定します。% setenv ORACLE_SID trgta
-
hostb
上でRMANを起動し、リカバリ・カタログに接続せずにターゲット・データベースに接続します。たとえば、次のコマンドを入力します。
% rman NOCATALOG RMAN> CONNECT TARGET /
-
DBIDを設定し、データベースをマウントせずにデータベース・インスタンスを起動します。
たとえば、
SET
DBID
を実行してDBIDを設定し、次にSTARTUP
NOMOUNT
を実行します。SET DBID 1340752057; STARTUP NOMOUNT
サーバー・パラメータ・ファイルがリストアされていないため、RMANがサーバー・パラメータ・ファイルの検出に失敗しますが、仮のファイルを使用してインスタンスが起動されます。出力例を次に示します。
startup failed: ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/net/hostb/oracle/dbs/inittrgta.ora' trying to start the Oracle instance without parameter files ... Oracle instance started
-
サーバー・パラメータ・ファイルをリストアおよび編集します。
バックアップの実行時に制御ファイルの自動バックアップ機能を有効にしたため、バックアップにサーバー・パラメータ・ファイルが含まれます。デフォルト以外の書式の自動バックアップをリストアする場合は、
SET CONTROLFILE AUTOBACKUP FORMAT
コマンドを使用して書式を指定します。メディア・マネージャにチャネルを割り当て、サーバー・パラメータ・ファイルをクライアント側のパラメータ・ファイルとしてリストアし、
SET
コマンドを使用して自動バックアップの場所を指定します(この例では、自動バックアップは/tmp
にあります)。RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...'; SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F'; RESTORE SPFILE TO PFILE '?/oradata/test/inittrgta.ora' FROM AUTOBACKUP; SHUTDOWN ABORT; }
-
リストアされた初期化パラメータ・ファイルを編集します。
末尾が
_DEST
などの場所固有のすべてのパラメータを変更し、新しいディレクトリ構造を反映します。たとえば、次のパラメータを編集します。- IFILE - LOG_ARCHIVE_DEST_1 - CONTROL_FILES
-
編集した初期化パラメータ・ファイルを使用してインスタンスを再起動します。
たとえば、次のコマンドを入力します。
STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
-
自動バックアップから制御ファイルをリストアし、データベースをマウントします。
たとえば、次のコマンドを入力します。
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...'; RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; }
CONTROL_FILES
初期化パラメータで指定した場所に制御ファイルがリストアされます。 -
新しいファイル名または
CATALOG START
WITH
(すべてのファイルが共通の接頭辞を持つディレクトリに含まれ、CATALOG START WITH
コマンドで簡単に指定できることがわかっている場合)を使用して、「新しいホストへのディスク・バックアップのリストア」でコピーしたデータファイルのコピーをカタログに追加します。たとえば、次のコマンドを実行します。CATALOG START WITH '/oracle/oradata/trgt/';
ファイルを個別に指定する場合は、
CATALOG
コマンドを次のように実行します。CATALOG DATAFILECOPY '/oracle/oradata/trgt/system01.dbf', '/oracle/oradata/trgt/undotbs01.dbf', '/oracle/oradata/trgt/cwmlite01.dbf', '/oracle/oradata/trgt/drsys01.dbf', '/oracle/oradata/trgt/example01.dbf', '/oracle/oradata/trgt/indx01.dbf', '/oracle/oradata/trgt/tools01.dbf', '/oracle/oradata/trgt/users01.dbf';
-
新しいデータベース上でSQL*Plusセッションを開始し、制御ファイルに記録されたデータベースのファイル名を問い合せます。
制御ファイルは
trgta
データベースからリストアされているため、記録されたファイル名では元のhosta
のファイル名が使用されます。V$
ビューを問い合せると、この情報を取得できます。SQL*Plusで次の問合せを実行します。COLUMN NAME FORMAT a60 SPOOL LOG '/tmp/db_filenames.out' SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE UNION SELECT GROUP#,MEMBER FROM V$LOGFILE; SPOOL OFF EXIT
-
RMANのリストア・スクリプトおよびリカバリ・スクリプトを記述します。このスクリプトには、次のステップが含まれている必要があります。
-
ソース・ホスト上のパスとは異なるパスにリストアされた宛先ホスト上の各データファイルに対して、
SET
NEWNAME
コマンドを使用して宛先ホスト上に新しいパスを指定します。宛先システム上のファイル・システムがソース・ホスト上のパスと同じパスを持つように設定されている場合は、ソース・ホスト上のパスと同じパスにリストアされるファイルに対してSET NEWNAME
を使用しないでください。 -
ソース・ホスト上の場所とは異なる場所に作成される各オンラインREDOログに対して、SQLの
ALTER
DATABASE
RENAME
FILE
コマンドを使用して宛先ホスト上にパス名を指定します。宛先システム上のファイル・システムがソース・ホスト上のパスと同じパスを持つように設定されている場合は、ソース・ホスト上のパスと同じパスにリストアされるファイルに対してALTER DATABASE RENAME FILE
を使用しないでください。 -
SET UNTIL
操作を実行して、リカバリをアーカイブREDOログの最後までに制限します。SET UNTIL
コマンドが指定されていない場合、エラーが発生してリカバリが停止します。 -
データベースをリストアおよびリカバリします。
-
SWITCH DATAFILE ALL
コマンドを実行して、新しいパス名をデータファイルの正式な新しい名前として制御ファイルに認識させます。
次のコードに、リストアおよびリカバリ操作を実行できるRMANスクリプト
reco_test.rman
を示します。RUN { # allocate a channel to the tape device ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...'; # rename the data files and online redo logs SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf'; SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf'; SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/cwmlite01.dbf'; SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/drsys01.dbf'; SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf'; SET NEWNAME FOR DATAFILE 6 TO '?/oradata/test/indx01.dbf'; SET NEWNAME FOR DATAFILE 7 TO '?/oradata/test/tools01.dbf'; SET NEWNAME FOR DATAFILE 8 TO '?/oradata/test/users01.dbf'; ALTER DATABASE RENAME FILE '/dev3/oracle/dbs/redo01.log' TO '?/oradata/test/redo01.log'; ALTER DATABASE RENAME FILE '/dev3/oracle/dbs/redo02.log' TO '?/oradata/test/redo02.log'; # Do a SET UNTIL to prevent recovery of the online logs SET UNTIL SCN 123456; # restore the database and switch the data file names RESTORE DATABASE; SWITCH DATAFILE ALL; # recover the database RECOVER DATABASE; } EXIT
-
-
前述のステップで作成したスクリプトを実行します。
たとえば、RMANを起動してターゲット・データベースに接続し、
@
コマンドを実行します。% rman TARGET / NOCATALOG RMAN> @reco_test.rman
-
RESETLOGS
オプションを指定して、リストアしたデータベースをオープンします。RMANプロンプトで、
RESETLOGS
オプションを指定してデータベースをオープンします。ALTER DATABASE OPEN RESETLOGS;
注意:
次のステップでデータベースを再オープンする場合は、リカバリ・カタログに接続しないでください。そうしなかった場合は、作成される新しいデータベース・インカネーションがリカバリ・カタログに自動的に登録され、本番データベースのファイル名が、スクリプトに指定されている新しいファイル名に置換されます。
-
必要に応じて、含まれているすべてのファイルとともにテスト・データベースを削除します。
注意:
ASMディスク・グループを使用した場合、テスト・データベースのファイルを安全に削除する方法は
DROP DATABASE
コマンドのみです。非ASMストレージにリストアした場合は、オペレーティング・システムのコマンドを使用してデータベースを削除することもできます。DROP DATABASE
コマンドを使用して、データベースに関連付けられているすべてのファイルを自動的に削除します。次の例では、データベース・ファイルを削除します。STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora'; DROP DATABASE;
リカバリ・カタログへの接続時にリストアおよびリカバリ操作を実行しなかったため、リカバリ・カタログには、リストアしたファイルまたはテスト中に実行した手順のレコードは含まれません。同様に、
trgta
データベースの制御ファイルは、テストによる影響を受けません。
関連項目:
20.6 古いバージョンのRMANを使用して作成されたバックアップのリストア
Oracle Database 9iリリース2 (9.2.0.8)までの古いバージョンのRMANを使用して作成されたバックアップをリストアできます。
この例では、ソース・データベースはOracle Database 11gリリース2データベースで、サーバー・パラメータ・ファイル(spfile)を使用するように構成されています。データベースはARCHIVELOG
モードで実行され、高速リカバリ領域を使用します。制御ファイルの自動バックアップも構成されます。アーカイブREDOログを含む、ソース・データベースのRMANバックアップを作成します。
これらのバックアップがリストアされる宛先ホストには、Oracle Database 12cリリース1がインストールされています。
現行のターゲット・データベース・バージョンより古いRMANバージョンを使用して作成されたRMANバックアップをリストアするには、次の手順を実行します。
20.7 ネットワークを介したファイルのリストアおよびリカバリ
RMANでは、必要なファイルが含まれるフィジカル・スタンバイ・データベースへネットワークを介して接続し、ファイルのリストアまたはリカバリを可能にします。データベース全体、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイルまたは表領域をリストアできます。プライマリ・データベースおよびスタンバイ・データベースを同期化する必要がある場合、ネットワークを介したファイルのリストアは、非常に有用です。
ネットワークを介してファイルをリストアまたはリカバリする場合、バックアップ・セットが使用されます。そのため、マルチセクション・バックアップ、暗号化および圧縮を使用して、バックアップとリストアのパフォーマンスを向上させることができます。
ネットワークを介したファイルのリストアおよびリカバリは、Oracle Database 12cリリース1 (12.1)からサポートされています。
この項の内容は次のとおりです。
20.7.1 ネットワークを介したファイルのリストアについて
RMANは、RESTORE
コマンドのFROM SERVICE
句を使用し、フィジカル・スタンバイ・データベースからネットワークを介してデータベース・ファイルをリストアします。
FROM SERVICE
句では、ファイルをリストアする必要があるフィジカル・スタンバイ・データベースのサービス名を指定します。リストア操作では、リストアする必要があるファイルのバックアップ・セットがRMANによってフィジカル・スタンバイ・データベース上に作成され、これらのバックアップ・セットがネットワークを介してターゲット・データベースに転送されます。
マルチセクション・リストア操作を実行するには、RESTORE
コマンドでSECTION SIZE
句を使用します。フィジカル・スタンバイ・データベース上に作成されたバックアップ・セットを暗号化するには、RESTORE
コマンドの前に、SET ENCRYPTION
コマンドで、使用される暗号化アルゴリズムを指定します。
フィジカル・スタンバイ・データベースから、圧縮されたバックアップ・セットとしてファイルを転送するには、RESTORE
コマンドでUSING COMPRESSED BACKUPSET
句を使用します。デフォルトでは、RMANの構成で設定されているアルゴリズムを使用して、バックアップ・セットが圧縮されます。RESTORE
文の前にSET COMPRESSION ALGORITHM
コマンドを使用することで、異なるアルゴリズム設定でデフォルトをオーバーライドできます。
20.7.2 ネットワークを介したファイルのリカバリについて
プライマリ・データベースからネットワークを介して増分バックアップをフェッチし、この増分バックアップをフィジカル・スタンバイ・データベースに適用することによって、リカバリを実行できます。
RMANはTARGET
としてフィジカル・スタンバイ・データベースに接続されます。リカバリ・プロセスは、データファイル内の使用済データ・ブロックのみをリストアすることによって最適化されます。FROM SERVICE
句を使用して、増分バックアップをフェッチする必要があるプライマリ・データベースのサービス名を指定します。
リカバリ・プロセスでマルチセクション・バックアップ・セットを使用するには、RECOVER
コマンドでSECTION SIZE
句を指定します。プライマリ・データベースから暗号化バックアップ・セットとして必要なファイルを転送するには、RESTORE
コマンドの前に、SET ENCRYPTION
コマンドで、バックアップ・セットの作成に使用される暗号化アルゴリズムを指定します。
ネットワークを介したファイルのリカバリに使用されるバックアップ・セットを圧縮するには、USING COMPRESSED BACKUPSET
を使用します。RMANでは、プライマリ・データベース上にバックアップ・セットを作成する際にこれらを圧縮し、その後ターゲット・データベースに転送します。
20.7.3 ネットワークを介したファイルのリストアおよびリカバリの例
ネットワークを介してフィジカル・スタンバイ・データベースに接続し、ファイルをリカバリすることは、特定の場合に役立ちます。
次のような場合があります。
-
フィジカル・スタンバイ・データベースをロールフォワードしてプライマリ・データベースと同期化する必要がある場合。
プライマリ・データベースで最新の変更の増分バックアップを作成した後、その増分バックアップを使用してフィジカル・スタンバイ・データベースをリストアできます。
-
プライマリ・データベースで失われたデータファイル、制御ファイルまたは表領域を、フィジカル・スタンバイ・データベース上の対応するファイルを使用してリストアする必要がある場合。プライマリ・データベースを使用してフィジカル・スタンバイ・データベース上のファイルをリストアすることもできます。
20.7.4 ネットワークを介したデータファイルのリストア
RESTORE
コマンドを使用して、ネットワーク経由でプライマリ・データベースまたはフィジカル・スタンバイ・データベースに接続することで、消失または破損したデータファイルをリストアします。
この例では、プライマリ・データベースのDB_UNIQUE_NAME
がMAIN
で、フィジカル・スタンバイ・データベースのDB_UNIQUE_NAME
がSTANDBY
です。プライマリ・データベースのデータファイルsales.dbf
が失われました。このデータファイルをフィジカル・スタンバイ・データベースからリストアする必要があります。フィジカル・スタンバイ・データベースのサービス名はstandby_tns
です。RESTORE
コマンドにFROM SERVICE
句を使用すると、フィジカル・スタンバイ・データベースのデータファイルを使用してプライマリ・データベースの失われたデータファイルをリストアできます。プライマリ・データベースとフィジカル・スタンバイ・データベースのパスワード・ファイルは、同じです。
次のステップを使用して、プライマリ・データベースのデータファイルsales.dbf
をフィジカル・スタンバイ・データベースのデータファイルを使用してリストアします。
20.7.5 RECOVERコマンドを使用したフィジカル・スタンバイ・データベースのロールフォワード
RMANでは、プライマリ・データベースへの変更を含む増分バックアップを作成し、ネットワークを介して増分バックアップをフィジカル・スタンバイ・データベースに転送し、この増分バックアップをフィジカル・スタンバイ・データベースに適用することによって、フィジカル・スタンバイ・データベースをロールフォワードします。プライマリ・データベース上のデータファイルへのすべての変更(スタンバイ・データファイル・ヘッダがSCNで始まる)が、この増分バックアップに含まれます。
RECOVER ... FROM SERVICE
コマンドを使用すると、フィジカル・スタンバイ・データベース上のデータファイルを、プライマリ・データベース上のデータファイルと同期化できます。このコマンドを使用すると、スタンバイ・データファイルを更新し、プライマリと同じ時点にロールフォワードできます。ただし、スタンバイ制御ファイルには、スタンバイ・データファイルのSCN値より小さい古いSCN値が含まれたままになります。したがって、フィジカル・スタンバイ・データベースの同期を完了するには、スタンバイ制御ファイルを更新し、更新されたスタンバイ制御ファイルのデータファイル名、オンラインREDOログ・ファイル名、スタンバイREDOログ・ファイル名を更新する必要があります。
ネットワーク・リソースに制約がある場合は、BACKUP INCREMENTAL
コマンドを使用してプライマリ・データベース上に増分バックアップを作成し、この増分バックアップを使用してフィジカル・スタンバイ・データベースをロールフォワードできます。
プライマリ・データベースで行われた変更を使用してフィジカル・スタンバイ・データベースを更新するステップでは、FROM SERVICE
句を使用してフィジカル・スタンバイをリフレッシュするステップについて説明します。
関連項目:
BACKUP INCREMENTAL
コマンドを使用したフィジカル・スタンバイ・データベースのロールフォワードの詳細は、Oracle Data Guard概要および管理を参照してください
20.7.5.1 プライマリ・データベースで行われた変更を使用してフィジカル・スタンバイ・データベースをリフレッシュするステップ
RECOVER STANDBY DATABASE
コマンドをFROM SERVICE
句とともに使用して、プライマリ・データベースに対して行われた変更でフィジカル・スタンバイ・データベースをリフレッシュします。
この例では、プライマリ・データベースのDB_UNIQUE_NAME
はMAIN
で、そのネット・サービス名はprimary_db
であると仮定します。スタンバイ・データベースのDB_UNIQUE_NAME
は、STANDBY
で、そのネット・サービス名はstandby_db
だとします。
プライマリ・データベースで行われた変更を使用してフィジカル・スタンバイ・データベースを更新する手順
-
次の前提条件が満たされていることを確認してください。
-
Oracle Net接続性が、フィジカル・スタンバイ・データベースとプライマリ・データベースとの間で確立されている。
これは、フィジカル・スタンバイ・データベースの
tnsnames.ora
ファイルに、プライマリ・データベースに対応するエントリを加えることによって行うことができます。 -
プライマリ・データベースとフィジカル・スタンバイ・データベースのパスワード・ファイルが同じである。
-
プライマリ・データベースおよびフィジカル・スタンバイ・データベースの初期化パラメータファイルの、
COMPATIBLE
パラメータが12.0に設定されている。
-
-
RMANを起動して、ターゲットとしてフィジカル・スタンバイ・データベースに接続します。リカバリ・カタログにも接続することをお薦めします。
次のコマンドで
TARGET
としてフィジカル・スタンバイ・データベースに接続し、CATALOG
としてリカバリ・カタログに接続します。フィジカル・スタンバイ・データベースへの接続は、sbu
ユーザーを使用して確立されます。このユーザーにはSYSBACKUP
権限が与えられています。フィジカル・スタンバイ・データベースのネット・サービス名はstandby_db
で、リカバリ・カタログのネット・サービス名はcatdb
です。CONNECT TARGET "sbu@standby_db AS SYSBACKUP"; CONNECT CATALOG rman@catdb;
-
FROM SERVICE
句を指定してRECOVER STANDBY DATABASE
コマンドを使用し、フィジカル・スタンバイ・データベースをロールフォワードします。FROM SERVICE
句では、フィジカル・スタンバイをロールフォワードする必要があるプライマリ・データベースのサービス名を指定します。スタンバイ・データベースは、ロール・フォワード操作後に再起動されます。次の例では、サービス名が
primary_db
であるプライマリ・データベースを使用して、フィジカル・スタンバイ・データベースをロールフォワードします。RECOVER STANDBY DATABASE FROM SERVICE primary_db;
-
(Active Data Guardの場合のみ)次のステップを実行して、REDOデータをリカバリし、フィジカル・スタンバイ・データベースを読取り専用モードでオープンします。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE UNTIL CONSISTENT; ALTER DATABASE OPEN READ ONLY;
-
フィジカル・スタンバイ・データベース上の管理リカバリ・プロセスを開始します。
次のコマンドでは、管理リカバリ・プロセスを開始します。
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Data Guard Brokerを使用する場合、次のコマンドを使用して、管理リカバリ・プロセスを開始します。
DGMGRL> edit database standby_db set state='APPLY-ON';
関連項目:
Oracle Netの接続確立の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。