12 RMANを使用したファイルのバックアップおよびリストア
Oracle Data Guardおよびスタンバイ・データベースとともにOracle Recovery Manager(RMAN)を使用するバックアップ対策を作成できます。
RMANを使用すると、最小限の労力でプライマリ・データベースのバックアップを実行し、個々のデータファイルの消失またはデータベース全体をすばやくリカバリできます。RMANとOracle Data Guardをともに使用すると、Oracle Data Guard構成の管理がシンプルになります。
次のトピックを参照してください。
注意:
ロジカル・スタンバイ・データベースはプライマリ・データベースのブロック単位のコピーではないため、ロジカル・スタンバイ・データベースを使用してプライマリ・データベースをバックアップすることはできません。
関連項目:
-
RMANの概念と、Oracle Data Guard環境でのRMANの使用方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
RMANコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
12.1 Oracle Data Guard構成でのRMANファイル管理について
RMANでは、リカバリ・カタログを使用して、Oracle Data Guard環境のすべてのデータベース・ファイルについてファイル名を追跡管理します。
リカバリ・カタログは、1つ以上のOracleデータベースに関するメタデータを格納するためにRMANで使用されるデータベース・スキーマです。また、カタログには、オンラインREDOログ、スタンバイREDOログ、テンプレート、アーカイブREDOログ、バックアップ・セットおよびイメージ・コピーが作成される場所も記録されます。
12.1.1 Oracle Data Guard環境でのバックアップの互換性
RMANコマンドは、リカバリ・カタログのメタデータを使用して、Oracle Data Guard環境の様々なフィジカル・データベースにわたって透過的に動作します。
たとえば、フィジカル・スタンバイ・データベースで表領域のバックアップを作成し、プライマリ・データベースでリストアおよびリカバリできます。同様に、プライマリ・データベースで表領域のバックアップを作成し、フィジカル・スタンバイ・データベースでリストアおよびリカバリできます。
注意:
ロジカル・スタンバイ・データベースのバックアップは、プライマリ・データベースでは使用できません。
スタンバイ制御ファイルのバックアップと非スタンバイ制御ファイルのバックアップには互換性があります。たとえば、スタンバイ制御ファイルをプライマリ・データベースにリストアし、プライマリ制御ファイルをフィジカル・スタンバイ・データベースにリストアできます。この互換性は、制御ファイルのバックアップをOracle Data Guard環境の1つのデータベースにオフロードできることを意味します。RMANは、データベースでのリストアおよびリカバリ時に、データベース・ファイルのファイル名を自動的に更新します。
12.1.2 Oracle Data Guard環境でのバックアップの関連付け
リカバリ・カタログでは、すべてのデータベース・ファイル(バックアップ・ファイル)をDB_UNIQUE_NAME
に関連付けて、Oracle Data Guard環境のファイルを追跡管理します。
ファイルを作成するデータベースは、そのファイルに関連付けられます。たとえば、RMANでstandby1
という一意の名前を持つデータベースをバックアップすると、standby1
がこのバックアップに関連付けられます。バックアップは、CHANGE
... RESET DB_UNIQUE_NAME
を使用して別のデータベースに関連付けないかぎり、作成元のデータベースに関連付けられたままです。
12.1.3 Oracle Data Guard環境でのバックアップのアクセシビリティについて
Oracle Data Guard環境では、関連付けられたデータベースのみがディスク・バックアップにアクセスできるとリカバリ・カタログによってみなされますが、1つのデータベースに作成されたテープ・バックアップにはすべてのデータベースがアクセスできます。
バックアップ・ファイルがいずれのデータベースにも関連付けられていない場合、リカバリ・カタログ・ビュー内のバックアップ・ファイルに関する行のSITE_KEY
列にnull
が表示されます。デフォルト設定では、RMANはターゲット・データベースにSITE_KEY
がnull
のファイルを関連付けます。
BACKUP
、RESTORE
、CROSSCHECK
などのRMANコマンドは、アクセス可能なバックアップに対して作用します。たとえば、RECOVER COPY
操作の場合、RMANはデータベースに関連付けられているイメージ・コピーのみをリカバリ対象とみなします。また、ディスクおよびテープ上の増分バックアップをイメージ・コピーのリカバリ対象とみなします。データベース・リカバリでは、RMANは、データベースに関連付けられたディスク・バックアップのみとテープ上のすべてのファイルをリストアの対象とみなします。
バックアップのアクセス可能性における差異を示すため、データベースprod
およびstandby1
が異なるホスト上に存在すると仮定します。RMANは、PROD
上のデータファイル1を本番ホスト上の/prmhost/disk1/df1.dbf
およびテープにバックアップします。RMANは、standby1
上のデータファイル1をスタンバイ・ホスト上の/sbyhost/disk2/df1.dbf
およびテープにバックアップします。RMANがデータベースprod
に接続されると、RMANコマンドを使用してスタンバイ・ホスト上にある/sbyhost/disk2/df1.dbf
バックアップで操作を実行することはできません。しかし、RMANはstandby1
で作成したテープ・バックアップをリストア対象とみなします。
注意:
スタンバイ・ホストからプライマリ・ホスト(またはその逆)にバックアップをFTP転送し、対象のホスト上のデータベースにTARGET
として接続した後、バックアップに対してCATALOG
を実行することができます。ファイルは、ターゲット・データベースによってカタログに追加された後に、ターゲット・データベースに関連付けられます。
12.2 Oracle Data Guard環境でのRMAN構成について
Oracle Data Guard構成では、制御ファイル、データファイルおよびアーカイブ・ログのバックアップ処理をスタンバイ・システムにオフロードできるため、バックアップが本番システムに与える影響は最小限に抑えられます。
これらのバックアップを使用すると、プライマリ・データベースまたはスタンバイ・データベースをリカバリできます。
RMANでは、DB_UNIQUE_NAME
初期化パラメータを使用してデータベース・サイトどうしを区別します。そのため、DB_UNIQUE_NAME
の一意性がOracle Data Guard構成で維持されることは不可欠なことです。
RMANのREGISTER DATABASE
コマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、RMANをリカバリ・カタログに接続し、ターゲットとしてプライマリ・データベースに接続した後に行います。
RMAN構成を設定するには、RMANのCONFIGURE
コマンドを使用します。CONFIGURE
コマンドがFOR DB_UNIQUE_NAME
オプションを指定して使用されると、指定したDB_UNIQUE_NAMEのデータベースに対してRMANサイト固有の構成が設定されます。
たとえば、リカバリ・カタログへの接続後、次のコマンドをRMANプロンプトで使用して、DBIDが1625818158のBOSTON
データベースに対してデフォルト・デバイス・タイプをSBT
に設定できます。RMANのSET DBID
コマンドは、ターゲットとしてデータベースに接続していない場合にのみ必要です。
SET DBID 1625818158; CONFIGURE DEFAULT DEVICE TYPE TO SBT FOR DB_UNIQUE_NAME BOSTON;
12.3 推奨されるRMAN構成およびOracle Database構成
これらの構成によってバックアップおよびリカバリ操作を簡略化できます。
構成の前提
これらの構成は、次の前提に立っています。
-
スタンバイ・データベースはフィジカル・スタンバイ・データベースで、バックアップはスタンバイ・データベースでのみ作成されます。プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成する場合の手順の変更は、「スタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない場合」を参照してください。
-
1つのデータベース・サーバーで作成されたバックアップを別なデータベース・サーバーにリストアできるようにするには、RMANリカバリ・カタログが必要です。プライマリ・データベースはスタンバイ・データベースでバックアップが作成されたことを知らないため、RMANリポジトリとして制御ファイルのみを使用するのでは不十分です。
RMANのリカバリ・カタログは、バックアップ履歴および他のリカバリ関連のメタデータを一元化された場所に編成します。リカバリ・カタログは、データベース内に構成され、バックアップ・メタデータが格納されます。リカバリ・カタログには、制御ファイルに関する領域の制限がないため、バックアップに関する履歴データをより多く格納できます。
カタログ・サーバーは、プライマリ・サイトおよびスタンバイ・サイトと物理的に切り離されていますが、Oracle Data Guard構成内に置くことをお薦めします。これは、いずれのサイトで障害が発生しても最新のバックアップをリカバリする機能に影響しないためです。
関連項目:
リカバリ・カタログの管理の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
構成内のすべてのデータベースには、Oracle Database 11gリリース1 (11.1)以上を使用します。
-
Oracle Secure Backupソフトウェアまたはサード・パーティのメディア管理ソフトウェアは、バックアップをテープに取るようにRMANで構成します。
12.3.1 プライマリおよびスタンバイ・データベースでのOracle Database構成
次のOracle Database構成は、Oracle Data Guard環境におけるすべてのプライマリ・データベースおよびスタンバイ・データベースで推奨されます。
-
データベースごとに高速リカバリ領域を構成する(リカバリ領域はデータベースに対してローカル)。
高速リカバリ領域は、ファイル・システムまたはOracle Automatic Storage Management(Oracle ASM)ディスク・グループ上にある、リカバリに必要なすべてのファイルが存在する唯一の格納場所です。これらのファイルには、制御ファイル、アーカイブ・ログ、オンラインREDOログ、フラッシュバック・ログおよびRMANバックアップがあります。新しいバックアップおよびアーカイブ・ログが高速リカバリ領域に作成されると、古いファイル(保存期間を超過しているまたは三次記憶域にバックアップされている)は自動的に削除され、新しいファイル用の領域が作成されます。さらに、高速リカバリ領域の領域使用量が事前に定義された制限に近づいている場合に、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バックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
12.3.2 プライマリ・データベースでのRMAN構成
RMANの継続的な使用を簡略化するために、多くの永続的な構成設定をOracle Data Guard環境のデータベースごとに設定できます。
これらの設定により、RMANの動作を多面的に制御します。たとえば、バックアップの保存ポリシー、デフォルトのバックアップ先(テープまたはディスク)、デフォルトのバックアップ・デバイス・タイプなどを構成できます。CONFIGURE
コマンドを使用すると、RMAN構成を設定および変更できます。次のRMAN構成は、プライマリ・データベースにおいて推奨されます。
関連項目:
-
RMAN構成の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
RMAN
CONFIGURE
コマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
12.3.3 バックアップが実行されるスタンバイ・データベースでのRMAN構成
次のRMAN構成は、バックアップが実行されるスタンバイ・データベースで推奨されます。
関連項目:
アーカイブREDOログの削除方針の有効化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
12.4 バックアップ手順
RMANのスクリプトと手順を使用して、Oracle Data Guard構成内のOracle Databaseをバックアップできます。
次のトピックを参照してください。
注意:
OracleのMaximum Availability Architecture(MAA)ベスト・プラクティスでは、プライマリ・データベースとスタンバイ・データベースの両方が停止した場合や、スイッチオーバーおよびフェイルオーバーについてサイトのプラクティスを新たに導入しなくてもよいようにする場合に、プライマリ・データベースとスタンバイ・データベースの両方でバックアップを作成してMTTRを短縮することをお薦めしています。
サーバー・パラメータ・ファイルのバックアップ
SPFILEのバックアップを除いたすべてのバックアップ操作は、単一のスタンバイ・データベースにオフロードできます。SPFILEのバックアップは、バックアップ元のデータベースにのみリストアできます。
バックアップされていないデータベースの場合、少なくともSPFILEを既知のローカル・ディスクの場所にバックアップすることをお薦めします。SPFILEバックアップをさらにテープにバックアップする必要がある場合、テープへのバックアップが構成済のデータベース・サイトへコピーすることができます。さらに次のRMANコマンドを使用して、SPFILEバックアップをそのデータベースでカタログ化することができます。
CATALOG START WITH '<SPFILE backup directory>';
次に、SPFILEバックアップをテープにバックアップします。
BACKUP BACKUPSET ALL;
SPFILEが特定のデータベースにリストアされる必要があるときは、適切なSPFILEバックアップがディスクまたはテープからリストアされます。
12.4.1 テープ・バックアップ用キャッシュとしてのディスクの使用
スタンバイ・データベースの高速リカバリ領域は、テープ・バックアップ用のディスク・キャッシュとして機能できます。
ディスクはバックアップ用の一次記憶域として使用され、テープは長期間のアーカイブ記憶域となります。テープの増分バックアップは毎日、テープの全体バックアップは毎週作成されます。これらのバックアップの実行に使用されるコマンドは、次の各項を参照してください。
12.4.1.1 ディスクをキャッシュとして使用する日次テープ・バックアップ用のコマンド
バックアップ計画を決定する際に、日次増分バックアップを利用することをお薦めします。
データファイル・イメージ・コピーは、最新の増分バックアップを使用してロールフォワードできるため、常に最新のデータファイル・イメージ・コピーを提供できます。RMANでは、そのシステム変更番号(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
Oracle 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
コマンドで設定されたログ削除ポリシーに従って、アーカイブ・ログを削除します。アーカイブ・ログが高速リカバリ領域にある場合は、空きディスク領域がさらに必要になると自動的に削除されます。そのため、毎日ログを明示的に削除する場合にのみ、このコマンドを使用する必要があります。
12.4.2 テープへの直接バックアップの実行
OracleのMedia Management Layer(MML)APIにより、サード・パーティ・ベンダーは、メディア・マネージャ、RMANと連動して機能するソフトウェア、テープ・ドライブなどの順次メディア・デバイスへのバックアップを可能にするベンダーのハードウェアを構築できます。
メディア・マネージャは、テープなどの順次メディアのロード、アンロードおよびラベル付けを処理します。RMANを順次メディア・デバイスとともに使用するには、Oracle Secure Backupまたはサード・パーティのメディア管理ソフトウェアをインストールする必要があります。
デフォルトでは、次の手順を実行してテープへの直接バックアップを実行します。
この例では、スタンバイ・データベースで全体バックアップが毎週、増分バックアップが毎日作成されます。
関連項目:
メディア・マネージャ用のRMANの構成方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
12.4.2.1 テープに直接実行する日次バックアップ用のコマンド
テープへの直接の日次バックアップ実行に使用されるRMANコマンドは、Oracle Data Guard環境にある他のデータベースすべてから情報を再同期化します。
次の手順を実行して、テープに日次バックアップを直接実行します。
またこれらのコマンドで、すべてのアーカイブ・ログを含むデータベースのレベル1の増分バックアップを作成します。このスクリプトが実行された1日目に、レベル0のバックアップが検出されなければ、レベル0のバックアップが作成されます。
DELETE ARCHIVELOG ALL
コマンドは、すべてのアーカイブ・ログ・ファイルが高速リカバリ領域にない場合にのみ必要です。
12.5 Oracle Data Guard環境でのデータベースの登録および登録解除
REGISTER DATABASE
コマンドを使用して明示的に登録する必要があるのは、プライマリ・データベースのみです。この登録は、RMANをリカバリ・カタログに接続し、TARGETとしてプライマリ・データベースに接続した後に行います。
新しいスタンバイは、スタンバイ・データベースに接続するか、またはCONFIGURE DB_UNIQUE_NAME
コマンドを使用して接続識別子を構成すると、リカバリ・カタログに自動的に登録されます。
特定のスタンバイ・データベースに関する情報を登録解除するには、UNREGISTER DB_UNIQUE_NAME
コマンドを使用できます。スタンバイ・データベースをOracle Data Guard環境から完全に削除すると、同じOracle Data Guard環境内の別のデータベースに接続した後に、リカバリ・カタログのデータベース情報も削除できます。登録解除されたデータベースと関連付けられたバックアップは、そのまま他のデータベースで使用できます。これらのバックアップは、CHANGE BACKUP RESET DB_UNIQUE_NAME
コマンドを使用して既存の他のデータベースに関連付けることができます。
INCLUDING BACKUPS
オプションを指定してUNREGISTER DB_UNIQUE_NAME
コマンドを使用すると、登録解除中のデータベースに関連付けられたすべてのバックアップ・ファイルのメタデータもリカバリ・カタログから登録解除されます。
12.6 Oracle Data Guard環境におけるレポート生成
FOR DB_UNIQUE_NAME
句を指定してRMANのLIST
、REPORT
およびSHOW
の各コマンドを使用すると、特定のデータベースに関する情報を表示できます。
たとえば、リカバリ・カタログに接続した後、次のコマンドを使用してDBIDが1625818158のデータベースに関する情報を表示し、Oracle Data Guard環境内のデータベースを出力できます。SET DBID
コマンドは、TARGET
としてデータベースに接続していない場合にのみ必要です。最後の3つのコマンドは、DB_UNIQUE_NAME
がBOSTON
のデータベースについて、アーカイブ・ログ、データベース・ファイル名およびRMANの構成情報を出力します。
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;
12.7 Oracle Data Guard環境におけるバックアップ・メンテナンスの実行
Oracle Data Guard環境のファイル(データファイル、アーカイブ・ログ、バックアップ・ピース、イメージ・コピー、プロキシ・コピー)は、DB_UNIQUE_NAME
パラメータを使用してデータベースに関連付けられます。
そのため、Oracle Data Guard環境のデータベースごとに、DB_UNIQUE_NAME
に指定された値は一意であることが重要です。この情報は、ファイル共有属性とともに、RMANの様々な操作の際にアクセスできるファイルを判別するのに使用されます。
ファイル共有属性は、ディスク上のファイルは関連付けられたデータベースでのみアクセス可能で、テープ上のすべてのファイルはすべてのデータベースでアクセス可能に設定されています。BACKUP
およびRESTORE
などのRMANコマンド、およびその他のメンテナンス・コマンドは、この想定で機能しています。たとえば、データベースでのイメージ・コピーのロールフォワード操作中は、そのデータベースに関連付けられたイメージ・コピーだけがロールフォワードされます。そのデータベースに関連付けられたディスクでの増分バックアップおよびテープでの増分バックアップは、イメージ・コピーのロール転送に使用されます。また、リカバリ操作中は、データベースに関付けられたディスク・バックアップとテープ上のファイルのみがバックアップ元と見なされます。
関連項目:
RMANコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
12.7.1 リカバリ・カタログのメタデータの変更
様々なオペランドを指定してRMAN CHANGE
コマンドを使用すると、リカバリ・カタログ内のメタデータを変更できます。
次に例を示します。
-
スタンバイ・データベース間でのファイルの関連付けの変更
RESET DB_UNIQUE_NAME
オプションを指定してCHANGE
コマンドを使用すると、Oracle Data Guard環境内のあるデータベースから別のデータベースにファイルの関連付けを変更できます。CHANGE
コマンドは、ディスク・バックアップまたはアーカイブ・ログをあるデータベースから別のデータベースに転送し、転送先のデータベースでそれらのファイルを使用するときに役立ちます。また、CHANGE
コマンドは、FOR DB_UNIQUE_NAME
オプションとRESET DB_UNIQUE_NAME TO
オプションを使用すると、いずれのデータベースに直接接続しなくてもデータベース間でファイルの関連付けを変更できます。 -
データベースのDB_UNIQUE_NAME初期化パラメータの変更
データベースの
DB_UNIQUE_NAME
初期化パラメータの値を変更すると、Oracle Data Guard環境でも同じ変更を行う必要があります。そのデータベース・インスタンスへの接続後、RMANのリカバリ・カタログはDB_UNIQUE_NAME
の新旧両方の値を認識します。リカバリ・カタログ・スキーマ内で新旧の値に関する情報をマージするには、RMANのCHANGE DB_UNIQUE_NAME
コマンドを使用する必要があります。データベースのDB_UNIQUE_NAME
初期化パラメータの値を変更すると、新しいDB_UNIQUE_NAME
を認識させるために、RMANでも同じ変更を行う必要があります。たとえば、次の手順を実行し、DB_UNIQUE_NAME
をBOSTON_A
からBOSTON_B
に変更することでデータベースを変更します。-
初期化パラメータ・ファイルまたはSQLで、
DB_UNIQUE_NAME
初期化パラメータをBOSTON_A
からBOSTON_B
に変更します。 -
RMANで、Oracle Data Guard environment環境のデータベースにターゲット・データベースとして接続し、リカバリ・カタログに接続します。続いて、
CHANGE
コマンドを実行します。CHANGE DB_UNIQUE_NAME FROM BOSTON_A TO BOSTON_B;
-
-
バックアップの使用不可化またはメタデータの削除
AVAILABLE
、UNAVAILABLE
、KEEP
、UNCATALOG
などのオプションを指定してCHANGE
コマンドを使用すると、バックアップをリストアおよびリカバリの目的で使用可能または使用不可能にしたり、そのメタデータを保存または削除することができます。関連項目:
RMANの
CHANGE
コマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
12.7.2 アーカイブ・ログまたはバックアップの削除
RMAN DELETE
コマンドを使用して、バックアップ・セット、イメージ・コピー、アーカイブ・ログ、プロキシ・コピーを削除します。
特定のデータベースに関連付けられているファイルのみを削除するには、FOR DB_UNIQUE_NAME
オプションをDELETE
コマンドとともに使用する必要があります。
ファイルのメタデータは、現行のターゲット・データベースに関連付けられ、正常に削除されたすべてのファイル(またはどの既知のデータベースにも関連付けられていないファイル)について削除されます。ファイルが正常に削除できなかった場合は、FORCE
オプションを使用してファイルのメタデータを削除します。
別のデータベースに関連付けられているファイルが正常に削除された場合、リカバリ・カタログのそのメタデータも削除されます。他のデータベースに関連付けられているファイルおよび正常に削除できなかったファイルは、DELETE
コマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはデータベースごとにグループ化されます)。FORCE
オプションを使用して、この動作を上書きすることはできません。削除不可のファイルのメタデータを削除しても問題ないことが明確である場合は、CHANGE RESET DB_UNIQUE_NAME
コマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、FORCE
オプションを指定してDELETE
コマンドを使用し、ファイルのメタデータを削除します。
関連項目:
RMANのDELETE
コマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
12.7.3 リカバリ・カタログのメタデータの検証
CROSSCHECK
コマンドを使用してリカバリ・カタログ・スキーマのファイル・ステータスを検証および更新します。
現行のターゲット・データベースに関連付けられたすべてのファイル(またはどのデータベースにも関連付けられていないあらゆるファイル)のメタデータは、CROSSCHECK
操作の結果に応じてAVAILABLE
またはEXPIRED
のマークが付けられます。
別のデータベースに関連付けられているファイルが正常に検査された場合、リカバリ・カタログのそのメタデータもAVAILABLE
に変更されます。他のデータベースに関連付けられているファイルおよび正常に検査できなかったファイルは、CROSSCHECK
コマンドの完了時に、ファイルが関連付けられているデータベースで同じ操作を実行するように求める指示とともに出力されます(ファイルはサイトごとにグループ化されます)。確認し、それでも使用不可のファイルのステータス・メタデータを変更する場合は、CHANGE RESET DB_UNIQUE_NAME
コマンドを使用してデータベースとのファイルの関連付けに対するメタデータを変更し、CROSSCHECK
コマンドを実行してステータス・メタデータをEXPIRED
に更新します。
関連項目:
RMANのCROSSCHECK
コマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
12.8 Oracle Data Guard環境におけるリカバリ例
Oracle Data Guard環境で発生する可能性のあるリカバリ・シナリオの一部を次に示します。
12.8.1 プライマリまたはスタンバイ・データベースでのファイルの損失からのリカバリ
必要なファイルが含まれるフィジカル・スタンバイ・データベースへ接続し、ネットワークを介してファイルをリストアおよびリカバリできます。
これは、プライマリ・データベースで失われたデータファイル、制御ファイルまたは表領域を、フィジカル・スタンバイ・データベース上の対応するファイルを使用してリストアする必要がある場合に有用です。同じプロセスを使用して、プライマリ・データベースを使用してフィジカル・スタンバイ・データベース上のファイルをリストアすることもできます。
ネットワーク経由での接続によるファイルのリストアおよびリカバリ方法の例については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
注意:
Oracle Database 12cより前のリリースでは、プライマリのファイルの損失からリカバリするには、RMANリカバリ・カタログ、RMAN BACKUP
、CATALOG DATAFILE
およびSWITCH DATAFILE
コマンドを使用しました。スタンバイのファイルの損失からリカバリするには、RESTORE
およびRECOVER
コマンドを使用しました。これらの方法は、Oracle Database 12cでは不要になりました。これらの使用についての情報が必要な場合は、Oracle Database 11gのドキュメントを参照してください。
関連項目:
-
ネットワークを介してファイルをリストアおよびリカバリする場合のRMANの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
12.8.2 オンラインREDOログ・ファイルの損失からのリカバリ
現行のACTIVE
グループまたはアーカイブされていない非アクティブ・グループのオンライン・ログ・メンバーすべてが消失した場合、スタンバイ・データベースにフェイルオーバーする必要があります。
フェイルオーバー手順の詳細は「ロールの推移」を参照してください。
その他の状況でのオンラインREDOログ・ファイルの損失からのリカバリ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
12.8.3 プライマリ・データベースの不完全リカバリ
プライマリ・データベースの不完全リカバリを実行するのは、通常、データベースが論理的に(ユーザーまたはアプリケーションが原因で)破損した場合や、表領域またはデータファイルがデータベースから意図せずに削除された場合などです。
スタンバイ・データベース・インスタンス上の現在のデータベース・チェックポイントSCNに応じて、次のいずれかの手順でプライマリ・データベースの不完全リカバリを実行できます。すべての手順は、最も所要時間が短いものから優先順位順になっています。
フラッシュバック・データベースの使用
ラッシュバック・データベースの使用は、プライマリ・データベースでフラッシュバック・データベース機能が使用可能で、データベース・ファイルが1つも消失しておらず、Point-in-Timeリカバリが最も古いフラッシュバックSCNより大きいか、最も早いフラッシュバック時間よりも後の場合の推奨手順です。フラッシュバック・データベースを使用してPoint-in-Timeリカバリを実行する手順の詳細は、「Open Resetlogs文の発行後のフラッシュバック・データベースの使用」を参照してください。
スタンバイ・データベース・インスタンスの使用
これは、スタンバイ・データベースが必要な不完全リカバリ時間より後のもので、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用可能でない場合の推奨手順です。
-
スタンバイ・データベースを必要な時点までリカバリします。次のコマンドを発行する前に、管理されているREDOプロセス(MRP)が停止していることを確認します。
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
文を使用してスタンバイ・データベースをアクティブ化します。これにより、スタンバイ・データベースがプライマリ・データベースに変換されて、新しいリセットログ・ブランチが作成され、データベースがオープンします。スタンバイ・データベースが新しいリセットログ・ブランチにどのように対処するかは、「OPEN RESETLOGS文を使用したリカバリ」を参照してください。
プライマリ・データベース・インスタンスの使用
すべてのスタンバイ・データベース・インスタンスがすでに必要な時点より後までリカバリされており、プライマリまたはスタンバイ・データベースでフラッシュバック・データベースが使用できない場合は、この方法で操作する必要があります。
次の手順に従ってプライマリ・データベースで不完全リカバリを実行します。
この処理の後に、Oracle Data Guard構成内ですべてのスタンバイ・データベース・インスタンスを再確立する必要があります。
12.8.4 プライマリでのTSPITRまたは表領域プラグイン後のスタンバイで必要なアクション
RMAN表領域Point-in-Timeリカバリ(TSPITR)がプライマリで実行された後、修復されたデータファイルは新しいシステム変更番号(SCN)を持つので、プライマリで新しいデータファイルのように扱われます。
これらのデータファイルはスタンバイで自動的に作成することはできません。
同様に、新しいプラグイン表領域がプライマリ・データベースに追加されると、データファイルはプライマリで新しいデータファイルのように扱われます。
Redo Applyプロセスがこれらの新しいファイルの作成を検出すると、スタンバイでの管理されたREDOプロセス(MRP)は停止します。必要な新しいデータファイルはコピーされ、スタンバイにリストアされる必要があります。バックアップまたはプライマリからの直接コピーのいずれかを使用してこれを行うことができます。たとえば、RMAN TSPITRが行われた表領域に属するすべてのファイルをコピーするには、次のRMANコマンドを使用できます。
RMAN> RESTORE TABLESPACE <tbs_name1, tbs_name2> FROM SERVICE <tnsalias-of-primary>
割り当てられるディスク・チャネルの数はRMAN構成ごとです。したがって、CONFIGURE DEVICE TYPE DISK PARALLELISM 4
が実行されると、4つのディスク・チャネルを使用してプライマリ・データベースからファイルが取得されます。
新しいデータファイルがスタンバイで使用可能な場合、MRPを再起動してログの適用を継続します。
関連項目:
-
RMAN TSPITRの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
12.9 その他のバックアップ状況
スタンバイ・データベースとプライマリ・データベースでバックアップ・ファイルを共有できない構成、REDOログ・ファイルのリモート・アーカイブにスタンバイ・インスタンスのみが使用される構成、スタンバイ・データベースのファイル名がプライマリ・データベースとは異なる構成など、その他の構成に合わせてバックアップ手順を変更できます。
12.9.1 スタンバイ・データベースが地理的に離れすぎているためにバックアップを共有できない場合
スタンバイ・データベース間の距離が離れている場合、プライマリ・システムや他のスタンバイ・システムからは、これらの上で作成されたバックアップに簡単にアクセスできません。
すべてのシステム上でデータベースの完全バックアップを実行して、リカバリ操作を実行します。高速リカバリ領域は、プライマリおよびスタンバイ・システム上にローカルに置くことができます。プライマリ・データベースとスタンバイ・データベースで同一である必要はありません。
この使用例でも、「Oracle Data Guard環境におけるリカバリ例」で説明した一般的な対策を使用できますが、次の例外があります。
-
RMANで作成されるバックアップ・ファイルには、タグとしてローカル・システム名を指定し、そのタグを
RESTORE
操作で使用して、RMANによる同じホスト上で作成されたバックアップの選択を制限する必要があります。つまり、バックアップの作成時に、BACKUP
コマンドではTAG
system nameオプションを、RESTORE
コマンドではFROM TAG
system nameオプションを、RECOVER
コマンドではFROM TAG
system nameARCHIVELOG TAG
system nameオプションをそれぞれ使用する必要があります。 -
スタンバイ・サイトの障害時リカバリを実行する手順は、次のとおりです。
-
スタンバイの操作に使用されていたのと同じパラメータ・ファイルを使用して、スタンバイ・インスタンスを
NOMOUNT
状態で起動します。 -
プライマリ・インスタンスで、SQL
ALTER DATABASE CREATE STANDBY CONTROLFILE AS
filename文を使用してスタンバイ制御ファイルを作成し、作成された制御ファイルを使用してスタンバイ・インスタンスをマウントします。 -
次のRMANコマンドを発行し、データベース・ファイルをリストアおよびリカバリします。
RESTORE DATABASE FROM TAG 'system name'; RECOVER DATABASE FROM TAG 'system name' ARCHIVELOG TAG 'system name';
-
REDO Applyを再開します。
-
スタンバイ・インスタンスにより残りのアーカイブREDOログ・ファイルがフェッチされます。
12.9.2 FALサーバーとして使用されるスタンバイ・データベースにデータファイルが含まれていない場合
FALサーバーは、すべてのアーカイブREDOログ・ファイルのバックアップ・ソースとして使用できるため、アーカイブREDOログ・ファイルのバックアップをFALサーバーにオフロードします。
「バックアップ手順」で説明した手順を使用しますが、データベース・ファイルをバックアップするRMANコマンドはFALサーバーに対して実行できません。
12.9.3 スタンバイ・データベースのファイル名がプライマリ・データベースとは異なる場合
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}; }
同様に、RMAN DUPLICATE
コマンドのSET NEWNAME
オプションを使用してスタンバイ・データベースの作成時に新しいファイル名を指定します。あるいは、LOG_FILE_NAME_CONVERT
およびDB_FILE_NAME_CONVERT
パラメータを設定できます。
関連項目:
DB_FILE_NAME_CONVERT
およびDB_CREATE_FILE_DEST
パラメータの両方がスタンバイに設定されている場合の優先ルールの詳細は、「OMFまたはOracle ASMを使用するスタンバイ・データベースの作成」を参照してください。
12.10 ネットワークを介したファイルのリストアおよびリカバリ
Oracle Database 12cでは、RMANを使用すると、必要なファイルが含まれるフィジカル・スタンバイ・データベースへネットワークを介して接続し、ファイルをリストアまたはリカバリできます。
データベース全体、データファイル、制御ファイル、spfileまたは表領域をリストアすることができます。プライマリ・データベースおよびスタンバイ・データベースを同期化する必要がある場合、ネットワークを介したファイルのリストアは、非常に有用です。
RMANは、RESTORE
コマンドのFROM
SERVICE
句を使用し、フィジカル・スタンバイ・データベースからネットワークを介してデータベース・ファイルをリストアします。FROM
SERVICE
句では、ファイルをリストアする必要があるフィジカル・スタンバイ・データベースのサービス名を指定します。リストア操作では、リストアする必要があるファイルのバックアップ・セットがRMANによってフィジカル・スタンバイ・データベース上に作成され、これらのバックアップ・セットがネットワークを介してターゲット・データベースに転送されます。
注意:
Oracle Database 12cより前のリリースでは、ネットワークを介してファイルをリストアまたはリカバリするには、RMANのBACKUP INCREMENTAL FROM SCN
コマンドを使用して、プライマリ・データベースでスタンバイの現行SCNから始まるバックアップを作成し、それを使用してスタンバイ・データベースをロールフォワードしました。この手動の、複数の手順による方法は、Oracle Database 12cでは不要です。この方法の使用に関する情報が必要な場合は、Oracle Database 11gのドキュメントを参照してください。
関連項目:
-
ネットワークを介してファイルをリストアおよびリカバリする場合のRMANの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
-
クロス・プラットフォームの増分バックアップを使用したトランスポータブル表領域の停止時間の短縮については、
http://support.oracle.com
にあるMy Oracle Supportノート2005729.1を参照してください。
12.11 Oracle Data Guard環境でのCDBに対するRMANサポート
RMANでは、スタンバイでのマルチテナント・コンテナ・データベース(CDB)のPoint-in-Timeリカバリ(PITR)がサポートされています。(個別のプラガブル・データベース(PDB)には個別のスタンバイはありません。)
これは、完全なデータベース・リカバリをサポートするためにRMANで提供され、スタンバイ・データベースでの完全なデータ・ファイル・リカバリを補完する追加機能です。
スタンバイでCDB PITRを実行するには、rootとしてCDBに接続し、必要に応じてRMAN BACKUP
、RESTORE
およびRECOVER
コマンドを発行します。
CDB PITRがスタンバイで実行される場合、無効状態だったプラガブル・データベース(PDB)がCDB PITRの前に有効になることに注意してください。PDBを無効状態に戻すには、PDBに接続し、閉じていることを確認し(V$PDBS
ビューのOPEN_MODE
列がMOUNTED
の値を示す)、SQL文ALTER
PLUGGABLE
DATABASE
DISABLE
RECOVERY
を実行します。
ALTER
PLUGGABLE
DATABASE
DISABLE
RECOVERY
文はPDBに属するすべてのデータ・ファイルをオフラインにし、PDBのリカバリを無効にします。PDBに属するデータ・ファイルはPDBが再度有効になるまで、リカバリ・セッションに含まれません。リカバリが無効な間に作成された新しいデータ・ファイルは、名前なしファイルとして作成され、オフラインにマークされます。
PDBに属するすべてのデータ・ファイルをオフラインに戻し、リカバリを有効にするには、PDBに接続し、閉じていることを確認し(V$PDBS
ビューのOPEN_MODE
列がMOUNTED
の値を示す)、SQL文ALTER
PLUGGABLE
DATABASE
ENABLE
RECOVERY
を発行します。
PDBでリカバリが有効か無効かを確認するには、次のようにV$PDBS
ビューを問い合せます。
SQL> SELECT RECOVERY_STATUS FROM V$PDBS;
PDBのフラッシュバック
Oracle Database 12cリリース2 (12.2.0.1)より、FLASHBACK PLUGGABLE DATABASE
コマンド(SQLまたはRecovery Managerを介して使用可能)を実行して特定のPDBでフラッシュバック操作を実行できます。CDBの他のPDBに影響を与えずに、過去の特定のリストア・ポイント(システム変更番号(SCN)の別名)にフラッシュバックできます。(PDBでこのような操作を実行することは、非CDBでのFLASHBACK DATABASE
に例えられます。)
スタンバイでPDBをフラッシュバックすることもできます。事実上、スタンバイでPDBをフラッシュバックすると、PDBのバックアップをリストアしたかのように、PDBのデータ・ファイルが過去のある時点に巻き戻されます。スタンバイでPDBをフラッシュバックすることで、プライマリでPDB PITR/フラッシュバック操作を実行した後、スタンバイはすばやくプライマリのあとを継ぐことができます(「プライマリでのPDB PITR後にスタンバイで必要なアクション」を参照)。
注意:
ALTER
PLUGGABLE
DATABASE
[
ENABLE
|
DISABLE
]
操作の結果として、オンラインまたはオフラインになったファイルは、その操作が実行される前のポイントにデータベースをフラッシュバックする場合でも、その状態のままです。
関連項目:
-
プライマリでのPDB PITR後にスタンバイで必要なアクションの詳細は、「プライマリでのPDB PITR後にスタンバイで必要なアクション」を参照してください
-
プライマリでのTSPITRまたは表領域プラグイン後にスタンバイで必要なアクションの詳細は、「プライマリでのTSPITRまたは表領域プラグイン後のスタンバイで必要なアクション」を参照してください