11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
この章では、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環境では、リカバリ・カタログは、ディスク・バックアップは関連付けられたデータベースでのみアクセス可能であるとみなします。これに対して、あるデータベースで作成されたテープ・バックアップは、すべてのデータベースでアクセス可能です。バックアップ・ファイルがデータベースに関連付けられていない場合は、リカバリ・カタログ・ビューでそれを示す行のSITE_KEY列にnullと表示されます。デフォルトでは、SITE_KEYがnullのファイルは、Recovery Managerによってターゲット・データベースに関連付けられます。
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で作成したテープ・バックアップをリストア対象とみなします。
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構成について説明します。各構成によってバックアップ操作およびリカバリ操作を簡略化できます。
この項で説明する構成は、次の前提に基づいています。
Recovery Managerのリカバリ・カタログは、バックアップ履歴および他のリカバリ関連のメタデータを一元化された場所に編成します。リカバリ・カタログは、データベース内に構成され、バックアップ・メタデータが格納されます。リカバリ・カタログには、制御ファイルに関する領域の制限がないため、バックアップに関する履歴データをより多く格納できます。
カタログ・サーバーは、プライマリ・サイトおよびスタンバイ・サイトと物理的に切り離されていますが、Data Guard構成内に置くことをお薦めします。これは、いずれのサイトで障害が発生しても最新のバックアップをリカバリする機能に影響しないためです。
次のOracle Database構成は、Data Guard環境におけるすべてのプライマリ・データベースおよびスタンバイ・データベースで推奨されます。
フラッシュ・リカバリ領域は、ファイル・システムまたは自動ストレージ管理（ASM）ディスク・グループ上にある、リカバリに必要なすべてのファイルが存在する唯一の格納場所です。これらのファイルには、制御ファイル、アーカイブ・ログ、オンラインREDOログ、フラッシュバック・ログおよびRecovery Managerバックアップがあります。新しいバックアップおよびアーカイブ・ログがフラッシュ・リカバリ領域に作成されると、古いファイル（保存期間を超過しているまたは三次記憶域にバックアップされている）は自動的に削除され、新しいファイル用の領域が作成されます。さらに、フラッシュ・リカバリ領域の領域使用量が事前に定義された制限に近づいている場合に、DBAにアラートを送信するように通知を設定できます。DBAは、リカバリ領域の領域制限を上げる、ディスク・ハードウェアを追加する、あるいは保存期間を短縮するなどの処置を取ることができます。
次の初期化パラメータを設定して、フラッシュ・リカバリ領域を構成します。
DB_RECOVERY_FILE_DEST = <mount point or ASM Disk Group> DB_RECOVERY_FILE_DEST_SIZE = <disk space quota>
フラッシュバック・データベースを有効に設定すると、Oracle Databaseによってフラッシュバック・ログがフラッシュ・リカバリ領域に保持されます。これらのログを使用すると、完全にリストアしなくても、前の時点までデータベースをロールバックできます。
Recovery Managerの継続的な使用を簡略化するために、多くの永続的な構成設定をData Guard環境のデータベースごとに設定できます。これらの設定により、Recovery Managerの動作を多面的に制御します。たとえば、バックアップの保存ポリシー、デフォルトのバックアップ先（テープまたはディスク）、デフォルトのバックアップ・デバイス・タイプなどを構成できます。CONFIGUREコマンドを使用すると、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コマンドの使用時にRecovery Managerがリモート接続して再同期化を実行できるように、プライマリ・データベースおよびすべてのスタンバイ・データベースについて接続文字列を構成します。ターゲット・インスタンスに接続するとき、ネット・サービス名を指定する必要があります。この要件は、再同期化が実行される他のデータベース・インスタンスがローカル・ホスト上にある場合にも当てはまります。ターゲット・インスタンスおよびリモート・インスタンスは、同じパスワード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構成は、バックアップが実行されるスタンバイ・データベースで推奨されます。
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE CHANNEL DEVICE TYPE SBT PARMS '<channel parameters>';
CONFIGURE ARCHIVELOG DELETION POLICYコマンドを使用して指定します。ログはスタンバイ・サイトでバックアップされるため、ログ削除ポリシーに対してBACKED UPオプションを構成することをお薦めします。
次のRecovery Manager構成は、バックアップが実行されないスタンバイ・データベースで推奨されます。
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
この項では、Data Guard構成内のOracle Databaseのバックアップに使用されるRecovery Managerスクリプトおよび手順について説明します。次の項目で構成されています。
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サービス名を使用してRecovery Managerをターゲットに接続する必要があります。また、すべてのデータベースで同じパスワード・ファイルを使用する必要があります。
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 ALLCONFIGURE ARCHIVELOG DELETION POLICYコマンドで設定されたログ削除ポリシーに従って、アーカイブ・ログを削除します。アーカイブ・ログがフラッシュ・リカバリ領域にある場合は、空きディスク領域がさらに必要になると自動的に削除されます。そのため、毎日ログを明示的に削除する場合にのみ、このコマンドを使用する必要があります。
すべてのリカバリ関連ファイルをテープにバックアップするには、次のコマンドを週1回使用します。
BACKUP RECOVERY FILES;
これにより、ディスク上にある最新の増分バックアップ、イメージ・コピー・バックアップおよびアーカイブ・ログ・バックアップがすべてテープにバックアップされます。
OralceのMedia Management Layer（MML）APIにより、サード・パーティ・ベンダーは、メディア・マネージャ、Recovery Managerと連動して機能するソフトウェア、テープ・ドライブなどの順次メディア・デバイスへのバックアップを可能にするベンダーのハードウェアを構築できます。メディア・マネージャは、テープなどの順次メディアのロード、アンロードおよびラベル付けを処理します。Recovery Managerを順次メディア・デバイスとともに使用するには、Oracle Secure Backupまたはサード・パーティのメディア管理ソフトウェアをインストールする必要があります。
デフォルトでは、次の手順を実行してテープへの直接バックアップを実行します。
CONFIGUREコマンドを実行します。
CONFIGURE DEFAULT DEVICE TYPE TO SBT;
この例では、スタンバイ・データベースで全体バックアップが毎週、増分バックアップが毎日作成されます。
次の手順を実行して、テープに日次バックアップを直接実行します。
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日、次の手順を実行してテープに週次バックアップを直接実行します。
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などのRecovery Managerコマンドや他のメンテナンス・コマンドは、この前提に従って動作します。たとえば、データベースでイメージ・コピーのロールフォワード操作中、そのデータベースに関連付けられたイメージ・コピーのみがロールフォワードされます。さらに、イメージ・コピーのロールフォワードには、ディスク上のすべての増分バックアップとテープ上のすべての増分バックアップが使用されます。同様に、リカバリ操作中、データベースに関連付けられたディスク・バックアップのみとテープ上のファイルが、バックアップのソースとみなされます。
様々なオペランドを指定してRecovery ManagerのCHANGEコマンドを使用すると、リカバリ・カタログのメタデータを変更できます。詳細は、次の各項を参照してください。
RESET DB_UNIQUE_NAMEオプションを指定してCHANGEコマンドを使用すると、Data Guard環境内のあるデータベースから別のデータベースにファイルの関連付けを変更できます。CHANGEコマンドは、ディスク・バックアップまたはアーカイブ・ログをあるデータベースから別のデータベースに転送し、転送先のデータベースでそれらのファイルを使用するときに役立ちます。また、CHANGEコマンドは、FOR DB_UNIQUE_NAMEオプションとRESET DB_UNIQUE_NAME TOオプションを使用すると、いずれのデータベースに直接接続しなくてもデータベース間でファイルの関連付けを変更できます。
データベースの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コマンドを使用すると、バックアップをリストアおよびリカバリの目的で使用可能または使用不可能にしたり、そのメタデータを保存または削除することができます。
DELETEコマンドを使用して、バックアップ・セット、イメージ・コピー、アーカイブ・ログ、プロキシ・コピーを削除します。特定のデータベースに関連付けられているファイルのみを削除するには、FOR DB_UNIQUE_NAMEオプションをDELETEコマンドとともに使用する必要があります。
ファイルのメタデータは、現行のターゲット・データベースに関連付けられ、正常に削除されたすべてのファイル（またはどの既知のデータベースにも関連付けられていないファイル）について削除されます。ファイルが正常に削除できなかった場合は、FORCEオプションを使用してファイルのメタデータを削除します。
別のデータベースに関連付けられているファイルが正常に削除された場合、リカバリ・カタログのそのメタデータも削除されます。他のデータベースに関連付けられているファイルおよび正常に削除できなかったファイルは、DELETEコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます（ファイルはデータベースごとにグループ化されます）。FORCEオプションを使用して、この動作を上書きすることはできません。削除不可のファイルのメタデータを削除しても問題ないことが明確である場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、FORCEオプションを指定してDELETEコマンドを使用し、ファイルのメタデータを削除します。
CROSSCHECKコマンドを使用してリカバリ・カタログ・スキーマのファイル・ステータスを検証および更新します。特定のデータベースに関連付けられたファイルを検証するには、FOR DB_UNIQUE_NAMEオプションをCROSSCHECKコマンドとともに使用します。
現行のターゲット・データベースに関連付けられたすべてのファイル（またはどのデータベースにも関連付けられていないあらゆるファイル）のメタデータは、CROSSCHECK操作の結果に応じてAVAILABLEまたはEXPIREDのマークが付けられます。
別のデータベースに関連付けられているファイルが正常に検査された場合、リカバリ・カタログのそのメタデータもAVAILABLEに変更されます。他のデータベースに関連付けられているファイルおよび正常に検査できなかったファイルは、CROSSCHECKコマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます（ファイルはサイトごとにグループ化されます）。確認し、それでも使用不可のファイルのステータス・メタデータを変更する場合は、CHANGE RESET DB_UNIQUE_NAMEコマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、CROSSCHECKコマンドを実行してステータス・メタデータをEXPIREDに更新します。
次の各項の例では、バックアップを作成したのと同じシステムにテープからファイルをリストアすると仮定しています。ファイルを異なるシステムにリストアする必要がある場合は、そのシステムに対してチャネルを構成してから、リストア・コマンドおよびリカバリ・コマンドを実行する必要があります。存在しないデータベースの構成を設定するには、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';
EXIT;
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データの適用を続行します。
ALTER DATABASE ...文を使用して、REDO Applyを停止します。
TARGETキーワードを使用します）。
RESTORE DATAFILE <n,m,...>; RECOVER DATABASE;
表領域をリストアするには、Recovery Managerの'RESTORE TABLESPACE tbs_name1, tbs_name2, ...'コマンドを使用します。
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コマンドは、制御ファイル内のファイル名をそのデータベースに存在するファイルと一致するように自動的に修正し、データベースをリカバリします。
他の方法として、CREATE CONTROLFILE SQLコマンドを使用して、新しい制御ファイルを作成します。すべてのデータファイルおよびオンライン・ログが消失していなければ、制御ファイルの再作成は可能です。
オンライン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に戻せないことに注意してください。
ALTER DATABASE ACTIVATE STANDBY DATABASE文を使用してスタンバイ・データベースをアクティブ化します。これにより、スタンバイ・データベースがプライマリ・データベースに変換されて、新しいリセットログ・ブランチが作成され、データベースがオープンします。新規リセットログ・ブランチへのスタンバイ・データベースの対応の詳細は、9.4項を参照してください。
すべてのスタンバイ・データベース・インスタンスがすでに必要な時点より後までリカバリされており、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用できない場合は、この方法で操作する必要があります。
次の手順に従ってプライマリ・データベースで不完全リカバリを実行します。
RESETLOGSオプションを使用して（カタログ・データベースとMOUNT状態のプライマリ・インスタンスに接続した後で）データベースをオープンします。
RUN { SET UNTIL TIME 'time'; RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS;
この処理の後に、Data Guard構成内ですべてのスタンバイ・データベース・インスタンスを再確立する必要があります。
次の各項では、スタンバイ・データベースとプライマリ・データベースでバックアップ・ファイルを共有できない場合、REDOログ・ファイルのリモート・アーカイブにスタンバイ・インスタンスのみが使用される場合、またはスタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合など、その他の構成にあわせてバックアップ処理を変更する方法について説明します。
スタンバイ・データベース間の距離が離れている場合、プライマリ・システムや他のスタンバイ・システムからは、これらの上で作成されたバックアップに簡単にアクセスできません。すべてのシステム上でデータベースの完全バックアップを実行して、リカバリ操作を実行します。フラッシュ・リカバリ領域は、プライマリおよびスタンバイ・システム上にローカルに置くことができます（つまり、プライマリ・データベースとスタンバイ・データベースでフラッシュ・リカバリ領域が同一である必要がありません）。
この使用例でも、11.8項で説明した一般的な対策を使用できますが、次の例外があります。
RESTORE操作で使用して、Recovery Managerによる同じホスト上で作成されたバックアップの選択を制限する必要があります。つまり、バックアップの作成時に、BACKUPコマンドではTAG system nameオプションを、RESTOREコマンドではFROM TAG system nameオプションを、RECOVERコマンドではFROM TAG system name ARCHIVELOG TAG system nameオプションをそれぞれ使用する必要があります。
NOMOUNT状態で起動します。
ALTER DATABASE CREATE STANDBY CONTROLFILE AS filename文を使用してスタンバイ制御ファイルを作成し、作成された制御ファイルを使用してスタンバイ・インスタンスをマウントします。
RESTORE DATABASE FROM TAG 'system name'; RECOVER DATABASE FROM TAG 'system name' ARCHIVELOG TAG 'system name';
スタンバイ・インスタンスにより残りのアーカイブREDOログ・ファイルがフェッチされます。
11.4項で説明した手順を使用しますが、データベース・ファイルをバックアップするRecovery ManagerコマンドはFALサーバーに対して実行できません。FALサーバーは、すべてのアーカイブREDOログ・ファイルのバックアップ・ソースとして使用できるため、アーカイブREDOログ・ファイルのバックアップをFALサーバーにオフロードします。
まったく再同期化されていなかったプライマリ・データベースとスタンバイ・データベースでデータベース・ファイル名が異なる場合は、使用する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パラメータを設定できます。
Recovery Managerの増分バックアップを使用して、フィジカル・スタンバイ・データベースをプライマリ・データベースと同期化できる場合があります。Recovery ManagerのBACKUP INCREMENTAL FROM SCNコマンドを使用すると、プライマリ・データベースでスタンバイの現行SCNから始まるバックアップを作成し、それを使用してスタンバイ・データベースをロールフォワードできます。
この項で説明する手順は、フィジカル・スタンバイ・データベースが次のいずれかに該当するため、Recovery Managerの増分バックアップが役立つ状況に適用します。
特に記載していないかぎり、次の手順は前述の3つの状況すべてに適用されます。
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 2> WHERE FIRST_NONLOGGED_SCN>0; MIN(FIRST_NONLOGGED_SCN) ------------------------ 223948
V$DATAFILEビューを問い合せます。
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE 2> WHERE FIRST_NONLOGGED_SCN > 0; FILE# FIRST_NONLOGGED_SCN ---------- ------------------- 4 225979 5 230184
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';
scpコマンドを使用してファイルをコピーしています。
scp /tmp/ForStandby_* standby:/tmp
次に、Recovery Managerのプロンプトで、次のコマンドを入力してカタログに追加します。
RMAN> CATALOG START WITH '/tmp/ForStandby';
REPORT SCHEMA文を実行してスタンバイ・データベース・サイトが自動的に登録され、スタンバイ・サイトにファイル名が表示されることを確認します。
RMAN> REPORT SCHEMA;
RMAN> STARTUP FORCE NOMOUNT; RMAN> RESTORE STANDBY CONTROLFILE FROM TAG 'FORSTANDBY'; RMAN> ALTER DATABASE MOUNT; RMAN> RECOVER DATABASE NOREDO;
V$DATAFILEビューを問い合せ、ロギングなしの変更が含まれるデータファイルがないことを確認します。次の問合せでは0（ゼロ）行が戻されます。
SQL> SELECT FILE#, FIRST_NONLOGGED_SCN FROM V$DATAFILE 2> WHERE FIRST_NONLOGGED_SCN > 0;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 2> USING CURRENT LOGFILE DISCONNECT FROM SESSION;
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|