| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
すべてのデータベースに適切なバックアップを用意する一方で、バックアップおよびリカバリ計画の設計時に目標リカバリ時間（RTO）と目標リカバリ時点（RPO）を検討してください。リカバリの多くにはバックアップのリストア操作が含まれますが、Oracleでは、データベース停止からのリカバリ時間を最小限に抑えるための他のデータベース機能も提供されます（Oracle Data Guardやフラッシュバック・テクノロジなど）。
この項では、データベース・バックアップを適切に管理するためのベスト・プラクティスと、利用可能なOracleデータベース機能を通じて使用できるその他のバックアップ・オプションとバックアップ計画について説明します。
Oracleには、バックアップとリカバリの操作を容易にする複数のデータベース機能および製品が含まれます（Recovery Manager（RMAN）、Oracle Secure Backup、フラッシュ・リカバリ領域、フラッシュバック・データベース、リストア・ポイントなど）。
Recovery Manager（RMAN）は、Oracleデータベースのバックアップとリカバリに使用できるOracleのユーティリティです。RMANは、データベースと緊密に統合されているため、バックアップに必要なファイルを自動的に判別できます。また、より重要な機能として、RMANでは、メディア・リカバリ操作でリストアする必要のあるファイルを認識できます。RMANでは、サーバー・セッションを使用してバックアップおよびリカバリ操作を実行し、バックアップに関するメタデータをリポジトリに格納します。RMANには、一般的なユーザー管理バックアップの方法と比べて有利な点が多くあります。たとえば、次のようなメリットがあります。
表領域をバックアップ・モードにする必要のないオンライン・データベース・バックアップ
増分バックアップ
バックアップおよびリストア操作中のデータ・ブロック整合性チェック
操作を実際に実行しないテスト・バックアップおよびリストア
RMANにより、バックアップとリカバリは自動化されます。ユーザー管理バックアップでは、各データファイルのバックアップ場所を探し、それらをオペレーティング・システムのコマンドを使用して正しい場所にコピーしてから、適用するログを選択する必要があります。RMANでは、これらのタスクを自動で管理できます。
RMANを使用している場合にのみ利用可能なOracleバックアップおよびリカバリの機能（表領域の自動ポイント・イン・タイム・リカバリやブロック・メディア・リカバリなど）もあります。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の次の章
|
Oracle Secure Backupは、UNIX、Linux、Windows、Network Attached Storage（NAS）などの異機種環境にデータ保護を提供します。Oracle Secure Backupにより、次のようなOracle環境全体でテープ・データ保護機能を使用できます。
Oracleデータベース（RMANとの統合を通じて）
Oracle Real Application Clusters（Oracle RAC）のシームレスなサポート
次のような分散サーバーのファイル・システム・データ保護
Oracle Application Server
Oracle Collaboration Suite
Oracleホームおよびバイナリ
RMANとOracle Secure Backupの組合せにより、エンドツーエンドのテープ・バックアップ・ソリューションが提供されるため、サード・パーティ製のバックアップ・ソフトウェアを使用する必要がなくなります。
Oracleリストア・ポイントは、データベース・メンテナンス時のリスクの高いポイントにおける論理障害を防ぎます。通常のリストア・ポイントを作成すると、特定の時点またはSCNにリストア・ポイント名が割り当てられます。リストア・ポイント名は、フラッシュバック表操作、フラッシュバック・データベース操作およびすべてのRMANリカバリ関連の操作で使用されます。
保証付きリストア・ポイントは、データベース全体を対象とするメンテナンス（データベースまたはアプリケーションのアップグレードや、バッチ・プロセスの実行など）に推奨されます。保証付きリストア・ポイントにより、フラッシュバック・データベースが有効化され、データベースをそのリストア・ポイントにフラッシュバックするのに必要なすべてのフラッシュバック・ログが保持されます。メンテナンス・アクティビティの完了後に結果を検証したら、不要な保証付きリストア・ポイントは削除する必要があります。
|
関連項目: フラッシュバック・データベースの詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。 |
この項では、バックアップの使用、バックアップの実行、RMANリカバリ・カタログの使用、ブロック変更トラッキングの有効化などのベスト・プラクティスを説明します。
本番データベースの計画外の停止を解決するためにバックアップを使用すると、RTOまたは品質保証要件を満たすことができない場合があります。たとえば、一部の停止は、フラッシュバック・データベースまたはスタンバイ・データベースを使用することで最も効果的に対処できます。ただし、次のようにデータベース・バックアップを使用することが必要な状況もあります。
Data Guard環境の初期設定 スタンバイ・データベースの初期設定時には、セカンダリ・サイトでプライマリ・データベースのバックアップを使用して初期スタンバイ・データベースを作成するか、ネットワーク対応のデータベース複製機能を使用してアクティブなデータベースの複製を実行します（この場合、データベース・バックアップがあらかじめ存在する必要はありません）。どちらの場合も、プライマリ・データベースに接続して、DUPLICATEコマンドを使用してフィジカル・スタンバイ・データベースを作成します。ネットワーク経由で複製を開始するには、FROM ACTIVE DATABASEオプションも含める必要があります。
|
関連項目:
|
ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリ Data Guardのない環境でブロック破損、メディア障害、またはその他の物理データ障害が発生した場合、唯一のリカバリ方法は、既存のバックアップからのリストアです。
二重障害の解決 二重障害の状況では、本番データベースとスタンバイ・データベースの両方の可用性が影響を受けます。二重障害の例は、セカンダリ・サイトが停止してフォルト・トレランスが失われ、それに続いて本番データベースでメディア障害が発生した場合です。スタンバイを再作成する必要があるどうかは、セカンダリ・サイトの停止タイプにより異なります。セカンダリ・サイトの停止が一時的で、ファイルの物理的破損がなかった場合は、セカンダリ・サイトがオンラインに戻された後で、本番データベースからREDOデータを継続して受信することができます。それ以外の場合、この状況を解決する方法は、使用可能なバックアップから本番データベースを再作成し、次にスタンバイ・データベースを再作成することです。
プライマリ・サイトの停止に続いてセカンダリ・サイトが停止するなど、複数の障害（より適切に言えば、災害）が発生した場合、オフサイトにのみ存在するバックアップを使用する必要があります。したがって、壊滅的な状況下でサービスを再開するには、オフサイトにバックアップ・テープを配布して管理するためのプロセスを開発し、そのプロセスに準拠する必要があります。
バックアップ頻度ポリシーを決定して、定期的にバックアップを実行することは重要です。バックアップ保存ポリシーは、必要なデータがすぐに破棄されないことを保証するのに役立ちます。
バックアップ頻度を決定する要因 頻繁なバックアップは、すべてのリカバリ・スキームにとって不可欠です。バックアップの頻度と内容は、次の基準に基づいて決定します。
データの重大性: 障害の場合にどれくらいのデータ損失を業務で許容できるかは、RPOにより決まります。データがより重大で、RPOが低いほど、データのバックアップ頻度を高めます。データベースのどの部分が業務にとって最も重要かを決定する必要があります。
推定修復時間: リカバリのために必要な時間の許容値は、RTOにより決まります。修復時間は、リストア時間とリカバリ時間の合計に基づきます。RTOが高くなるほど、バックアップ頻度を高め、リカバリに必要な時間を短縮します。
変更されたデータ量: データベースのバックアップ頻度は、データベースの変更率の影響を受けます。
読取り専用データの場合、保存ポリシーを確実に守れる頻度でバックアップを実行します。
変更頻度の高いデータの場合、バックアップ頻度をさらに高めてRTOを減らします。
データベースのバックアップとリカバリを簡略化するため、推奨バックアップ計画では、フラッシュ・リカバリ領域を導入し、増分バックアップ機能と更新増分バックアップ機能を使用します。
|
関連項目: 『Oracle Database 2日でデータベース管理者』の、Oracle推奨のバックアップ戦略に関する項 |
バックアップ保存ポリシーの確定 バックアップ保存ポリシーは、リカバリなどの要件を満たすために（ディスクまたは他のバックアップ・メディアに）保存する必要のあるバックアップに関するルール・セットです。特定のバックアップは、より新しいバックアップで置換されているか、テープに保存済であるという理由から、安全に削除することが可能です。また、特定のバックアップは、アーカイブ要件や規制要件など、他の理由により、ディスクに保存する必要があります。バックアップ保存ポリシーを満たすために必要でなくなったバックアップは、不要なバックアップとなります。
バックアップ保存ポリシーは、冗長性やリカバリ・ウィンドウに基づいて決定します。
冗長性ベースの保存ポリシーでは、データベース内の各ファイルの個別バックアップを少なくともn個常に保持するように、nという数を指定します。
リカバリ・ウィンドウ・ベースの保存ポリシーでは、以前の時間間隔（1週間や1か月など）を指定して、その期間内の任意の時点に対してポイント・イン・タイム・リカバリを実行するのに必要なすべてのバックアップを保持します。
アーカイブ・バックアップの保持 一部のビジネスでは、将来の数年間にわたり必要とされるアーカイブ（長期）・バックアップを保持する必要があります。アーカイブのバックアップは、データベースのバックアップ保存ポリシーによってでなく、その時間制限が期限切れになったときに不要になります。
KEEPオプション付きでRMAN BACKUPコマンドを使用すると、保存ポリシーとは関係なく無期限にバックアップを保存して、任意の時点にデータベースをリストアおよびリカバリできます。領域不足のためにバックアップ・メタデータが失われることのないように、RMANリポジトリにリカバリ・カタログを使用する必要があります（RMANリポジトリにターゲット・データベースの制御ファイルを使用すると、領域不足が発生する可能性があります）。Oracle Database in 11g以上では、アーカイブ・バックアップの一貫性を維持するのに必要とされるアーカイブREDOログ・ファイルのみが保存されます。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の長期保管用のデータベース・バックアップの作成に関する項 |
さらにより長い期間バックアップ・メタデータを保護および維持する場合、リカバリ・カタログと呼ばれる別個のデータベース・スキーマに、追加のRMANリポジトリを作成することができます。リカバリ・カタログ・スキーマは、この目的専用のスタンドアロンのデータベースに作成してください。リカバリ・カタログを他の本番データとともに配置しないでください。Oracle Enterprise Managerを使用する場合、Enterprise Managerリポジトリ・データベースにリカバリ・カタログ・スキーマを作成することをお薦めします。
リカバリ・カタログを使用することによるメリットは、次のとおりです。
バックアップ情報の長期保存
複数のデータベースのメタデータの保存
別のシステムへの使用可能バックアップのリストア
フィジカル・スタンバイ・データベースにバックアップの負荷を移行し、それらのバックアップを使用してプライマリ・データベースをリストアおよびリカバリできます。同様に、プライマリ・データベースの表領域をバックアップし、フィジカル・スタンバイ・データベースでリカバリできます。ただし、ロジカル・スタンバイ・データベースのバックアップはプライマリ・データベースで使用できません。
リカバリ・カタログを使用するもう1つの理由は、ターゲット・データベースの制御ファイルに最大サイズの制限があるためです。制御ファイルのサイズが小さすぎて追加のバックアップ・メタデータを保持できなくなると、既存のバックアップ情報は上書きされるため、それらのバックアップを使用してリストアとリカバリを行うことは困難になります。
|
関連項目: RMANリポジトリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
バックアップをディスクまたはテープに作成する場合、ターゲット・データベースの制御ファイルをRMANリポジトリとして使用します。これにより、バックアップの成功が、RMANリポジトリを保持するデータベースの可用性に左右されなくなります。ターゲット・データベースの制御ファイルをRMANリポジトリとして使用するには、NOCATALOGオプションを付けてRMANを実行します。バックアップの完了直後に、RESYNC CATALOGコマンドを使用することで、ターゲット・データベースの制御ファイルに格納された新規バックアップ情報がリカバリ・カタログと再同期されます。
|
関連項目: RESYNC CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。 |
Oracleデータベースには、増分バックアップ用の変更トラッキング機能があります。この機能により、各データファイルの変更済ブロックを変更トラッキング・ファイルに記録することで、増分バックアップのパフォーマンスを向上できます。変更トラッキングが有効化されると、RMANは、変更トラッキング・ファイルを使用して増分バックアップに含める変更済ブロックを特定します。これにより、データファイルのすべてのブロックをスキャンする必要がなくなるため、バックアップ中のディスク読取り数が減少します。
Oracle Database 11g以上では、プライマリ・データベースとスタンバイ・データベースの両方に変更トラッキングを有効化できます。増分バックアップを実行する任意のデータベースで変更トラッキングを有効化する必要があります。たとえば、バックアップの負荷をフィジカル・スタンバイ・データベースに完全に移行している場合、そのデータベースでブロック変更トラッキングを有効化する必要があります。プライマリ・データベースとスタンバイ・データベースの両方でバックアップを実行する場合、両方のデータベースで変更トラッキングを有効化します。
|
関連項目: ブロック変更トラッキングの詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。 |
RMANを構成して、制御ファイルのデータベース構造メタデータが変更された場合、またはバックアップ・レコードが追加された場合に制御ファイルとサーバー・パラメータ・ファイル（SPFILE）を自動的にバックアップできます。自動バックアップにより、RMANでは、現在の制御ファイル、カタログおよびSPFILEが失われた場合でもデータベースをリカバリできます。RMANの自動バックアップ機能は、CONFIGURE CONTROLFILE AUTOBACKUP ON文を使用して有効化します。
自動バックアップ機能は、プライマリ・データベースとスタンバイ・データベースの両方で有効化する必要があります。たとえば、プライマリ・データベース（ターゲット・データベース）およびリカバリ・カタログに接続した後、次のコマンドを発行します。
CONFIGURE CONTROLFILE AUTOBACKUP ON;
|
関連項目: 自動バックアップの詳細は、MAAホワイト・ペーパー『Using Recovery Manager with Oracle Data Guard』と、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。 |
Data Guard構成では、制御ファイル、データファイルおよびアーカイブREDOログ・ファイルをバックアップするプロセスの負荷をフィジカル・スタンバイ・システムに移行して、プライマリ・システムに対するバックアップの影響を最小限に抑えることができます。これらのバックアップは、プライマリ・データベースまたはスタンバイ・データベースのリカバリに使用できます。ただし、ロジカル・スタンバイ・データベースのバックアップはプライマリ・データベースで使用できません。
|
関連項目: 『Oracle Data Guard概要および管理』のRMANを使用したファイルのバックアップとリストアに関する章 |
バックアップ・メカニズムを選択する場合、次の優先項目を参考にバックアップ計画を決定してください。
バックアップ時間全体
リソース使用量への影響
バックアップによる使用領域
リカバリ時間
表2-8では、環境ごとに異なる優先項目に対応する様々なバックアップの選択肢を比較しています。この表を参考に、現在の特定のビジネス要件に最適なバックアップ方法を選択してください。リカバリ時間を犠牲にする一方で、バックアップ領域を最小化することが可能です。または、領域を考慮せずに、リカバリ時間とバックアップ時間を優先することも可能です。
| バックアップ・オプション | バックアップ時間全体 1: 最も速い 5: 最も遅い |
リソース使用量への影響 1: 最小 5: 最大 |
バックアップによる使用領域 1: 最小 5: 最大 |
リカバリ時間 1: 最も速い 5: 最も遅い |
|---|---|---|---|---|
|
5 |
5 |
5 |
1 脚注1 |
|
|
4 |
4 |
3 |
3 |
|
|
1 |
1 |
1 |
5 |
|
|
2 |
2 |
2 |
4 |
|
|
3 |
1 |
5 |
1脚注1 |
脚注1 リストアなし（フラッシュ・リカバリ領域コピーに切替え）
リカバリ時間を最適化するためのベスト・プラクティス リストア時間が主な検討課題の場合、データベース・コピーか、または即時ロールフォワードを実行する増分バックアップを実行します。即座に使用できるデータベースのバックアップを提供するのはこれら2つのオプションのみであり、最後のバックアップ以降に作成されたアーカイブREDOログ・ファイルを使用することで、障害発生時点までリカバリできます。
領域使用量を最小化するためのベスト・プラクティス 領域使用量が主な検討課題の場合、遅延ロールフォワードを実行する増分バックアップを実行します。累積レベル1の増分バックアップを実行すると、最後のレベル0のバックアップ以降に変更されたブロックのみが保存されます。
累積増分バックアップでは、最後のレベル1のバックアップのみをレベル0のバックアップに適用します。
差分増分バックアップでは、レベル1のすべてのバックアップをレベル0のバックアップに適用します。
通常、累積増分バックアップは、差分増分バックアップより多くの領域をフラッシュ・リカバリ領域で使用します。
システム・リソース消費（I/OおよびCPU）を最小化するためのベスト・プラクティス システム・リソース消費が主な検討課題の場合、ブロック変更トラッキング・ファイルを使用する増分バックアップを有効にすると、データベースでのリソース消費量が最小になります。
例
ほとんどのアプリケーションで、トランザクション頻度が非常に高くても、データベース全体で毎日変更される部分の割合は多くありません。アプリケーションは、同じブロック・セットを頻繁に更新するため、ダーティ・ブロック・セットの合計サイズは小さくなります。
たとえば、約600GBのユーザー・データを含むデータベースがあるとします（一時ファイルとREDOログは除外します）。24時間ごとに、データベースの約2.5%（約15GBのデータ）が変更されます。この例では、MAAテストで次の結果が得られました。
レベル0のバックアップには、180分を要します（データ領域からのREAD操作とフラッシュ・リカバリ領域へのWRITE操作を含む）。
レベル1のバックアップには、20分を要します（データ領域からのREAD操作とフラッシュ・リカバリ領域へのWRITE操作を含む）。
新規作成された増分バックアップによる、フラッシュ・リカバリ領域にある既存のイメージ・コピーのロールフォワードとマージには、45分を要します（フラッシュ・リカバリ領域を対象とするREAD操作とWRITE操作を含む）。
レベル0バックアップが行われてから増分バックアップを使用してロールフォワードされる最後の事例では、初期バックアップに180分を要します（全体バックアップ実行の所要時間と同じ）。それ以降のバックアップはレベル1（増分）で、所要時間は20分なので、データ領域への潜在的影響は減少します。その後、そのバックアップが、レベル0バックアップに適用されます。これには45分を要します。このプロセスはデータ領域へのI/Oを実行しないため、影響はありません（フラッシュ・リカバリ領域とデータ領域が個別ストレージを使用する場合）。増分バックアップを作成し、既存のレベル0バックアップに適用する場合の総所要時間は65分です（20 + 45）。どちらの場合も結果は同じです。データベースの全体イメージ・バックアップが実行されます。増分を使用する手法の所要時間は、単純に全体バックアップを作成するより115分短くなります（64%減少）。そして、特にデータ領域に対して、同じエンド・ポイントに到達するために実行されるI/Oの量が少なくなるため、本番データベースのパフォーマンスへの影響も少なくなります。
このように、この例で、常に全体バックアップ行う場合と、まずレベル0バックアップを行い、増分バックアップのみを実行し、その後でレベル0バックアップをロールフォワードする場合を比較すると、最終的な削減内容は次のようになります。
115分または64%の時間を節約して完全なバックアップを作成できます。
バックアップ中のデータベースのI/Oを削減できます。
大規模データベースの場合、MAAテストではさらに大きな削減量が記録されました。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の、データベースのバックアップに関する章 |
この項では、テープ・バックアップやOracle Secureバックアップを作成する方法と、オフサイト・バックアップの管理について説明します。
RMANコマンドのBACKUP RECOVERY FILESを使用すると、フラッシュ・リカバリ領域に作成されているディスク・バックアップをテープにコピーできます。1つのコマンドを使用して、まだテープにバックアップされていないすべてのファイルをバックアップできます。これにより、2回以上ファイルをバックアップしてテープを無駄にせずにすむ他、以前にバックアップされていないファイルを追跡する必要もなくなります。テープ・バックアップは、オフサイトおよび長期保管用で、特定の停止状況に対処する際に使用します。
Oracle Secure Backupでは、Oracleデータベースを最高速でテープにバックアップできます。Oracle Secure Backupは、Oracle以外のテープ・バックアップ・システムでは利用できないRecovery Manager（RMAN）と統合されており、容易にアクセスできます。Oracle Secure Backupリリース10.2とOracle Database 11gを使用することで、次の主要なパフォーマンス最適化が実現します。
コミット済UNDOのバックアップがなくなるため、バックアップ・パフォーマンスが向上し、テープ使用量が減少します。未コミットのUNDOのみがバックアップされます。
SBTとテープ間の共有バッファの使用によりSBTバッファの割当てが最適化されます（Oracle Secure Backup）。以前のリリースでは、RMANがデータをSBTバッファに書き込み、メディア・マネージャがデータをSBTバッファからテープ・バッファにコピーしていました。Oracleのテスト結果では、共有バッファを使用することで（Oracle Secure BackupおよびRMANのみ）、CPUのオーバーヘッドが最大30%削減されました。
Oracle Database 10gリリース2（10.2）とOracle Secure Backupリリース10.1が稼働中の構成では、Oracle Secure Backupは、データベース・オブジェクトに現在割り当てられているブロックのみをバックアップし、読み取ります。割り当てられていないブロックは、読み取られず、バックアップもされません。
|
関連項目: Oracle Secure Backupのドキュメント・セットは、Oracle Technology Networkの次の場所で入手できます。
|
この項では、データファイルの破損チェック、データ・リカバリ・アドバイザの使用、リカバリ手順のテスト、およびリカバリ・カタログ・データベースのバックアップについて説明します。
RMAN VALIDATEコマンドを使用して、ユーザー・セッションや通常のバックアップ操作によりまだレポートされていないブロック破損が存在しないかどうか、データベース・ファイルを定期的にチェックします。RMANは、指定されたファイルをスキャンして、物理エラーと論理エラーをチェックしますが、実際のバックアップまたはリカバリ操作は実行しません。Oracle Databaseでは、破損ブロックのアドレスと破損タイプが制御ファイルに記録されます。これらのレコードには、V$DATABASE_BLOCK_CORRUPTIONビューを通じてアクセスします（このビューは、RMANのブロック・メディア・リカバリで使用できます）。
検出可能なすべての破損タイプを検出するには、CHECK LOGICALオプションを指定します。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』のデータベース・ファイルおよびバックアップの検証方法に関する章 |
完全で正常なテスト済のバックアップは、リカバリが成功するための基盤となります。異なる停止タイプに対応するテスト計画を作成してください。最も一般的な停止タイプから始め、最も可能性の低いタイプへと作業を進めます。RMAN DUPLICATEコマンドの使用は、リカバリ・テストを実行するためのよい方法です。バックアップからのリストアと、メディア・リカバリの実行が必要であるためです。
バックアップ手順のエラーを監視し、定期的にリカバリ手順をテストしてバックアップを検証します。また、RMANコマンドRESTORE...VALIDATEを使用して、データベースのリストアの実行可能性を検証します。
