| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
データ保護計画には、システムおよびストレージのエラーから保護するための適切なバックアップおよびリカバリ戦略が不可欠です。オラクルはOracleデータベースおよび構造化されていないアプリケーション・ファイルのバックアップおよびリカバリのための、包括的なデータ保護スイートを提供します。
この章の主なトピックは、Oracleデータベースのバックアップおよびリカバリのベスト・プラクティスの構成です。ファイル・システム・データ保護機能が、詳細を示す場所のポインタとともに示されます。
この章には、次の項目が含まれます。
表7-1にOracleのバックアップおよびリカバリ・スイートの概要のクイック・リファレンスを示します。
表7-1 バックアップおよびリカバリの概要
| テクノロジ | Oracleデータベースでの使用の推奨 | ファイル・システム・データでの使用の推奨 | コメント |
|---|---|---|---|
|
Zero Data Loss Recovery Appliance |
はい |
いいえ |
エンタープライズ全体のOracleデータ保護(バックアップとリカバリ)ソリューション |
|
Recovery Manager (RMAN) |
はい |
いいえ |
Oracleデータベースのネイティブ・バックアップ・ユーティリティ |
|
Oracle Secure Backup |
はい |
はい |
テープ・バックアップ管理ソフトウェア |
|
Oracle Databaseバックアップ・サービス |
はい |
いいえ |
Oracle Public Cloudへのバックアップ |
|
Oracle Secure Backup Cloud Module for Amazon S3 |
はい |
いいえ |
Amazon S3ストレージへのバックアップ |
|
フラッシュバック・テクノロジ |
はい |
いいえ |
Oracle DatabaseのUNDOデータを利用する論理エラー収集 |
|
フラッシュバック・データベース |
はい |
いいえ |
フラッシュバック・ログを利用するContinuous Data Protection (CDP) |
|
Automatic Clustered File System (ACFS)スナップショット(ファイル・システム・クローンおよび障害時リカバリ用) |
いいえ |
はい |
ファイル・システムの読取り専用または読取り/書込みのcopy-on-writeバージョン。レプリケーション使用可能。 |
|
ZFSスナップショット(開発/テストなどのデータベース・クローン用) |
はい |
はい |
テストおよび開発用データベースの読取り専用または読取り/書込みのcopy-on-writeバージョン |
|
バックアップ/リストア用のZFSスナップショット |
いいえ |
はい |
テスト、開発およびバックアップ用ファイル・システムの読取り専用または読取り/書込みのcopy-on-writeバージョン |
この項では、Oracleデータベースのリカバリ機能を使用し、Oracleデータベースの機能で可能なバックアップ・オプションおよびバックアップ計画を使用する場合の、データベース・バックアップを適切に管理するための目的意識およびツールについて説明します。
本番データベースの計画外の停止を解決するためにバックアップを使用すると、リカバリ時間目標(RTO)とリカバリ・ポイント目標(RPO)、またはサービス・レベル要件を満たすことができない場合があります。たとえば、一部の停止は、フラッシュバック・データベースまたはスタンバイ・データベースを使用することで最も効果的に対処できます。ただし、表7-2に示されている状況のように、データベース・バックアップの使用が必要な状況もあります。
表7-2 データベース・バックアップが必要な状況の例
| データベース・バックアップが必要な状況 | 説明 |
|---|---|
|
Data Guard環境の初期設定 |
スタンバイ・データベースの初期設定時には、セカンダリ・サイトにアクセス可能なプライマリ・データベースのバックアップを使用して初期スタンバイ・データベースを作成するか、RMANネットワーク対応のデータベース複製機能を使用してスタンバイ・データベースを作成します(この場合、バックアップがあらかじめ存在する必要はありません)。ネットワーク経由で複製を実行するには、RMAN |
|
ファイルまたはブロック・メディア・リカバリを使用したデータ障害からのリカバリ |
Data Guardのない環境でブロック破損、メディア障害、またはその他の物理データ障害が発生した場合、唯一のリカバリ方法は、既存のバックアップからのリストアです。 |
|
二重障害の解決 |
二重障害の状況では、本番データベースとスタンバイ・データベースの両方の可用性が影響を受けます。二重障害の例は、セカンダリ・サイトが停止してフォルト・トレランスが失われ、それに続いて本番データベースでメディア障害が発生した場合です。スタンバイを再作成する必要があるどうかは、セカンダリ・サイトの停止タイプにより異なります。セカンダリ・サイトの停止が一時的で、ファイルの物理的破損がなかった場合は、セカンダリ・サイトがオンラインに戻された後で、本番データベースからREDOデータを継続して受信することができます。それ以外の場合、この状況を解決する方法は、使用可能なバックアップから本番データベースを再作成し、次にスタンバイ・データベースを再作成することです。 プライマリ・サイトの停止に続いてセカンダリ・サイトが停止するなど、複数の障害(より適切に言えば、災害)が発生した場合、オフサイトにのみ存在するバックアップを使用する必要があります。したがって、この最悪の事態のシナリオでサービスを再開するには、オフサイトにバックアップ・テープを配布して管理するためのプロセスを開発し、そのプロセスに準拠する必要があります。 |
|
関連項目:
|
Zero Data Loss Recovery Applianceは、Oracle Databaseと統合された新しいデータ保護ソリューションで、データ損失にさらされる状態を解消し、本番サーバーでのバックアップおよびデータ保護によるオーバーヘッドを劇的に減らします。リカバリ・アプライアンスにより、スケーラブルなクラウド・アーキテクチャを備えたデータ・センターのすべてのデータベースを簡単に保護でき、エンドツーエンドのデータ検証が実行されるようになります。また、Enterprise Manager統合インタフェースからすべてのOracleデータベースのデータ保護ライフサイクル全体の管理が自動化されます。
リカバリ・アプライアンスは、すべてのOracle Database 11gおよび12cのデータベースに対するリアルタイムREDO転送の宛先として機能するため、トランザクション・データの過去1秒未満までのデータ損失保護が実現します。
Oracle Recovery Manager (RMAN)と連動して、リカバリ・アプライアンスは、1日目に単一の増分レベル0 (全体)データベース・バックアップを、その後は増分レベル1データベース・バックアップを必要とするだけで、データベースに対するバックアップの実行による影響を最小限に抑えます。
データベースのリストアが必要な場合、直近の増分レベル1バックアップの時点の状態にあるため、リカバリ・アプライアンスによってデータファイルのレベル0コピーが作成され、その結果、データベースのリストアが完了した後にリカバリが必要なデータ量が減ります。
また、テープ・ボールティングのためにOracle Secure Backup (OSB)を使用する他、オフサイトのデータ保護を高速にするために別のリカバリ・アプライアンスにバックアップをレプリケートして、アプライアンスからテープ・ライブラリへのデータの転送が管理されます。
Oracle ZDLRAには、従来のバックアップ方法に対して次のような利点が数多くあります。
オフロードされた永久増分バックアップ計画
リアルタイムREDO転送(過去1秒未満のトランザクションまでのデータ損失保護を実現)
エンドツーエンド・データ・バックアップおよびリカバリ品質保証契約(SLA)の検証
テープ・リソースの効率的な使用
オフサイトのリカバリ・アプライアンスへのバックアップのレプリケーション
Oracle Enterprise Manager Cloud Controlを使用した集中管理および監視
キャパシティ・プランニング、データベース・バックアップおよびリカバリ品質保証契約に関するレポート作成
|
関連項目: Zero Data Loss Recovery Applianceのドキュメント・ライブラリ(特に『Zero Data Loss Recovery Appliance管理者ガイド』および『Zero Data Loss Recovery Appliance保護されたデータベースの構成ガイド』) |
Recovery Manager (RMAN)は、OracleデータベースをバックアップおよびリカバリするためのOracleのユーティリティです。データベースと緊密に統合されているため、バックアップの必要なファイルがRMANにより自動的に判別されます。さらに重要なのは、メディア・リカバリ操作用にリストアする必要のあるファイルをRMANが把握していることです。RMANでは、サーバー・セッションを使用してバックアップおよびリカバリ操作が実行され、バックアップに関するメタデータがリポジトリに格納されます。RMANには、次に示す一般的なユーザー管理のバックアップ方法に対して多くの利点があります。
表領域をバックアップ・モードにする必要のないオンライン・データベース・バックアップ
効率的なブロックレベルの増分バックアップ
バックアップおよびリストア操作中のデータ・ブロック整合性チェック
操作を実際に実行しないテスト・バックアップおよびリストア
フィジカル・スタンバイ・データベースのプライマリ・データベースとの同期化
RMANにより、バックアップとリカバリは自動化されます。ユーザーが管理するやり方では次の作業が必要です。
各データファイルのバックアップ場所の特定
オペレーティング・システム・コマンドを使用した、バックアップの所定の場所へのコピー
適用するログの選択
RMANでは、これらのバックアップおよびリカバリのタスクがすべて自動化されます。
RMANを使用している場合にのみ利用可能なOracleバックアップおよびリカバリの機能(表領域の自動ポイント・イン・タイム・リカバリやブロック・メディア・リカバリなど)もあります。
|
関連項目: 詳細は、次の章を参照してください。
|
Oracle Secure Backupは、一連のサーバーに対する共通管理インタフェースによって、異機種環境における一体的なデータ保護を提供します。Oracleデータベースおよび未構成データの両方を保護することで、Oracle Secure Backupは、次のような環境を含む、ユーザーのIT環境全体に対する集中的なテープ・バックアップ管理を提供します。
Oracle Secure BackupのRecovery Manager (RMAN)とのビルトイン統合を通じた、Oracleデータベース
ファイル・システム・データ保護: UNIX、WindowsおよびLinuxの各サーバー
Network Data Management Protocol (NDMP)を利用するNetwork Attached Storage (NAS)データ保護
Oracle Secure BackupはRMANと統合されて、Oracleデータベースのテープ・バックアップおよびリストア操作のためのメディア管理層(MML)を提供します。この2製品の緊密な統合によって、パフォーマンスの高いOracleデータベースのテープ・バックアップが実現します。
テープの使用を抑えてバックアップ・パフォーマンスを向上させるRMANおよびOracle Secure Backup間で固有のパフォーマンス最適化には、次のようなものがあります。
Oracle Secure Backup環境の管理にはコマンドライン、Oracle Secure Backup WebツールおよびOracle Enterprise Managerを使用できます。
RMANとOracle Secure Backupの組合せの使用により、エンドツーエンドのテープ・バックアップ・ソリューションが提供されるため、サード・パーティ製のバックアップ・ソフトウェアを使用する必要がなくなります。
必要に応じて、Zero Data Loss Recovery Applianceのデプロイ中に、Oracle Secure Backupを構成してリカバリ・アプライアンスと自動的に統合することができます。
|
関連項目:
|
データベースのバックアップが必要な場合、Amazon Web Services (AWS)のSimple Storage Service (S3)によって提供されるインターネット・ベースのデータ・ストレージ・サービスを利用できます。OSB Cloud ModuleによってRMANでは、S3をOracleデータベース・バックアップのリポジトリとして使用できます。これは、社内データ・ストレージや詳細に構成されたローカル・バックアップ・インフラストラクチャの管理に適した、管理しやすくコスト効率の高いスケーラブルな代替手段を提供します。OSB Cloud Moduleを使用したRMANは、AWSのElastic Compute Cloud (EC2)で実行中のOracleデータベースをバックアップする際に推奨される手段でもあります。
ユーザーは、ストレージおよびネットワーク転送コストの支払いを適宜行うための、AWSでのアカウントを設定する必要があります。また、セキュリティ要件およびネットワーク・リソースについても検討し、バックアップも適切に構成する必要があります。S3へのバックアップはパブリック・インターネット経由でAWSに送信され、パブリック・クラウド機能上に格納されるため、転送中およびS3での静止中のデータを保護にはバックアップの暗号化が必要です。この要件は、特定のデータベースまたは特定の構成のデータベースには適用されません。たとえば、データベースがEC2上で実行、またはAWSのVirtual Private Cloud (VPC)内で実行されている場合です。
また、ユーザーは、(RMANチャネルを使用する)ネットワーク並列処理の程度を構成して、データベースとS3 (パブリック・インターネットの要素を含む可能性があります)間のネットワーク機能を照合する必要があります。複数の同時チャネルが全体的に最も高いスループットを実現する可能性があります。RMANではこのような並列処理が最大限活用されるためです。
Oracleはリストア・ポイントおよび保証付きリストア・ポイントを備えています。
リストア・ポイントは、データベース・メンテナンス時のリスクの高いポイントにおける論理障害を防ぎます。通常のリストア・ポイントを作成すると、特定の時点またはSCN、つまりその時点のデータのスナップショットにリストア・ポイント名が割り当てられます。通常のリストア・ポイントは、フラッシュバック表操作、フラッシュバック・データベース操作およびすべてのRMANリカバリ関連の操作で使用できます。
保証付きリストア・ポイントは、データベース全体を対象とするメンテナンス(データベースまたはアプリケーションのアップグレードや、バッチ・プロセスの実行など)に推奨されます。保証付きリストア・ポイントはフラッシュバック・データベースと統合され、保証付きリストア・ポイントにフラッシュバックするのに必要なすべてのフラッシュバック・ログが保持されます。メンテナンス・アクティビティの完了後に結果を検証したら、フラッシュバック・ログ領域を再利用するため不要な保証付きリストア・ポイントは削除する必要があります。
|
関連項目: フラッシュバック・データベースでのリストア・ポイントおよび保証付きリストア・ポイントの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
この項では、バックアップ頻度の決定、RMANリカバリ・カタログの使用、Oracleデータベースのバックアップ・オプション(ブロック変更トラッキングなど)の使用におけるベスト・プラクティスを説明します。
バックアップ頻度ポリシーを決定して、定期的にバックアップを実行することは重要です。バックアップ保存ポリシーは、必要なデータが破棄されないことを保証するのに役立ちます。
バックアップ頻度を決定する要因 頻繁なバックアップは、すべてのリカバリ・スキームにとって不可欠です。バックアップの頻度と内容は、次の基準に基づいて決定します。
データの重大性: 障害が発生した場合にどれくらいのデータ損失を業務で許容できるかは、リカバリ・ポイント目標(RPO)により決まります。データがより重大で、RPOが低いほど、データのバックアップ頻度を高めます。特定の表領域についてより高いRPOを得るため、その表領域を他の表領域よりも頻繁にバックアップする場合は、リカバリ計画の一環としてTSPITRの実行も予定に入れる必要があります。これには、DBPITRよりもさらに多くの計画および実践が必要です。TSPITRを予定している表領域が自己完結型であることの確認が必要なためです。
推定修復時間: リカバリのために必要な時間の許容値は、リカバリ時間目標(RTO)により決まります。修復時間は、リストア時間とリカバリ時間の合計に基づきます。RTOが低いほど、バックアップ頻度は高くなります。つまりバックアップがより最新になるため、リカバリ時間は短縮します。
変更されたデータ量: データベースのバックアップ頻度は、データベースの変更率の影響を受けます。
読取り専用データの場合、保存ポリシーを確実に守れる頻度でバックアップを実行します。
変更頻度の高いデータの場合、バックアップ頻度をさらに高めてRTOを減らします。
データベースのバックアップおよびリカバリを簡略化するために、エンタープライズに対する推奨リカバリ・アプライアンス・バックアップ計画ではRMANを使用して、Data Guard転送によって増分データベース・バックアップおよびREDOをリカバリ・アプライアンスに送信する一方で、推奨バックアップ計画では高速リカバリ領域、増分バックアップおよび更新増分バックアップ機能を特定のデータベースに使用します。FRAへの初期イメージ・コピー・バックアップの後、変更されたブロックのみが増分バックアップで取得され、続いてイメージ・コピーに適用されます。これによって、コピーが最新の増分バックアップ時間に更新されます(つまり、バックアップを増分的に更新します)。
|
関連項目:
|
バックアップ保存ポリシーの確定 バックアップ保存ポリシーは、リカバリ・アプライアンスに保護ポリシーとして実装されますが、リカバリなどの要件を満たすために(ディスクまたは他のバックアップ・メディアに)保存する必要のあるバックアップに関するルール・セットです。特定のバックアップは、より新しいバックアップで置換されているか、テープに保存済であるという理由から、安全に削除することが可能です。また、特定のバックアップは、アーカイブ要件や規制要件など、他の理由により、ディスクに保存する必要があります。バックアップ保存ポリシーを満たすために必要でなくなったバックアップは、不要なバックアップとなります。
バックアップ保存ポリシーは、冗長性やリカバリ・ウィンドウに基づいて決定します。
冗長性ベースの保存ポリシーでは、データベース内の各ファイルの個別バックアップを少なくともn個常に保持するように、nという数を指定します。
リカバリ・ウィンドウ・ベースの保存ポリシーでは、以前の時間間隔(1週間や1か月など)を指定して、その期間内の任意の時点に対してポイント・イン・タイム・リカバリを実行するのに必要なすべてのバックアップを保持します。
アーカイブ・バックアップの保持 ビジネスの中には、日ごとのバックアップ保存ポリシーよりも長期間、バックアップの保持が必要なものもあります。RMANでは、長期アーカイブ・バックアップ機能によってこれが可能です。アーカイブのバックアップは、データベースのバックアップ保存ポリシーに従って不要になるのではなく、まったく不要にならないか、時間制限が切れたときに不要になります。
RMAN BACKUPコマンドをKEEPオプションとともに使用すると、通常の保存ポリシーよりも長期間バックアップを保存できます。このオプションは、バックアップをアーカイブ・バックアップとして指定します。これは、構成済の保存方針から除外される自己完結型のバックアップです。これによって、法定保存要件を満たす場合など必要なときに、特定のバックアップを通常よりも長く保存できます。KEEP FOREVERオプションを使用すると、リカバリ・カタログが必要になります。バックアップ・レコードは最終的に制御ファイルの制御期間を超えてしまうためです(リカバリ・カタログを使用しないと、データベース制御ファイルを使用して通常よりも長くバックアップを保持した場合にデータが消失する可能性があります)。アーカイブ・バックアップの一貫性を維持するのに必要とされるアーカイブREDOログ・ファイルのみが保存されます。RMANリカバリ・カタログの詳細は、7.2.2項「RMANリカバリ・カタログの使用」を参照してください。
|
関連項目: 長期保管用のアーカイブ・バックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
制御ファイルの保存期間よりも長くバックアップ・メタデータを保護および維持するために、リカバリ・カタログを作成できます。リカバリ・アプライアンスを使用している場合、リカバリ・アプライアンスがすべてのデータベースに対するリカバリ・カタログです。リカバリ・アプライアンスを使用していない場合、リカバリ・カタログ・スキーマを専用のスタンドアロンのデータベースに作成する必要があります。リカバリ・カタログを他の本番データとともに配置しないでください。Oracle Enterprise Managerを使用する場合、Oracle Enterprise Managerリポジトリ・データベースでリカバリ・カタログ・スキーマを作成できます。
リカバリ・カタログを使用することによるメリットは、次のとおりです。
制御ファイルで保存が可能な期間よりも長期間のバックアップ情報の保存。制御ファイルのサイズが小さすぎて追加のバックアップ・メタデータを保持できなくなると、既存のバックアップ情報は上書きされるため、それらのバックアップを使用してリストアとリカバリを行うことは困難になります。
複数のデータベースのメタデータの保存
フィジカル・スタンバイ・データベースへのバックアップの負荷の移行と、それらのバックアップを使用したプライマリ・データベースのリストアおよびリカバリ。同様に、プライマリ・データベースの表領域をバックアップし、フィジカル・スタンバイ・データベースでリカバリできます。ただし、ロジカル・スタンバイ・データベースのバックアップはプライマリ・データベースで使用できません。
|
関連項目: RMANリポジトリおよびリカバリ・カタログの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
バックアップをディスクまたはテープに作成する場合、ターゲット・データベースの制御ファイルをRMANリポジトリとして使用します。これにより、バックアップの成功が、リカバリ・カタログへのデータベース接続の可用性に左右されなくなります。ターゲット・データベースの制御ファイルをRMANリポジトリとして使用するには、NOCATALOGオプションを付けてRMANを実行します。バックアップの完了直後に、RESYNC CATALOGコマンドを使用することで、ターゲット・データベースの制御ファイルに格納された新規バックアップ情報がリカバリ・カタログと再同期されます。
|
関連項目: RESYNC CATALOGコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 |
Oracleデータベースには、増分バックアップ用のBLOCK CHANGE TRACKING機能があります。この機能により、以前のバックアップ以降に変更されたデータベース・ブロックを追跡することで、増分バックアップのパフォーマンスを向上できます。BLOCK CHANGE TRACKINGを有効にすると、RMANでは、ブロック変更トラッキング・ファイルを使用して、増分バックアップに含まれるブロックが識別されます。これにより、データファイルのすべてのブロックをスキャンする必要がなくなるため、バックアップ中のディスク読取り数が減少します。
Oracle Database 11g以上では、プライマリ・データベースおよびフィジカル・スタンバイ・データベースの両方でBLOCK CHANGE TRACKINGを有効にできます。増分バックアップを実行する任意のデータベースで変更トラッキングを有効化する必要があります。たとえば、バックアップの負荷をフィジカル・スタンバイ・データベースに完全に移行している場合、そのデータベースでブロック変更トラッキングを有効化する必要があります(これにはActive Data Guardが必要です)。プライマリ・データベースとフィジカル・スタンバイ・データベースの両方でバックアップを実行する場合、両方のデータベースでブロック変更トラッキングを有効化します。
|
関連項目:
|
RMANを構成すると、制御ファイルのデータベース構造メタデータが変更された場合、またはバックアップ・レコードが追加された場合は常に、制御ファイルとサーバー・パラメータ・ファイル(SPFILE)を自動的にバックアップできます。
制御ファイルの自動バックアップ・オプションにより、RMANでは、現在の制御ファイル、カタログおよびSPFILEが失われた場合でもデータベースをリカバリできます。RMANの自動バックアップ機能は、CONFIGURE CONTROLFILE AUTOBACKUP ON文を使用して有効化します。
自動バックアップ機能は、プライマリ・データベースとスタンバイ・データベースの両方で有効化する必要があります。たとえば、プライマリ・データベース(ターゲット・データベース)およびリカバリ・カタログに接続した後、次のコマンドを発行します。
CONFIGURE CONTROLFILE AUTOBACKUP ON;
|
関連項目:
|
Data Guard構成では、制御ファイル、データファイルおよびアーカイブREDOログ・ファイルをバックアップするプロセスの負荷をフィジカル・スタンバイ・システムに移行して、プライマリ・システムに対するバックアップの影響を最小限に抑えることができます。これらのバックアップは、プライマリ・データベースまたはスタンバイ・データベースのリカバリに使用できます。
|
注意: ロジカル・スタンバイ・データベースのバックアップは、プライマリ・データベースで使用できません。 |
|
関連項目: RMANを使用したファイルのバックアップおよびリストアの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
フラッシュバック問合せ、フラッシュバック・バージョン問合せおよびフラッシュバック・トランザクション問合せをデータベースで使用可能にするには、次の作業を行います。
UNDO_MANAGEMENT初期化パラメータをAUTOに設定します。これによってデータベースで必ずUNDO表領域が使用されます。
UNDO_RETENTION初期化パラメータを、UNDOが、最長の問合せが時間内に戻り成功することが可能な期間保持されるか、人為的エラーからリカバリすることが可能となる値に設定します。
期限切れ前のUNDOが上書きされないよう保証するには、UNDO表領域でRETENTION GUARANTEE句を設定します。
フラッシュバック表でも、表のリカバリのためにUNDOデータが利用されます。自動UNDO管理の有効化が推奨されます。UNDO_RETENTIONパラメータは、フラッシュバック表が必要とされる期間に設定してください。指定された表に、フラッシュバック表の後の必須データが含まれていない場合、十分なUNDOデータがあるならば、表をさらにフラッシュバックする、フラッシュフォワードする、あるいは元の状態に戻すことができます。
|
関連項目:
|
次の優先項目を参考にディスク・バックアップ計画を決定してください。
バックアップ時間全体
リソース使用量への影響
バックアップによる使用領域
リカバリ時間
表7-3では、環境ごとに異なる優先項目に対応する様々なバックアップの選択肢を比較しています。表7-3をガイドとして使用することで、現在の特定のビジネス要件に最適なバックアップ・アプローチを選択できます。リカバリ時間を犠牲にする一方で、バックアップ領域を最小化することが可能です。または、領域を考慮せずに、リカバリ時間とバックアップ時間を優先することも可能です。
| バックアップ・オプション | バックアップ時間全体 1: 最も速い 5: 最も遅い |
リソース使用量への影響 1: 最小 5: 最大 |
バックアップによる使用領域 1: 最小 5: 最大 |
リストア時間 1: 最も速い 5: 最も遅い |
|---|---|---|---|---|
|
推奨リカバリ・アプライアンス・バックアップ計画 |
1 |
1 |
1 (圧縮形式で格納されたバックアップ) |
2 |
|
5 |
5 |
5 |
1 リストアなし(高速リカバリ領域コピーに切替え) |
|
|
4 |
4 |
3 |
3 |
|
|
1 |
1 |
1 |
5 |
|
|
2 |
2 |
2 |
4 |
|
|
3 |
1 |
5 |
1 リストアなし(高速リカバリ領域コピーに切替え) |
ディスクへのバックアップ: リカバリ時間を最適化するためのベスト・プラクティス リストア時間が主な検討課題の場合、データベース・コピーを実行するか、増分のコピーへの即時適用を行う増分バックアップを実行します。即座に使用できるデータベースのバックアップを提供するのはこれらのオプションのみであり、最後の増分バックアップが実行された後に作成されたアーカイブ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を削減できます。
|
関連項目: データベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
Recovery Manager (RMAN)は、Oracleデータベースの自動ディスク・バックアップを提供し、テープへのバックアップのためにOracle Secure Backupなどのメディア管理製品と統合されています。ユーザーのOracleデータベース・バックアップ計画がディスク、テープ、あるいはその両方のどれを使用する場合でも、RMANとOracle Secure Backupの組合せはユーザー固有の要件に対応する包括的なソリューションを実現します。
Oracle Secure Backupをインストールすると、RMANテープ・バックアップに対するSystem Backup Tape (SBT)ライブラリが自動的にリンクされます。Oracle Enterprise Manager Database Controlを使用すると、Oracle Secure Backupバックアップ・ドメインをテープ・ボールティングからバックアップおよびリストア操作まで管理できます。RMAN、Oracle Enterprise Manager Database ControlおよびOracle Secure Backupが緊密に統合されているため、初期構成はシンプルなプロセスです。
初期構成を実行し、データベースのテープへのバックアップの準備をするため、次の4つの手順を実行します。
Oracle Enterprise Manager Database ControlでOracle Secure Backup Administrative Serverを定義して、Oracle Secure BackupドメインをOracle Enterprise Managerから管理できるようにします。
RMANで使用するOracle Secure Backupユーザーを事前認可します。これによって、Oracle Secure Backupに明示的にログインしなくても、RMANのバックアップ/リストアを実行できるようになります。
RMANバックアップについて使用されるメディア・ポリシーをOracle Secure Backupで設定します。
並列処理および圧縮などのRMANバックアップ設定を決定します。
|
注意: Oracle Secure Backupまたはテープ側圧縮を使用する場合、RMAN圧縮も使用することは避けてください。 |
|
関連項目: Recovery ManagerのOracle Secure Backupとの使用方法の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。 |
テープに保存されたバックアップ・データが一度不要になれば、そのライフサイクルは終了し、テープ・メディアは再利用できます。テープのライフサイクル(保存期間)中の管理要件には、複製と、複数の保存場所におけるボールティングが含まれます。Oracle Secure Backupは、次のようなユーザー定義メディア・ポリシーによって効率的なメディア・ライフサイクル管理を提供します。
保存
テープの複製
ボールティング: 複数の保存場所間のテープのローテーション
メディア・ライフサイクル管理は、適切な保存設定の定義のように単純な場合もあれば、元のテープと同じ複製、または異なる保存期間およびボールティング要件による複製のように複雑になる場合もあります。Oracle Secure Backupメディア・ファミリ(通例ではテープ・プールと呼ばれます)は、メディア・ライフサイクル管理の基盤を提供します。
推奨されるベスト・プラクティスは、データベースに関連付けられた定義済のRMAN保存パラメータを使用するコンテンツ管理メディア・ファミリを利用して、テープ(効率的には期限切れのテープ)を再利用できる時期を判断することです。特定の有効期限は、時間管理と関連付けられるようにコンテンツ管理テープとは関連付けられていません。これらのテープの期限切れまたはリサイクルは、テープ上のバックアップ・イメージと関連付けられた属性に基づいています。コンテンツ管理テープに自動的に書き込まれたすべてのバックアップ・イメージには、関連付けられたコンテンツ管理再利用の属性があります。コンテンツ管理テープのリサイクルはユーザー定義のRMAN保存設定に従うため、バックアップ・イメージ属性をいつ「削除済」に変更するかは、RMANによってOracle Secure Backupに示されます。
RMANのDELETE OBSOLETEコマンドは、ユーザー定義のRMAN保存期間には不要になったバックアップ・ピース(イメージ)はどれかを伝達します。Oracle Secure Backupがこの通信を受け取ると、バックアップ・イメージ属性は「削除済」に変更されます。実際のバックアップ・イメージは削除されませんが、Oracle Secure Backupカタログ内の属性は更新されます。テープ上のすべてのバックアップ・イメージが削除済という属性になると、Oracle Secure Backupでは、有効期限管理テープと同様に、このテープが再利用可能であると判断されます。
Oracle Secure Backupは、ユーザー定義のDatabase Backup Storage Selectorsを通して、RMANバックアップ操作に対するポリシーベースのメディア管理を提供します。1つのDatabase Backup Storage Selector (SSEL)が複数のデータベースに適用されたり、複数のSSELが1つのデータベースに関連付けられる場合があります。たとえば、RMAN複製の使用時に1つのデータベースに対して2つのSSELを作成し、それぞれのコピーが異なるメディア・ファミリに書き込まれる場合があります。SSELには、次の情報が含まれます。
データベース名/ ID、またはすべてのデータベースに適用可
ホスト名、またはすべてのホストに適用可
コンテンツ: アーカイブ・ログ、完全、増分、自動バックアップ、またはすべてに適用可
RMANコピー番号(RMAN複製が構成済の際に適用可)
メディア・ファミリ名
操作が制限されるデバイスの名前(デバイス制約が構成されていない場合、Oracle Secure Backupは任意の使用可能デバイスを使用)
使用可能なテープ・リソースに対する待機時間(期間)
暗号化設定
Oracle Secure BackupはSSEL内で定義されたストレージ選択を自動的に使用するため、ユーザーが設定することは不要です。1回かぎりのバックアップ操作やその他の例外時にストレージ選択を上書きする場合は、RMANバックアップ・スクリプトで代替的なメディア管理パラメータを定義します。詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。
高速リカバリ領域(FRA)は、RMANコマンド: BACKUP RECOVERY AREAによって簡単にテープにバックアップできます。テープへの本番データベースの個別バックアップを実行するかわりに、このディスクをテープ・バックアップ・メソッドに使用すると、次のような明確な利点があります。
高速リカバリ領域(FRA)の最適なバックアップの作成によって、テープですでに保護されている不要なファイルのバックアップが排除されるため、テープの使用量が抑えられます。
ディスクからテープへと必要に応じた、より最適なリストア・インテリジェンスがRMANで有効になります。これ以外の場合では、メディア・タイプに関係なく最新のバックアップからリストアされます。
FRAでは個別ディスク・グループが使用されるため、本番データベース上のI/Oが削減されます。
リストアの際、RMANでは自動的に最適なバックアップが選択され、ディスクまたはテープからリストアされます。必要なバックアップがテープ上にある場合、RMANではリストアされるか、Oracle Secure Backupとの統合によってテープ・メディアから直接データベースがリカバリされます。リカバリに必要なファイルの種類はRMANで熟知されているため、ディスクまたはテープからのリストアは自動化されたプロセスです。
FRAのバックアップや、RMAN外部のテープに対するその他のRMANディスクのバックアップは、メディア管理ソフトウェアを使用してディスク領域のファイル・システム・バックアップを実行すれば可能ですが、推奨されません。RMANでテープ・バックアップが認識されていなければ、リストアがエラーを引き起こしやすい手動プロセスになります。
DBAはリストアに必要なファイルを決定する必要があります。
メディア・マネージャ管理者は次に、目的のファイルをテープ・バックアップからディスクの場所にリストアします。
ファイルがディスク上にリストアされたら、DBAはRMANのリストアまたはリカバリをディスクの場所から開始します。
RMANとOracle Secure Backupの組合せによって、Oracleデータベースの一体的なテープ・バックアップ・ソリューションが提供されます。
|
関連項目: 高速リカバリ領域の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。 |
バックアップ・テープは携帯性に優れているため、しばしば、障害回復を目的としてオフサイトの場所に保存されます。このようなテープは最初はテープ・デバイス内から作成されますが、ハードウェア・デバイスからは削除されることがほとんどです。バックアップ・テープがハードウェア・デバイスから一度削除されると、テープはオンサイトまたはオフサイトの場所に保存されます。複数の場所におけるテープの移動は、Oracle Secure Backupのローテーション・ポリシーを使用して効率的に管理できます。
Oracleデータベースのリストアの場合、リストア・リクエストはRMANからOracle Secure Backupに送信されます。テープがライブラリ内にある場合、デバイスの可用性が想定されてリストアがすぐに開始します。ただし、リストアに必要なテープがオフサイトに存在する場合、リストア・コマンドを発行する前にテープの場所を確認することが必要です。RMANおよびOracle Secure Backupでは、次のRMANコマンドの発行でこの作業を簡単にできます。
RESTORE DATABASE PREVIEWコマンドは、オフサイトに存在する、リストアに必要なテープのリストを提供します。
RESTORE DATABASE PREVIEW RECALLコマンドは、リストアのためにテープをオフサイトからテープ・デバイスに戻すため、Oracle Secure Backupからリコール操作を開始します。テープがオンサイトに戻ったら、RMANリストア操作を開始できます。
|
関連項目:
|
この項では、データ・リカバリ・アドバイザを使用したデータファイルの破損チェック、リカバリ手順のテスト、およびリカバリ・カタログ・データベースのバックアップを定期的にチェックする手順の概要を示します。
変更対象ではない履歴データは、読取り専用表領域に格納できます。読取り専用表領域を1回バックアップできれば、そのデータファイルに対して追加バックアップは必要ありません。これにより、増分レベル0 (全体)バックアップ中にバックアップする必要があるデータの量を減らすことができます。
データベースにHCCオブジェクトなどの圧縮されたデータが含まれる場合、データをさらに圧縮しようとしてRMAN圧縮を使用しないでください。RMAN圧縮を使用すると、RMANバックアップは通常、IOバウンドではなくCPUバウンドになり、データベースおよび使用されるRMAN圧縮アルゴリズムよっては、バックアップ操作の完了に2から50倍の時間がかかる可能性があります。
RMANセクション・サイズ・オプションを使用すると、同時に処理するためにビッグファイル・データファイルの様々な部分を複数のRMANチャネルに割り当てることで、データベース・バックアップの速度を大幅に上げることができます。
データ・リカバリ・アドバイザは、データ障害を自動的に診断し、適切な修復オプションを判断して提示し、ユーザーの要求に応じて修復を実行するOracle Databaseツールです。ここでは、データ障害とは、ディスク上の永続的データの破損または損失を指します。自動データ修復を行う集中化されたツールを持つデータ・リカバリ・アドバイザを使用すると、Oracleデータベースの管理性と信頼性が向上し、平均リカバリ時間(MTTR)が減少します。
|
関連項目: データ・リカバリ・アドバイザの使用の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
推奨リカバリ・アプライアンス・バックアップ計画を使用している場合、アプライアンスに格納されているデータベース・バックアップの定期チェックが自動的に実行されます。あるいは、RMAN VALIDATEコマンドを使用して、ユーザー・セッションや通常のバックアップ操作によりまだレポートされていないブロック破損が存在しないかどうか、データベース・ファイルを定期的にチェックします。RMANは、指定されたファイルをスキャンして、物理エラーと論理エラーをチェックしますが、実際のバックアップまたはリカバリ操作は実行しません。Oracle Databaseでは、破損ブロックのアドレスと破損タイプが制御ファイルに記録されます。これらのレコードには、V$DATABASE_BLOCK_CORRUPTIONビューを通じてアクセスします(このビューは、RMANのブロック・メディア・リカバリで使用できます)。
検出可能なすべての破損タイプを検出するには、CHECK LOGICALオプションを指定します。
|
関連項目: データベース・ファイルおよびバックアップの検証の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
完全で正常なテスト済のバックアップは、リカバリが成功するための基盤となります。異なる停止タイプに対応するテスト計画を作成してください。最も一般的な停止タイプから始め、最も可能性の低いタイプへと作業を進めます。RMAN DUPLICATEコマンドの使用は、リカバリ・テストを実行するためのよい方法です。バックアップからのリストアと、メディア・リカバリの実行が必要であるためです。
バックアップ手順のエラーを監視し、定期的にリカバリ手順をテストしてバックアップを検証します。また、RMANコマンドRESTORE...VALIDATEを使用して、データベースのリストアの実行可能性を検証します。
|
関連項目:
|
リカバリ・カタログ・データベースは、バックアップおよびリカバリ計画に含めます。リカバリ・カタログのバックアップがない状態でリカバリ・カタログ・データベースを破壊するディスク障害が発生すると、カタログ内のメタデータが失われる可能性があります。リカバリ・カタログの内容がない場合は、その他のデータベースのリカバリがより困難になる可能性があります。
Oracle Zero Data Loss Recovery Applianceにより、RMANカタログはディスクに自動でバックアップされてから、統合Oracle Secure Backupカタログのバックアップに伴いテープにバックアップされます。
リカバリ・アプライアンスが使用されていない場合、Oracle Secure Backupカタログは、バックアップ・ドメインのためのバックアップ・メタデータ、スケジューリングおよび構成の詳細を保持します。RMANカタログまたは制御ファイルの保護が重要であるのと同様に、Oracle Secure Backupカタログも定期的にバックアップする必要があります。
|
関連項目:
|
Oracle Secure BackupはOracle以外のファイル用のテープ・バックアップを提供します。Oracle Secure Backupには、データベースのような予防的なチェック機能はありません。データベース外部のファイルのバックアップに有効な機能を使用してください。詳細は、7.6項「データベース外部のファイルのバックアップ」を参照してください。
Oracle IT環境には、短期および長期の保存要件のために保護することが必要な、データベースとアプリケーション・ファイルの両方が含まれます。データベースと未構成ファイルの各バックアップには差異が存在します。さらに、バックアップとリカバリの管理は、しばしば組織的領域と交わります。たとえば、データベースに対するDBAとファイル・システム・データに対するシステム管理は、組織的領域と交わる場合があります。Oracleのデータ保護スイートは、OracleデータベースとOracle以外のデータベース・ストレージに対する完全なニーズを満たす統合的なソリューションを提供します。
Oracle ACFSスナップショットは、Oracle ACFSファイル・システムのオンライン読取り専用ポイント・イン・タイム・コピーです。スナップショット・コピーは領域使用効率がよく、copy-on-write機能を使用します。Oracle ACFSファイル・エクステントの変更または削除前に、その現行値は、ファイル・システムのポイント・イン・タイム・ビューを保持するスナップショットにコピーされます。
Oracle ACFSスナップショットは、不用意に変更、またはファイル・システムから削除してしまったファイルのオンライン・リカバリをサポートできます。ファイル・システムごとに最高63のスナップショット・ビューがサポートされており、複数のビューにわたる柔軟性のあるオンライン・ファイル・リカバリ・ソリューションを利用できます。Oracle ACFSスナップショットは、アクティブ・ファイル・システムの一貫性のある現行オンライン・ビューを提供するために、要求に応じて作成できるので、ファイル・システム・バックアップのソースとしても使用できます。
|
関連項目:
|
Oracle ZFS Storage Applianceは、一体的な高パフォーマンスのバックアップ・ソリューションを提供し、同時にデータベース以外のファイルの障害回復における費用効果的なプラットフォームともなります。絶え間なく増え続けるデータ量は、システムおよびデータベースの管理者に多くの課題を示します。中でもひときわ困難なのはバックアップおよびリカバリの複雑なプロセスに関わる課題です。データ保護およびプロセスの信頼性が低ければ、ミッションクリティカルなデータがリスクにさらされます。
Oracle ZFS Storage Applianceはデプロイが容易なユニファイド・ストレージ・システムで、障害発生時にタイムリなリカバリが行われることで、バックアップ・ウィンドウとリカバリ時間目標(RTO)が必ず一致するようになります。
Oracle ZFS Storage Applianceは制約のないスナップショット機能をサポートしています。Oracle ACFSに類似したスナップショットは、ファイル・システムの読取り専用のポイント・イン・タイム・コピーです(Oracle ACFSの詳細は、7.6.1項「ACFSスナップショット」を参照してください)。スナップショットは即時作成され、最初は領域が割り当てらません。ベース・ファイル・システムに変更が行われるに従って、ブロックが割り当てられます(copy-on-write)。スナップショットは手動で開始するか、特定の間隔をスケジューリングして自動化することができます。スナップショット・データは、あらゆるバックアップ目的のために直接アクセスできます。スナップショット・ブロックへの読取りはすべて、ベース・ファイル・システムのブロックで提供されます。ベース・ファイル・システムに変更が発生すると、古い方のブロックがスナップショットで参照されるようになり、新しく変更されたブロックがファイル・システムで参照されます。
Oracle ZFS Storage Applianceは、Data Guard環境のスタンバイ・データベースから取得されたスナップショットである、システムの開発およびテストに対しても推奨されます。
スナップショット・ロールバックは、スナップショットが取得されたポイント・イン・タイムにベース・ファイル・システムを戻すプロセスです。ロールバック・プロセスでは、スナップショットの時刻からロールバックの時刻までのベース・ファイル・システムに対する変更がすべて排除されます。これによってデータ・リストア・プロセスが不要になります。
|
関連項目:
|
Oracle Secure Backupでは、異機種のファイル・システム・データやOracleデータベースに対するテープ・バックアップ集中管理機能が提供されます。Oracle Secure Backupは完全、増分および差分などの複数のバックアップ・レベルを提供します。詳細は、7.4項「テープへのバックアップのベスト・プラクティス」を参照してください。さらに、完全なオフサイト・バックアップ・レベルのスケジューリングも可能で、この場合、通常の完全/増分スケジュールが妨害されることはありません。ファイル・システム・バックアップはファイル、ディレクトリまたはファイル・システムで実行が可能で、ユーザー定義バックアップ・ウィンドウ内で最も厳しい要件にも一致するRAWパーティション・レベルでも実行できます。
ファイル・システム・バックアップ操作では、バックアップする対象を記述するOracle Secure Backupのデータセットを定義します。データセットは軽量の言語を採用したテキスト記述で、保護されるファイルの構築および編成方法を伝達します。Oracleデータベースを認識している場合、Oracle Secure Backupは「exclude oracle database files」ディレクティブをデータセット内で使用することで、ファイル・システム・バックアップ中にデータベース・ファイルをスキップできます。
|
関連項目: ファイル・システム・バックアップ操作の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。 |
