| Oracle® Data Guard概要および管理 11gリリース2 (11.2) B56302-06 |
|
 前 |
 次 |
この章では、Data Guardおよびスタンバイ・データベースとともにOracle Recovery Manager(RMAN)を使用するバックアップ対策について説明します。Recovery Managerを使用すると、最小限の労力でプライマリ・データベースのバックアップを実行し、個々のデータファイルの消失またはデータベース全体をすばやくリカバリできます。Recovery ManagerとData Guardを併用すると、Data Guard構成の管理作業を簡素化できます。
この章は、次の項目で構成されています。
|
注意: ロジカル・スタンバイ・データベースはプライマリ・データベースのブロック単位のコピーではないため、ロジカル・スタンバイ・データベースを使用してプライマリ・データベースをバックアップすることはできません。 |
|
関連項目:
|
Recovery Managerでは、リカバリ・カタログを使用して、Data Guard環境のすべてのデータベース・ファイルについてファイル名を追跡管理します。リカバリ・カタログは、1つ以上のOracleデータベースに関するメタデータを格納するためにRecovery Managerで使用されるデータベース・スキーマです。また、カタログには、オンラインREDOログ、スタンバイREDOログ、テンプレート、アーカイブREDOログ、バックアップ・セットおよびイメージ・コピーが作成される場所も記録されます。
Recovery Managerコマンドは、リカバリ・カタログのメタデータを使用して、Data Guard環境の様々なフィジカル・データベースにわたって透過的に動作します。たとえば、フィジカル・スタンバイ・データベースで表領域のバックアップを作成し、プライマリ・データベースでリストアおよびリカバリできます。同様に、プライマリ・データベースで表領域のバックアップを作成し、フィジカル・スタンバイ・データベースでリストアおよびリカバリできます。
|
注意: ロジカル・スタンバイ・データベースのバックアップは、プライマリ・データベースでは使用できません。 |
スタンバイ制御ファイルとスタンバイ以外の制御ファイルのバックアップには互換性があります。たとえば、スタンバイ制御ファイルをプライマリ・データベースでリストアしたり、プライマリ制御ファイルをフィジカル・スタンバイ・データベースでリストアできます。この互換性は、制御ファイルのバックアップをData Guard環境の1つのデータベースにオフロードできるということです。Recovery Managerは、データベースでのリストアおよびリカバリ時に、データベース・ファイルのファイル名を自動的に更新します。
リカバリ・カタログでは、すべてのデータベース・ファイル(バックアップ・ファイル)をDB_UNIQUE_NAMEに関連付けて、Data Guard環境のファイルを追跡管理します。ファイルを作成するデータベースは、そのファイルに関連付けられます。たとえば、Recovery Managerで一意の名前standby1が付けられたデータベースのバックアップが作成されると、standby1はこのバックアップに関連付けられます。バックアップは、CHANGE ... RESET DB_UNIQUE_NAMEを使用して別のデータベースに関連付けないかぎり、作成元のデータベースに関連付けられたままです。
バックアップのアクセシビリティは、その関連付けとは異なります。Data Guard環境では、関連付けられたデータベースのみがディスク・バックアップにアクセスできるとリカバリ・カタログによってみなされますが、1つのデータベースに作成されたテープ・バックアップにはすべてのデータベースがアクセスできます。バックアップ・ファイルがいずれのデータベースにも関連付けられていない場合、リカバリ・カタログ・ビュー内のバックアップ・ファイルに関する行のSITE_KEY列にnullが表示されます。デフォルト設定では、Recovery Managerはターゲット・データベースにSITE_KEYがnullのファイルを関連付けます。
BACKUP、RESTORE、CROSSCHECKなどのRecovery Managerコマンドは、アクセス可能なバックアップに対して作用します。たとえば、RECOVER COPY操作の場合、Recovery Managerはデータベースに関連付けられているイメージ・コピーのみをリカバリ対象とみなします。また、ディスクおよびテープ上の増分バックアップをイメージ・コピーのリカバリ対象とみなします。データベース・リカバリでは、Recovery Managerは、データベースに関連付けられたディスク・バックアップのみとテープ上のすべてのファイルをリストアの対象とみなします。
バックアップのアクセス可能性における差異を示すため、データベースprodおよびstandby1が異なるホスト上に存在すると仮定します。Recovery Managerは、prodのデータファイル1のバックアップを本番ホスト上にある/prmhost/disk1/df1.dbfおよびテープに作成します。また、standby1のデータファイル1のバックアップをスタンバイ・ホスト上にある/sbyhost/disk2/df1.dbfおよびテープに作成します。Recovery Managerがデータベースprodに接続されると、Recovery Managerコマンドを使用してスタンバイ・ホスト上にある/sbyhost/disk2/df1.dbfバックアップで操作を実行することはできません。しかし、Recovery Managerはstandby1で作成したテープ・バックアップをリストア対象とみなします。
|
注意: スタンバイ・ホストからプライマリ・ホスト(またはその逆)にバックアップをFTP転送し、対象のホスト上のデータベースにTARGETとして接続した後、バックアップに対してCATALOGを実行することができます。ファイルは、ターゲット・データベースによってカタログに追加された後に、ターゲット・データベースに関連付けられます。 |
Data Guard構成では、制御ファイル、データファイルおよびアーカイブ・ログのバックアップ処理をスタンバイ・システムにオフロードできるため、バックアップが本番システムに与える影響は最小限に抑えられます。これらのバックアップを使用すると、プライマリ・データベースまたはスタンバイ・データベースをリカバリできます。
Recovery Managerでは、DB_UNIQUE_NAME初期化パラメータを使用してデータベース・サイトどうしを区別します。そのため、DB_UNIQUE_NAMEの一意性がData Guard構成で維持されることは不可欠なことです。
Recovery ManagerのREGISTER DATABASEコマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、Recovery Managerをリカバリ・カタログに接続し、ターゲットとしてプライマリ・データベースに接続した後に行います。
Recovery Manager構成を設定するには、Recovery ManagerのCONFIGUREコマンドを使用します。CONFIGUREコマンドがFOR DB_UNIQUE_NAMEオプションを指定して使用されると、指定したDB_UNIQUE_NAMEのデータベースに対してRecovery Managerサイト固有の構成が設定されます。
たとえば、リカバリ・カタログへの接続後、次のコマンドをRecovery Managerプロンプトで使用して、DBIDが1625818158のBOSTONデータベースに対してデフォルト・デバイス・タイプをSBTに設定できます。Recovery ManagerのSET DBIDコマンドは、ターゲットとしてデータベースに接続していない場合にのみ必要です。
SET DBID 1625818158; CONFIGURE DEFAULT DEVICE TYPE TO SBT FOR DB_UNIQUE_NAME BOSTON;
この項では、次のRecovery Manager構成およびOracle Database構成について説明します。各構成によってバックアップ操作およびリカバリ操作を簡略化できます。
構成の前提
この項で説明する構成は、次の前提に基づいています。
スタンバイ・データベースはフィジカル・スタンバイ・データベースで、バックアップはスタンバイ・データベースでのみ作成されます。プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成する場合の手順の変更は、11.9.1項を参照してください。
1つのデータベース・サーバーで作成されたバックアップを別なデータベース・サーバーにリストアできるようにするには、RMANリカバリ・カタログが必要です。プライマリ・データベースはスタンバイ・データベースでバックアップが作成されたことを知らないので、RMANリポジトリとして制御ファイルだけを使用するのでは不十分です。
Recovery Managerのリカバリ・カタログは、バックアップ履歴および他のリカバリ関連のメタデータを一元化された場所に編成します。リカバリ・カタログは、データベース内に構成され、バックアップ・メタデータが格納されます。リカバリ・カタログには、制御ファイルに関する領域の制限がないため、バックアップに関する履歴データをより多く格納できます。
カタログ・サーバーは、プライマリ・サイトおよびスタンバイ・サイトと物理的に切り離されていますが、Data Guard構成内に置くことをお薦めします。これは、いずれのサイトで障害が発生しても最新のバックアップをリカバリする機能に影響しないためです。
|
関連項目: リカバリ・カタログの管理の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
構成内のすべてのデータベースには、Oracle Database 11gリリース1(11.1)を使用します。
Oracle Secure Backupソフトウェアまたはサード・パーティのメディア管理ソフトウェアは、バックアップをテープに取るようにRecovery Managerで構成します。
次のOracle Database構成は、Data Guard環境におけるすべてのプライマリ・データベースおよびスタンバイ・データベースで推奨されます。
データベースごとに高速リカバリ領域を構成する(リカバリ領域はデータベースに対してローカル)。
高速リカバリ領域は、ファイル・システムまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループ上にある、リカバリに必要なすべてのファイルが存在する唯一の格納場所です。これらのファイルには、制御ファイル、アーカイブ・ログ、オンラインREDOログ、フラッシュバック・ログおよびRecovery Managerバックアップがあります。新しいバックアップおよびアーカイブ・ログが高速リカバリ領域に作成されると、古いファイル(保存期間を超過しているまたは三次記憶域にバックアップされている)は自動的に削除され、新しいファイル用の領域が作成されます。さらに、高速リカバリ領域の領域使用量が事前に定義された制限に近づいている場合に、DBAにアラートを送信するように通知を設定できます。DBAは、リカバリ領域の領域制限を上げる、ディスク・ハードウェアを追加する、あるいは保存期間を短縮するなどの処置を取ることができます。
次の初期化パラメータを設定して、高速リカバリ領域を構成します。
DB_RECOVERY_FILE_DEST = <mount point or Oracle ASM Disk Group> DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>
|
関連項目: 高速リカバリ領域の構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
サーバー・パラメータ・ファイル(SPFILE)を使用して、インスタンス・パラメータがバックアップに保存されるようにバックアップを作成できるようにする。
プライマリ・データベースおよびスタンバイ・データベースでフラッシュバック・データベースを有効にする。
フラッシュバック・データベースを有効に設定すると、Oracle Databaseによってフラッシュバック・ログが高速リカバリ領域に保持されます。これらのログを使用すると、完全にリストアしなくても、前の時点までデータベースをロールバックできます。
|
関連項目: フラッシュバック・データベースの有効化に関する詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Recovery Managerの継続的な使用を簡略化するために、多くの永続的な構成設定をData Guard環境のデータベースごとに設定できます。これらの設定により、Recovery Managerの動作を多面的に制御します。たとえば、バックアップの保存ポリシー、デフォルトのバックアップ先(テープまたはディスク)、デフォルトのバックアップ・デバイス・タイプなどを構成できます。CONFIGUREコマンドを使用すると、Recovery Manager構成を設定および変更できます。次のRecovery Manager構成は、プライマリ・データベースにおいて推奨されます。
Recovery Managerをプライマリ・データベースおよびリカバリ・カタログに接続します。
データベースの保存ポリシーをn日間として構成します。
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <n> DAYS;
この構成により、任意の時点までのデータベース・リカバリの実行に必要なバックアップを指定した日数の間保存できます。
DELETE OBSOLETEコマンドを使用して、特定日数の間はリカバリを実行する必要がないバックアップ(設定されている保存方針に基づき)を削除します。
アーカイブ・ログを削除できる時期をCONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して指定します。たとえば、すべての宛先への送信を確認した後にログを削除する場合は、次の構成を使用します。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
すべてのスタンバイ宛先への適用を確認した後にログを削除する場合は、次の構成を使用します。
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
RESYNC CATALOG FROM DB_UNIQUE_NAMEコマンドの使用時に、RMANがリモートで接続して、再同期化を行えるように、プライマリ・データベースおよびすべてのスタンバイ・データベースの接続文字列を構成します。ターゲット・インスタンスに接続する際、ネット・サービス名を提供する必要があります。再同期化元の他のデータベースがローカル・ホストにある場合でも、この要件は適用されます。ターゲットおよびリモート・インスタンスは同じSYSDBAパスワードを使用する必要があります。したがって、両方のインスタンスにパスワード・ファイルがなければなりません。単一のパスワードでパスワード・ファイルを作成し、そのパスワード・ファイルですべてのデータベース・インスタンスを起動することができます。たとえば、ボストンにあるスタンバイへの接続用TNS別名がboston_conn_strの場合、次のコマンドを使用してBOSTONデータベース・サイトの接続識別子を構成することができます。
CONFIGURE DB_UNIQUE_NAME BOSTON CONNECT IDENTIFIER 'boston_conn_str';
'boston_conn_str'にはユーザー名とパスワードが含まれていない点に注意してください。任意のデータベース・サイトからBOSTONデータベース・サイトに接続するために使用できる、Oracle Netサービス名だけが含まれています。
すべてのスタンバイ・データベースについて接続識別子が構成されたら、LIST DB_UNIQUE_NAME OF DATABASEコマンドを使用してスタンバイのリストを確認できます。
|
関連項目:
|
次のRecovery Manager構成は、バックアップが実行されるスタンバイ・データベースで推奨されます。
Recovery Managerをターゲットとして(バックアップが実行される)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。
制御ファイルおよびサーバー・パラメータ・ファイルの自動バックアップを有効にします。
CONFIGURE CONTROLFILE AUTOBACKUP ON;
同じチェックポイントで有効なバックアップがすでに存在するデータファイルのバックアップをスキップします。
CONFIGURE BACKUP OPTIMIZATION ON;
メディア管理ソフトウェアによる要求に応じて、バックアップを作成するためのテープ・チャネルを構成します。
CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '<channel parameters>';
アーカイブ・ログを削除できる時期をCONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して指定します。
ログはスタンバイ・サイトでバックアップされるため、ログ削除ポリシーに対してBACKED UPオプションを構成することをお薦めします。
|
関連項目: アーカイブREDOログの削除方針の有効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
次のRecovery Manager構成は、バックアップが実行されないスタンバイ・データベースで推奨されます。
Recovery Managerをターゲットとしてスタンバイ・データベースに接続し、リカバリ・カタログに接続します。
スタンバイ・データベースで適用された後のアーカイブ・ログの自動削除を有効にします。
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
この項では、Data Guard構成内のOracle Databaseのバックアップに使用されるRecovery Managerスクリプトおよび手順について説明します。次の項目で構成されています。
|
注意: OracleのMaximum Availability Architecture(MAA)ベスト・プラクティスでは、プライマリ・データベースとスタンバイ・データベースの両方が停止した場合や、スイッチオーバーおよびフェイルオーバーについてサイトのプラクティスを新たに導入しなくてもよいようにする場合に、プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成してMTTRを短縮することをお薦めしています。 |
サーバー・パラメータ・ファイルのバックアップ
Oracle Database 11gまでは、サーバー・パラメータ・ファイル(SPFILE)のバックアップは、他のスタンバイ・データベースで使用できると想定されていました。しかし、実際には、すべてのスタンバイ・データベースで同じSPFILEを使用することは不可能です。この問題に対応するため、Recovery Managerでは、あるデータベース・サイトで作成されたSPFILEバックアップを別のデータベース・サイトで使用できないようにしています。この制約は、COMPATIBLE初期化パラメータが11.0.0に設定されている場合にのみ実施されます。
スタンバイ・データベースでは、SPFILEのバックアップを除いたすべてのバックアップ操作をある特定のスタンバイ・データベースにオフロードできます。しかし、COMPATIBLE初期化パラメータが11.0.0に設定されている場合、SPFILEをディスクにバックアップし、バックアップがテープに書き込まれるスタンバイ・サイトでは手動でカタログに追加できます。SPFILEバックアップ・セットに格納される追加メタデータにより、どのデータベースのSPFILEがどのバックアップ・セットに含まれるかRecovery Managerで識別できます。そのため、テープからリストアする際に、適切なSPFILEバックアップが選択されます。
スタンバイ・データベースの高速リカバリ領域は、テープ・バックアップ用のディスク・キャッシュとして機能できます。ディスクはバックアップ用の一次記憶域として使用され、テープは長期間のアーカイブ記憶域となります。テープの増分バックアップは毎日、テープの全体バックアップは毎週作成されます。これらのバックアップの実行に使用されるコマンドは、次の各項を参照してください。
バックアップ計画を決定する際に、日次増分バックアップを利用することをお薦めします。データファイル・イメージ・コピーは、最新の増分バックアップを使用してロールフォワードできるため、常に最新のデータファイル・イメージ・コピーを提供できます。Recovery Managerでは、そのシステム変更番号(SCN)で取得された全体イメージ・コピーを使用するように、結果のイメージ・コピーをメディア・リカバリに使用するため、データベースの全体イメージ・コピーを毎日実行するオーバーヘッドはありません。もう1つのメリットは、イメージ・コピーが最新のブロック変更で更新され、現在の状態にデータベースを戻すのに必要なREDOログが少なくなるため、リカバリ時間が短縮されることです。
日次増分バックアップを実施するには、1日目にデータベースの全体バックアップを作成し、2日目に増分バックアップを作成します。アーカイブREDOログを使用すると、いずれの日のどの時点についてもデータベースをリカバリできます。3日目以降は、前日の増分バックアップをデータファイル・コピーとマージし、当日の増分バックアップを作成して、最終日までのどの時点についても高速リカバリを可能にします。REDOログを使用すると、当日のどの時点についてもデータベースをリカバリできます。
日次バックアップを実行するスクリプトは次のとおりです(最終行DELETE ARCHIVELOG ALLは、高速リカバリ領域をログの格納に使用しない場合にのみ必要です)。
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL; RECOVER COPY OF DATABASE WITH TAG 'OSS'; BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE; BACKUP DEVICE TYPE SBT ARCHIVELOG ALL; BACKUP BACKUPSET ALL; DELETE ARCHIVELOG ALL;
スタンバイ制御ファイルは、制御ファイルの自動バックアップが有効に設定されているため、バックアップ操作の最後に自動的にバックアップされます。
次に、スクリプトの各コマンドの動作について説明します。
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL
Data Guard設定で、リカバリ・カタログが把握しているその他すべてのデータベース・サイト(プライマリおよびその他のスタンバイ・データベース)からの情報を再同期化します。RESYNC CATALOG FROM DB_UNIQUE_NAMEが機能するためには、Oracle Netサービス名を使用してRMANをターゲットに接続し、すべてのデータベースで同じパスワード・ファイルを使用する必要があります。
RECOVER COPY OF DATABASE WITH TAG 'OSS'
前日に取得したレベル1の増分バックアップを適用して、データベースのレベル0のコピーをロールフォワードします。この例のスクリプトでは、前日のレベル1の増分にはOSSタグが付けられています。その増分は、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。このコマンドが実行された1日目には、レベル1の増分がまだないため、ロールフォワードはありません。レベル0の増分が、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。2日目にも、レベル0の増分しかないため、ロールフォワードはありません。OSSタグが付けられたレベル1の増分が、BACKUP DEVICE TYPE DISK ... DATABASEコマンドによって生成されます。3日目以降には、前日に作成されたOSSタグ付きのレベル1の増分を使用して、ロールフォワードが実行されます。
BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'OSS' DATABASE
新しいレベル1の増分バックアップを作成します。このコマンドが実行された1日目は、レベル0の増分となります。2日目以降は、レベル1の増分となります。
BACKUP DEVICE TYPE SBT ARCHIVELOG ALL
所定の削除ポリシーに従って、アーカイブ・ログをテープにバックアップします。
BACKUP BACKUPSET ALL
増分バックアップの作成結果として作成されるバックアップ・セットをバックアップします。
DELETE ARCHIVELOG ALL
CONFIGURE ARCHIVELOG DELETION POLICYコマンドで設定されたログ削除ポリシーに従って、アーカイブ・ログを削除します。アーカイブ・ログが高速リカバリ領域にある場合は、空きディスク領域がさらに必要になると自動的に削除されます。そのため、毎日ログを明示的に削除する場合にのみ、このコマンドを使用する必要があります。
OracleのMedia Management Layer(MML)APIにより、サード・パーティ・ベンダーは、メディア・マネージャ、Recovery Managerと連動して機能するソフトウェア、テープ・ドライブなどの順次メディア・デバイスへのバックアップを可能にするベンダーのハードウェアを構築できます。メディア・マネージャは、テープなどの順次メディアのロード、アンロードおよびラベル付けを処理します。Recovery Managerを順次メディア・デバイスとともに使用するには、Oracle Secure Backupまたはサード・パーティのメディア管理ソフトウェアをインストールする必要があります。
デフォルトでは、次の手順を実行してテープへの直接バックアップを実行します。
Recovery Managerを(ターゲット・データベースとして)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。
次のように、CONFIGUREコマンドを実行します。
CONFIGURE DEFAULT DEVICE TYPE TO SBT;
この例では、スタンバイ・データベースで全体バックアップが毎週、増分バックアップが毎日作成されます。
|
関連項目: メディア・マネージャ用のRMANの構成方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
次の手順を実行して、テープに日次バックアップを直接実行します。
RMANをスタンバイ・データベース(ターゲット・データベースとして)、およびリカバリ・マネージャに接続します。
次のRecovery Managerコマンドを実行します。
RESYNC CATALOG FROM DB_UNIQUE_NAME ALL; BACKUP AS BACKUPSET INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG; DELETE ARCHIVELOG ALL;
これらのコマンドは、Data Guard環境内のその他すべてのデータベースの情報を再同期化します。また、すべてのアーカイブ・ログを含むデータベースのレベル1の増分バックアップを作成します。このスクリプトが実行された1日目に、レベル0のバックアップが検出されなければ、レベル0のバックアップが作成されます。
DELETE ARCHIVELOG ALLコマンドは、すべてのアーカイブ・ログ・ファイルが高速リカバリ領域にない場合にのみ必要です。
週1日、次の手順を実行してテープに週次バックアップを直接実行します。
Recovery Managerを(ターゲット・データベースとして)スタンバイ・データベースに接続し、リカバリ・カタログに接続します。
次のRecovery Managerコマンドを実行します。
BACKUP AS BACKUPSET INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG; DELETE ARCHIVELOG ALL;
これらのコマンドは、Data Guard環境内のその他すべてのデータベースの情報を再同期化し、すべてのアーカイブ・ログを含むレベル0のデータベース・バックアップを作成します。
DELETE ARCHIVELOG ALLコマンドは、すべてのアーカイブ・ログ・ファイルが高速リカバリ領域にない場合にのみ必要です。
REGISTER DATABASEコマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、Recovery Managerをリカバリ・カタログに接続し、TARGETとしてプライマリ・データベースに接続した後に行います。
新しいスタンバイは、スタンバイ・データベースに接続するか、またはCONFIGURE DB_UNIQUE_NAMEコマンドを使用して接続識別子を構成すると、リカバリ・カタログに自動的に登録されます。
特定のスタンバイ・データベースに関する情報を登録解除するには、UNREGISTER DB_UNIQUE_NAMEコマンドを使用できます。スタンバイ・データベースをData Guard環境から完全に削除すると、同じData Guard環境内の別のデータベースに接続した後に、リカバリ・カタログのデータベース情報も削除できます。登録解除されたデータベースと関連付けられたバックアップは、そのまま他のデータベースで使用できます。これらのバックアップは、CHANGE BACKUP RESET DB_UNIQUE_NAMEコマンドを使用して既存の他のデータベースに関連付けることができます。
INCLUDING BACKUPSオプションを指定してUNREGISTER DB_UNIQUE_NAMEコマンドを使用すると、削除されるデータベースに関連付けられたすべてのバックアップ・ファイルのメタデータもリカバリ・カタログから削除されます。
FOR DB_UNIQUE_NAME句を指定してRecovery ManagerのLIST、REPORTおよびSHOWの各コマンドを使用すると、特定のデータベースに関する情報を表示できます。
たとえば、リカバリ・カタログに接続した後、次のコマンドを使用してDBIDが1625818158のデータベースに関する情報を表示し、Data Guard環境内のデータベースを出力できます。SET DBIDコマンドは、TARGETとしてデータベースに接続していない場合にのみ必要です。最後の3つのコマンドは、DB_UNIQUE_NAMEがBOSTONのデータベースについて、アーカイブ・ログ、データベース・ファイル名およびRecovery Managerの構成情報を出力します。
SET DBID 1625818158; LIST DB_UNIQUE_NAME OF DATABASE; LIST ARCHIVELOG ALL FOR DB_UNIQUE_NAME BOSTON; REPORT SCHEMA FOR DB_UNIQUE_NAME BOSTON; SHOW ALL FOR DB_UNIQUE_NAME BOSTON;
Data Guard環境のファイル(データファイル、アーカイブ・ログ、バックアップ・ピース、イメージ・コピー、プロキシ・コピー)は、DB_UNIQUE_NAMEパラメータを使用してデータベースに関連付けられます。そのため、Data Guard環境のデータベースごとに、DB_UNIQUE_NAMEに指定された値は一意であることが重要です。この情報は、ファイル共有属性とともに、Recovery Managerの様々な操作の際にアクセスできるファイルを判別するのに使用されます。
ファイル共有属性は、ディスク上のファイルは関連付けられたデータベースでのみアクセス可能で、テープ上のすべてのファイルはすべてのデータベースでアクセス可能に設定されています。BACKUPおよびRESTOREなどのRMANコマンド、およびその他のメンテナンス・コマンドは、この想定で機能しています。たとえば、データベースでのイメージ・コピーのロールフォワード操作中は、そのデータベースに関連付けられたイメージ・コピーだけがロールフォワードされます。同様に、ディスクとテープのすべての増分バックアップを使用して、イメージ・コピーのロールフォワードを行います。また、リカバリ操作中は、データベースに関付けられたディスク・バックアップとテープ上のファイルだけがバックアップ元と見なされます。
|
関連項目: RMANコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
様々なオペランドを指定してRecovery ManagerのCHANGEコマンドを使用すると、リカバリ・カタログのメタデータを変更できます。詳細は、次の各項を参照してください。
スタンバイ・データベース間でのファイルの関連付けの変更
RESET DB_UNIQUE_NAMEオプションを指定してCHANGEコマンドを使用すると、Data Guard環境内のあるデータベースから別のデータベースにファイルの関連付けを変更できます。CHANGEコマンドは、ディスク・バックアップまたはアーカイブ・ログをあるデータベースから別のデータベースに転送し、転送先のデータベースでそれらのファイルを使用するときに役立ちます。また、CHANGEコマンドは、FOR DB_UNIQUE_NAMEオプションとRESET DB_UNIQUE_NAME TOオプションを使用すると、いずれのデータベースに直接接続しなくてもデータベース間でファイルの関連付けを変更できます。
データベースのDB_UNIQUE_NAMEの変更
データベースのDB_UNIQUE_NAME初期化パラメータの値を変更すると、Data Guard環境でも同じ変更を行う必要があります。そのデータベース・インスタンスへの接続後、Recovery Managerのリカバリ・カタログはDB_UNIQUE_NAMEの新旧両方の値を認識します。リカバリ・カタログ・スキーマ内で新旧の値に関する情報をマージするには、Recovery ManagerのCHANGE DB_UNIQUE_NAMEコマンドを使用する必要があります。Recovery Managerが変更後のDB_UNIQUE_NAMEパラメータでインスタンスに接続されない場合は、CHANGE DB_UNIQUE_NAMEコマンドを使用してリカバリ・カタログ・スキーマのDB_UNIQUE_NAMEの名前を変更することもできます。たとえば、データベースのインスタンス・パラメータ値がBOSTON_AからBOSTON_Bに変更された場合、ターゲット・データベースおよびリカバリ・カタログに接続した後に、Recovery Managerのプロンプトで次のコマンドを実行する必要があります。
CHANGE DB_UNIQUE_NAME FROM BOSTON_A TO BOSTON_B;
バックアップの使用不可化またはメタデータの削除
AVAILABLE、UNAVAILABLE、KEEP、UNCATALOGなどのオプションを指定してCHANGEコマンドを使用すると、バックアップをリストアおよびリカバリの目的で使用可能または使用不可能にしたり、そのメタデータを保存または削除することができます。
|
関連項目: RMANのCHANGEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
DELETEコマンドを使用して、バックアップ・セット、イメージ・コピー、アーカイブ・ログ、プロキシ・コピーを削除します。特定のデータベースに関連付けられているファイルのみを削除するには、FOR DB_UNIQUE_NAMEオプションをDELETEコマンドとともに使用する必要があります。
ファイルのメタデータは、現行のターゲット・データベースに関連付けられ、正常に削除されたすべてのファイル(またはどの既知のデータベースにも関連付けられていないファイル)について削除されます。ファイルが正常に削除できなかった場合は、FORCEオプションを使用してファイルのメタデータを削除します。
別のデータベースに関連付けられているファイルが正常に削除された場合、リカバリ・カタログのそのメタデータも削除されます。他のデータベースに関連付けられているファイルおよび正常に削除できなかったファイルは、DELETEコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはデータベースごとにグループ化されます)。FORCEオプションを使用して、この動作を上書きすることはできません。削除不可のファイルのメタデータを削除しても問題ないことが明確である場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、FORCEオプションを指定してDELETEコマンドを使用し、ファイルのメタデータを削除します。
|
関連項目: RMANのDELETEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
CROSSCHECKコマンドを使用してリカバリ・カタログ・スキーマのファイル・ステータスを検証および更新します。特定のデータベースに関連付けられたファイルを検証するには、FOR DB_UNIQUE_NAMEオプションをCROSSCHECKコマンドとともに使用します。
現行のターゲット・データベースに関連付けられたすべてのファイル(またはどのデータベースにも関連付けられていないあらゆるファイル)のメタデータは、CROSSCHECK操作の結果に応じてAVAILABLEまたはEXPIREDのマークが付けられます。
別のデータベースに関連付けられているファイルが正常に検査された場合、リカバリ・カタログのそのメタデータもAVAILABLEに変更されます。他のデータベースに関連付けられているファイルおよび正常に検査できなかったファイルは、CROSSCHECKコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはサイトごとにグループ化されます)。確認し、それでも使用不可のファイルのステータス・メタデータを変更する場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、CROSSCHECKコマンドを実行してステータス・メタデータをEXPIREDに更新します。
|
関連項目: RMANのCROSSCHECKコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
次の各項の例では、バックアップを作成したのと同じシステムにテープからファイルをリストアすると仮定しています。ファイルを異なるシステムにリストアする必要がある場合は、そのシステムに対してチャネルを構成してから、リストア・コマンドおよびリカバリ・コマンドを実行する必要があります。存在しないデータベースの構成を設定するには、SET DBIDコマンドおよびFOR DB_UNIQUE_NAMEを指定したCONFIGUREコマンドを使用します。異なるシステムからRecovery Managerバックアップにアクセスする方法の詳細は、メディア管理のドキュメントを参照してください。
この項では、次の使用例について説明します。
プライマリ・データベースのデータファイル消失からは、バックアップを使用するか、スタンバイ・データベースのファイルを使用してリカバリできます。詳細は、次の各項を参照してください。
バックアップの使用
次のRecovery Managerコマンドを発行して、データファイルをリストアおよびリカバリします。プライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があります。
RESTORE DATAFILE n,m...; RECOVER DATAFILE n,m...;
次のRecovery Managerコマンドを発行して、表領域をリストアおよびリカバリします。プライマリ・データベースとリカバリ・カタログ・データベースの両方に接続する必要があります。
RESTORE TABLESPACE tbs_name1, tbs_name2, ... RECOVER TABLESPACE tbs_name1, tbs_name2, ...
スタンバイ・データベースのファイルの使用
Oracle 11g現在、スタンバイ・データベースのファイルを使用して消失したファイルをリカバリできます。これは、スタンバイが最新の状態で、ネットワーク接続がスタンバイとプライマリ間のファイル・コピーをサポートするのに十分足りる場合に有効に機能します。
Recovery Managerを起動し、次の手順を実行してスタンバイからプライマリにデータファイルをコピーします。
ターゲット・データベースとしてスタンバイ・データベースに接続します。
CONNECT TARGET sys@standby
パスワードの入力を求められます。
target database Password: password
補助データベースとしてプライマリ・データベースに接続します。
CONNECT AUXILIARY sys@primary
パスワードの入力を求められます。
target database Password: password
ネットワークを介してスタンバイ・ホストのデータファイルをプライマリ・ホスト上の場所にバックアップします。たとえば、/disk1/df2.dbfがスタンバイ・ホストのデータファイル2の名前だとします。/disk8/datafile2.dbfがプライマリ・ホストのデータファイル2の名前だとします。次のコマンドは、ネットワークを介してデータファイル2を/disk9/df2copy.dbfにコピーします。
BACKUP AS COPY DATAFILE 2 AUXILIARY FORMAT '/disk9/df2copy.dbf';
次のようにして、Recovery Managerクライアントを終了します。
EXIT;
Recovery Managerを起動し、ターゲットとしてプライマリ・データベースに接続し、リカバリ・カタログに接続します。
CONNECT TARGET sys@primary; target database Password: password CONNECT CATALOG rman@catdb; recovery catalog database Password: password
CATALOG DATAFILECOPYコマンドを使用して、Recovery Managerで使用できるようにこのデータファイル・コピーをカタログに追加します。
CATALOG DATAFILECOPY '/disk9/df2copy.dbf';
次に、SWITCH DATAFILEコマンドを使用してデータファイル・コピーを切り替え、/disk9/df2copy.dbfが現行のデータファイルになるようにします。
RUN {
SET NEWNAME FOR DATAFILE 2 TO '/disk9/df2copy.dbf';
SWITCH DATAFILE 2;
}
1つ以上のデータファイルが消失した後にスタンバイ・データベースをリカバリするには、Recovery ManagerのRESTORE DATAFILEコマンドを使用して、消失したファイルをバックアップからスタンバイ・データベースにリストアする必要があります。破損ファイルのリカバリに必要なアーカイブREDOログ・ファイルすべてにスタンバイ・データベースがディスク上でアクセス可能な場合は、REDO Applyを再開します。
リカバリに必要なアーカイブREDOログ・ファイルにディスク上でアクセスできない場合は、次の手順に従ってRecovery Managerを使用し、リストアしたデータファイルをスタンバイ・データベースに最後に適用されたログよりも大きいSCN/ログ順序番号までリカバリし、REDO Applyを再開してREDOデータの適用を続行します。
SQL*Plusをスタンバイ・データベースに接続します。
SQL ALTER DATABASE ...文を使用して、REDO Applyを停止します。
別の端末で、Recovery Managerを起動し、スタンバイ・データベースとリカバリ・カタログ・データベースの両方に接続します(スタンバイ・インスタンスへの接続にはTARGETキーワードを使用します)。
次のRecovery Managerコマンドを発行して、スタンバイ・データベースでデータファイルをリストアおよびリカバリします。
RESTORE DATAFILE <n,m,...>; RECOVER DATABASE;
表領域をリストアするには、Recovery Managerの'RESTORE TABLESPACE tbs_name1, tbs_name2, ...'コマンドを使用します。
SQL*PlusのプロンプトでSQL ALTER DATABASE ...文を使用して、REDO Applyを再開します。
Oracleソフトウェアでは、スタンバイ制御ファイルを多重化できます。スタンバイ制御ファイルが多重化されているかどうかを確認するには、次のようにCONTROL_FILES初期化パラメータを調べます。
SQL> SHOW PARAMETER CONTROL_FILES; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_files string <cfilepath1>,<cfilepath2>
多重スタンバイ制御ファイルの1つが消失しているかアクセスできないと、Oracleソフトウェアはインスタンスを停止し、アラート・ログに次のメッセージを書き込みます。
ORA-00210: cannot open the specified controlfile ORA-00202: controlfile: '/disk1/oracle/dbs/scf3_2.f' ORA-27041: unable to open file
制御ファイルの元のコピーを消失したコピーに上書きコピーし、次のSQL文を使用してスタンバイ・インスタンスを再起動できます。
SQL> STARTUP MOUNT; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
RESTORE CONTROLFILEコマンドに続いてRECOVER DATABASEコマンドを実行すると、バックアップから制御ファイルをリストアできます。RECOVER DATABASEコマンドは、制御ファイル内のファイル名をそのデータベースに存在するファイルと一致するように自動的に修正し、データベースで最後に受信したログ順序番号までデータベースをリカバリします。
他の方法として、プライマリ・データベースから新しい制御ファイルを作成し、すべての多重化位置にコピーしてデータファイル名を手動で変更し、ディスク上に存在するファイルと一致させます。
Oracleソフトウェアでは、プライマリ・データベースの制御ファイルを多重化できます。プライマリ・データベースで制御ファイルの1つを更新できない場合は、プライマリ・データベース・インスタンスが自動的に停止します。
RESTORE CONTROLFILEコマンドに続いてRECOVER DATABASEコマンドを実行すると、バックアップから制御ファイルをリストアできます。RECOVER DATABASEコマンドは、制御ファイル内のファイル名をそのデータベースに存在するファイルと一致するように自動的に修正し、データベースをリカバリします。
もう1つの方法として、CREATE CONTROLFILE SQLコマンドを使用して新しい制御ファイルを作成することができます。すべてのデータファイルとオンライン・ログが残っている場合は、制御ファイルを再作成することができます。
|
関連項目: 失われた制御ファイルのRMANを使用したリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
オンラインREDOログ・ファイルは多重化することをお薦めします。オンラインREDOログ・グループのメンバーがすべて消失すると、Oracleソフトウェアはインスタンスを終了します。書込みできないのがログ・ファイル・グループの一部のメンバーのみの場合、そのメンバーはアクセス可能になるまで使用されません。V$LOGFILEおよびV$LOGビューには、プライマリ・データベース・インスタンスのログ・ファイル・メンバーの現行のステータスに関する詳細情報が含まれます。
OracleソフトウェアがオンラインREDOログ・ファイルのメンバーの1つに書込みできない場合は、次のアラート・メッセージが戻されます。
ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: '/disk1/oracle/dbs/t1_log1.f' ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3
アクセスの問題がハードウェア・エラーによる一時的なものの場合は、問題を解決すると処理が自動的に続行されます。消失が永続的な場合は、新規メンバーを追加して古いメンバーをグループから削除できます。
REDOログ・グループに新規メンバーを追加するには、次の文を発行します。
SQL> ALTER DATABASE ADD LOGFILE MEMBER 'log_file_name' REUSE TO GROUP n;
この文は、データベースがオープン状態の場合にも、データベースの可用性に影響を与えずに発行できます。
アーカイブ済の非アクティブ・グループのメンバーがすべて消失した場合は、そのグループを削除して再作成できます。
他のすべての場合(現行のACTIVEグループまたはアーカイブされていない非アクティブ・グループのオンライン・ログ・メンバーすべてが消失した場合)は、スタンバイ・データベースにフェイルオーバーする必要があります。フェイルオーバー手順の詳細は第8章を参照してください。
プライマリ・データベースの不完全リカバリを実行するのは、通常、データベースが論理的に(ユーザーまたはアプリケーションが原因で)破損した場合や、表領域またはデータファイルがデータベースから意図せずに削除された場合などです。
スタンバイ・データベース・インスタンス上の現在のデータベース・チェックポイントSCNに応じて、次のいずれかの手順でプライマリ・データベースの不完全リカバリを実行できます。すべての手順は、最も所要時間が短いものから優先順位順になっています。
フラッシュバック・データベースの使用 フラッシュバック・データベースの使用は、プライマリ・データベースでフラッシュバック・データベース機能が使用可能で、データベース・ファイルが1つも消失しておらず、Point-in-Timeリカバリが最も古いフラッシュバックSCNより大きいか、最も早いフラッシュバック時間よりも後の場合の推奨手順です。フラッシュバック・データベースを使用してPoint-in-Timeリカバリを実行する手順の詳細は、13.3項を参照してください。
スタンバイ・データベース・インスタンスの使用 これは、スタンバイ・データベースが必要な不完全リカバリ時間より後のもので、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用可能でない場合の推奨手順です。
スタンバイ・データベースを必要な時点までリカバリします。
RECOVER DATABASE UNTIL TIME 'time';
あるいは、SCNまたはログ順序番号を使用して不完全リカバリ時間を指定できます。
RECOVER DATABASE UNTIL SCN incomplete recovery SCN'; RECOVER DATABASE UNTIL LOGSEQ incomplete recovery log sequence number THREAD thread number;
スタンバイ・データベースを読取り専用モードでオープンし、データベースの状態を確認します。
必要な状態になっていない場合は、LogMinerユーティリティを使用してアーカイブREDOログ・ファイルを調べ、不完全リカバリに適切なターゲット時刻またはSCNを確認します。または、ターゲット時刻より前の判明している時点までスタンバイ・データベースをリカバリしてから、データベースを読取り専用モードでオープンし、データの状態を検査することもできます。データベースの状態が正常であると確認されるまで、このプロセスを繰り返します。データベースのリカバリ終了時点が遅すぎると(つまり、エラーが発生したSCNより後までリカバリすると)、それより前のSCNに戻せないことに注意してください。
SQL ALTER DATABASE ACTIVATE STANDBY DATABASE文を使用してスタンバイ・データベースをアクティブ化します。これにより、スタンバイ・データベースがプライマリ・データベースに変換されて、新しいリセットログ・ブランチが作成され、データベースがオープンします。新規リセットログ・ブランチへのスタンバイ・データベースの対応の詳細は、9.4項を参照してください。
プライマリ・データベース・インスタンスの使用 すべてのスタンバイ・データベース・インスタンスがすでに必要な時点より後までリカバリされており、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用できない場合は、この方法で操作する必要があります。
次の手順に従ってプライマリ・データベースで不完全リカバリを実行します。
LogMinerまたは他の手段を使用して、データベースのすべてのデータが正常と判明している時点またはSCNを識別します。
その時点またはSCNを使用して次のRecovery Managerコマンドを発行し、不完全データベース・リカバリを実行し、RESETLOGSオプションを使用して(カタログ・データベースとMOUNT状態のプライマリ・インスタンスに接続した後で)データベースをオープンします。
RUN
{
SET UNTIL TIME 'time';
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;
この処理の後に、Data Guard構成内ですべてのスタンバイ・データベース・インスタンスを再確立する必要があります。
次の各項では、スタンバイ・データベースとプライマリ・データベースでバックアップ・ファイルを共有できない場合、REDOログ・ファイルのリモート・アーカイブにスタンバイ・インスタンスのみが使用される場合、またはスタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合など、その他の構成にあわせてバックアップ処理を変更する方法について説明します。
スタンバイ・データベース間の距離が離れている場合、プライマリ・システムや他のスタンバイ・システムからは、これらの上で作成されたバックアップに簡単にアクセスできません。すべてのシステム上でデータベースの完全バックアップを実行して、リカバリ操作を実行します。高速リカバリ領域は、プライマリおよびスタンバイ・システム上にローカルに置くことができます(つまり、プライマリ・データベースとスタンバイ・データベースで高速リカバリ領域が同一である必要がありません)。
この使用例でも、11.8項で説明した一般的な対策を使用できますが、次の例外があります。
Recovery Managerで作成されるバックアップ・ファイルには、タグとしてローカル・システム名を指定し、そのタグをRESTORE操作で使用して、Recovery Managerによる同じホスト上で作成されたバックアップの選択を制限する必要があります。つまり、バックアップの作成時に、BACKUPコマンドではTAG system nameオプションを、RESTOREコマンドではFROM TAG system nameオプションを、RECOVERコマンドではFROM TAG system name ARCHIVELOG TAG system nameオプションをそれぞれ使用する必要があります。
スタンバイ・サイトの障害時リカバリを実行する手順は、次のとおりです。
スタンバイの操作に使用されていたのと同じパラメータ・ファイルを使用して、スタンバイ・インスタンスをNOMOUNT状態で起動します。
プライマリ・インスタンスで、SQL ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename文を使用してスタンバイ制御ファイルを作成し、作成された制御ファイルを使用してスタンバイ・インスタンスをマウントします。
次のRecovery Managerコマンドを発行し、データベース・ファイルをリストアおよびリカバリします。
RESTORE DATABASE FROM TAG 'system name'; RECOVER DATABASE FROM TAG 'system name' ARCHIVELOG TAG 'system name';
REDO Applyを再開します。
スタンバイ・インスタンスにより残りのアーカイブREDOログ・ファイルがフェッチされます。
11.4項で説明した手順を使用しますが、データベース・ファイルをバックアップするRecovery ManagerコマンドはFALサーバーに対して実行できません。FALサーバーは、すべてのアーカイブREDOログ・ファイルのバックアップ・ソースとして使用できるため、アーカイブREDOログ・ファイルのバックアップをFALサーバーにオフロードします。
|
注意: Oracle Database 11g現在、リカバリ・カタログは各スタンバイ・データベース・サイトのファイル名を再同期化できます。しかし、スタンバイ・データベースのファイル名がなんらかの理由でまったく再同期化されていなかった場合は、この項で説明する手順に従って再同期化することが可能です。 |
まったく再同期化されていなかったプライマリ・データベースとスタンバイ・データベースでデータベース・ファイル名が異なる場合は、使用するRESTOREおよびRECOVERコマンドが若干異なります。スタンバイ・データベースで実際のデータファイル名を取得するには、V$DATAFILEビューを問い合せ、データベースのすべてのデータファイルに対してSET NEWNAMEオプションを指定します。
RUN
{
SET NEWNAME FOR DATAFILE 1 TO 'existing file location for file#1 from V$DATAFILE';
SET NEWNAME FOR DATAFILE 2 TO 'existing file location for file#2 from V$DATAFILE';
…
…
SET NEWNAME FOR DATAFILE n TO 'existing file location for file#n from V$DATAFILE';
RESTORE {DATAFILE <n,m,…> | TABLESPACE tbs_name_1, 2, …| DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE {NOREDO};
}
同様に、Recovery ManagerのDUPLICATEコマンドでもSET NEWNAMEオプションを使用し、スタンバイ・データベースの作成中に新規ファイル名を指定する必要があります。あるいは、LOG_FILE_NAME_CONVERTおよびDB_FILE_NAME_CONVERTパラメータを設定できます。
|
関連項目: DB_FILE_NAME_CONVERTおよびDB_CREATE_FILE_DESTパラメータの両方がスタンバイに設定されている場合の優先ルールの詳細は、13.5項「OMFまたはOracle ASMを使用するスタンバイ・データベースの作成」を参照してください。 |
Recovery Managerの増分バックアップを使用して、フィジカル・スタンバイ・データベースをプライマリ・データベースと同期化できる場合があります。Recovery ManagerのBACKUP INCREMENTAL FROM SCNコマンドを使用すると、プライマリ・データベースでスタンバイの現行SCNから始まるバックアップを作成し、それを使用してスタンバイ・データベースをロールフォワードできます。
この項で説明する手順は、フィジカル・スタンバイ・データベースが次のいずれかに該当するため、Recovery Managerの増分バックアップが役立つ状況に適用します。
プライマリ・データベースから大幅に遅れている
広範囲にロギングなしの変更がある
データファイルのサブセットにロギングなしの変更がある
|
注意: この操作の実行時にはリカバリ・カタログの使用をお薦めします。これらの手順は、リカバリ・カタログがなくても可能ですが、リストアされた制御ファイルのファイル名を慎重に修正する必要があります。 |
|
関連項目: RMANの増分バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
特に記載していないかぎり、次の手順は前述の3つの状況すべてに適用されます。
スタンバイ・データベースでREDO Applyを停止します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
スタンバイ・データベースで、増分バックアップのFROM SCNを計算します。この計算は、状況によって異なります。
プライマリ・データベースから大幅に遅れているスタンバイでは、V$DATABASEビューを問い合せてスタンバイ・データベースの現行SCNを記録します。
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
CURRENT_SCN
-----------
233995
広範囲にロギングなしの変更があるスタンバイでは、V$DATAFILEビューを問い合せて最小のFIRST_NONLOGGED_SCNを記録します。
SQL> SELECT MIN(FIRST_NONLOGGED_SCN) FROM V$DATAFILE -
> WHERE FIRST_NONLOGGED_SCN>0;
MIN(FIRST_NONLOGGED_SCN)
------------------------
223948
データファイルのサブセットにロギングなしの変更があるスタンバイでは、次のようにV$DATAFILEビューを問い合せます。
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE -
> WHERE FIRST_NONLOGGED_SCN > 0;
FILE# FIRST_NONLOGGED_SCN
---------- -------------------
4 225979
5 230184
RMANターゲットとしてプライマリ・データベースに接続し、手順2で記録したスタンバイ・データベースの現行SCN(プライマリから大幅に遅れているスタンバイの場合)または最小のFIRST_NONLOGGED_SCN(広範囲にロギングなしの変更があるスタンバイの場合)から増分バックアップを作成します。
RMAN> BACKUP INCREMENTAL FROM SCN 233995 DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FORSTANDBY';
スタンバイのデータファイルのサブセットにログの変更がない場合、次のように、FIRST_NONLOGGED_SCN列(手順2で記録された)にリストされた各データファイル用に増分バックアップを作成します。
RMAN> BACKUP INCREMENTAL FROM SCN 225979 DATAFILE 4 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY'; RMAN> BACKUP INCREMENTAL FROM SCN 230184 DATAFILE 5 FORMAT '/tmp/ForStandby_%U' TAG 'FORSTANDBY';
このBACKUPコマンドは。データファイルのバックアップ、および手順7で使用する制御ファイルのバックアップを生成します。
バックアップ・ピースが共有記憶域にない場合は、プライマリで作成されたすべてのバックアップ・ピースをスタンバイに転送します。
scp /tmp/ForStandby_* standby:/tmp
前の手順でバックアップ・ピースをコピーする必要があった場合、またはプロセス全体のリカバリ・カタログに接続されていない場合、新しいバックアップ・ピースをスタンバイのカタログに追加する必要があります(それ以外の場合は次の手順に進みます)。
RMAN> CATALOG START WITH '/tmp/ForStandby';
Recovery Managerターゲットとしてスタンバイ・データベースに接続し、REPORT SCHEMA文を実行してスタンバイ・データベース・サイトが自動的に登録され、スタンバイ・サイトにファイル名が表示されることを確認します。
RMAN> REPORT SCHEMA;
RMANターゲットとしてスタンバイ・データベースに接続し、次のコマンドを実行して増分バックアップを適用します。RESTORE STANDBY CONTROLFILE FROM TAGコマンドは、プロセス全体のリカバリ・カタログに接続されている場合にのみ機能するという点に注意してください。それ以外の場合は、RESTORE STANDBY CONTROLFILE FROM '<control file backup filename>'コマンドを使用します。
RMAN> STARTUP FORCE NOMOUNT; RMAN> RESTORE STANDBY CONTROLFILE FROM TAG 'FORSTANDBY'; RMAN> ALTER DATABASE MOUNT; RMAN> RECOVER DATABASE NOREDO;
|
注意: リカバリ・カタログを使用する場合、RMANRECOVERコマンドによってスタンバイ制御ファイル内のデータファイルのパス名が修正されます。リカバリ・カタログを使用しない場合はスタンバイ制御ファイル内のファイル名を手動で編集する必要があります。またはRMAN SET NEWNAMEコマンドを使用してデータファイル名を割り当てます。RMANのRECOVERおよびSET NEWNAMEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
広範囲にロギングなしの変更があるスタンバイまたはデータファイルのサブセットにロギングなしの変更があるスタンバイで、V$DATAFILEビューを問い合せ、ロギングなしの変更が含まれるデータファイルがないことを確認します。次の問合せでは0(ゼロ)行が戻されます。
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE - > WHERE FIRST_NONLOGGED_SCN > 0;
|
注意: 増分バックアップは7日で不要になります。あるいは、この時点でRecovery ManagerのDELETEコマンドを使用して削除できます。 |
フィジカル・スタンバイ・データベースでREDO Applyを開始します。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE - > USING CURRENT LOGFILE DISCONNECT FROM SESSION;
