機械翻訳について
  1. Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ
  2. Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ

1 Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ

このドキュメントは、Oracle Database ApplianceでOracle Data Guardテクノロジを利用するためのステップ・バイ・ステップ・ガイドを提供します。 スタンバイ・コンピューティング能力を活用しながら本番システムを保護するためのガイドラインを提供します。

Oracle Database Applianceの概要

Oracle Database Applianceは、Oracle Database用のすぐにデプロイ可能な事前構築済のプラットフォームです。

Oracle Database Applianceシステムは、サーバー、ストレージ、ネットワーキングおよびソフトウェアが最適化された構成に含まれる、事前に構築され、事前にチューニングされ、すぐに使用できるクラスタ化されていないクラスタ化されていないデータベース・システムであり、デプロイ、操作および管理が容易になります。 Oracle Database Applianceは、小規模、中規模および大規模のデータベース実装のための完全で理想的なデータベース・プラットフォームであり、世界をリードするOracle Database、ベスト・セルのOracle Real Application Clusters (Oracle RAC)データベース・オプション、Oracle ClusterwareおよびOracle Automatic Storage Management (Oracle ASM)を含む、堅牢で時間テストされたOracleテクノロジを組み込みます。 Oracle Database Applianceは、ハードウェアとソフトウェアを統合することで、統合されていない手作業で組み立てられたデータベース・ソリューションに固有の複雑さを解消し、デプロイメント時間を数週間または数か月から数時間に短縮すると同時に、最適ではなく管理しにくいデータベース環境になることが多い構成や設定のエラーを防止します。

oda_ha_model.pngの説明は以下のとおりです
図oda_ha_model.pngの説明

親トピック: Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ

Oracle Active Data Guardを使用したデータ保護

Oracle Database ApplianceがOracle Active Data Guardを使用してデータ保護を提供する方法を理解します。

Oracle Database Applianceは、それ自体の高可用性システムです。 ただし、スタンバイ・データベース環境はデータ保護を提供し、プライマリ・データベース環境が使用できなくなったり破損したりすると、計画的および計画外の停止時間を短縮できます。 したがって、スタンバイ・データベースは、ミッションクリティカルな本番システムに追加の高可用性とデータ保護を提供するMaximum Availability Architecture (MAA)の不可欠なコンポーネントです。Oracle Maximum Availability Architecture (MAA)のGold Tierベスト・プラクティスを使用すると、スタンバイ・データベースをプライマリ・データベースと同期できるため、データベースのアップグレードや、データ破損、データベース障害、クラスタ障害、停電、自然災害などの計画外停止などの計画メンテナンス・アクティビティにおけるデータベースの停止時間を最小限に抑えることができます。

適切なリカバリ計画を開発および実装するために考慮する必要がある2つのメトリックは、リカバリ・ポイント目標(RPO)とリカバリ時間目標(RTO)です。 Oracle Data Guardは、ミッション・クリティカルなOracle Databasesの単一障害点を排除するために利用可能な最も包括的なソリューションです。 MAA Gold Tierは、本番データベースの同期された物理レプリカをリモートのロケーションに維持することで、最も簡単かつ最も経済的な方法でデータ損失(ゼロRPO)およびダウンタイム(ゼロRTO)を防ぎます。 何らかの理由で本番データベースが使用できない場合、クライアント接続をすばやく実行でき、構成によっては透過的に同期レプリカにフェイルオーバーしてサービスをリストアできます。

Oracle Active Data Guardを使用すると、管理者はプライマリ・データベースから受信した更新を適用しながら、読取り専用でオープンしているフィジカル・スタンバイ・データベースに処理をオフロードすることで、パフォーマンスを向上できます。 Oracle Active Data Guardのオフロード機能には、ときどき書込みまたは更新(Oracle Database 19cではDML Re-direct)を使用した読取り専用レポートとアドホック問合せ(グローバル一時表へのDMLおよび一意のグローバルまたはセッション順序)、データ抽出、高速増分バックアップ、REDO転送圧縮、複数のリモート宛先の効率的なサービス、およびプライマリ・データベースのパフォーマンスに影響を与えることなく、データ損失ゼロの保護をリモート・スタンバイ・データベースに拡張する機能。

Oracle Active Data Guardは、自動ブロック修復を実行し、高可用性アップグレードを有効にすることで、高可用性も向上します(データベースのローリング・アップグレードの自動化を利用して、可用性の高い環境を維持しながら、ダウンタイムを回避します)。 さらに、コミットされていない可能性がある処理中のトランザクションにデータ保護を拡張するアプリケーション継続性も含まれます。 Oracleでは、個別の専用Oracle Database Applianceシステムを使用して、プライマリOracle Database Applianceシステムで実行されているミッション・クリティカルな本番システムのData Guardスタンバイ・システムをホストすることをお薦めします。 MAAのベスト・プラクティスは、ローカル(同期レプリケーション)スタンバイ・データベースを、ある程度の分離レベルを持つ付近のデータ・センターと、非同期レプリケーションによって定期的に保守されるリモート・スタンバイに配置することです。 これにより、大規模な停電などリージョン全体に影響を及ぼす可能性がある災害から保護でき、未計画停止の大部分でRPOをゼロのまま維持できます。

親トピック: Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ

Oracle Data GuardおよびOracle Active Data Guardを使用する利点

Oracle Data Guardは、多くのメリットを提供し、デプロイされたアーキテクチャの効率性と効率性を向上させます。

Oracle Data Guard自体が大幅な保護を提供しているにもかかわらず、MAA Gold TierにはOracle Active Data Guardが必要です。これは、自動ブロック修復、アプリケーション・コンティニュイティおよびDBMS_ROLLINGがないために、Maximum Availability Architecture (MAA)参照アーキテクチャに含まれるRTO/RPOには到達できないためです。

Oracle Active Data Guardを使用する場合、スタンバイ・データベース環境はアイドル状態でも、容量が不足している必要はありません。 かわりに、スタンバイ・データベースは多くの有用な目的をアクティブに処理できます。 これらの追加使用により、全体的な労力と投資対効果が大幅に向上します。

「Oracle Database Applianceへの移行」 - 既存のデータベースをOracle Database Applianceに移行する場合、Oracle Data Guardを使用すると、データベースをOracle Database Applianceに簡単に移行できます。 Oracle Database Applianceにフィジカル・スタンバイ・データベースを設定し、レガシー環境から新しいOracle Database Appliance環境に操作を切り替えることができます。 これには、特定のプラットフォーム間での移行も含まれます。 たとえば、Windowsプラットフォームで現在実行されているデータベースをLinuxプラットフォームであるOracle Database Applianceに移行するには、2つの環境間でOracle Data Guardを設定し、スイッチオーバーを実行できます。 プラットフォーム移行へのこのアプローチにより、なんらかの理由でテスト後に切り替えることができる場合は、柔軟にスイッチバックできます。 My Oracle Support (MOS)ノート413484.1を参照してください: Oracle Data Guardを使用したプラットフォーム移行の詳細は、同じData Guard構成での異機種プライマリおよび物理スタンバイのData Guardサポートを参照してください。

ノート:

Oracle Data Guardでは、一時ロジカル・スタンバイ・データベースを使用して、データベース・バージョン間で移行することもできます。

「ディザスタ・リカバリ」 - Oracle Data Guardフィジカル・スタンバイ・データベースは、障害保護に最適なソリューションを提供します。 災害が発生する最も一般的な例は、リージョンの停電ですが、災害のシナリオは、破水や蒸気管、火災、ハリケーン、破壊、地震、洪水、テロ行為によって異なります。 Oracle Data Guardフィジカル・スタンバイ・データベースは、本番データベースのブロック間コピーを保持します。 何らかの理由でプライマリ環境が使用できなくなった場合、スタンバイ環境を迅速にアクティブ化して、アプリケーションの継続的なデータベース可用性を維持できます。

「高可用性」 - スタンバイ・データベースおよびOracle RACは、計画的および計画外の停止および停止時間における可用性の維持にも役立ちます。 このようなイベントには、構成の変更、ハードウェアの交換、データの破損、ヒューマン・エラーによる障害、その他の予期しないシステム・コンポーネントや完全なシステム障害などが含まれます。

「スタンバイ・ファースト・パッチ適用」 - Oracle Active Data Guardを使用すると、最初にハードウェア、オペレーティング・システム、Oracle Grid Infrastructureおよび適格なデータベース・ソフトウェア更新を適用することで、スタンバイ・データベースが追加の保護を提供できます。 検証は、プライマリ・データベースでOracle RACローリング方式で同じ変更を適用する前、またはOracle Data Guardロール・トランジションを発行する前に、時間、日、さらには週単位で行われます。 この追加の保護により、パッチの不良、高可用性またはパッチによるパフォーマンスの低下による停止を防止できます。 データベースの唯一の停止時間は、プライマリとスタンバイの間でロールを変更するために必要な短い期間です。 詳細は、My Oracle Support (MOS) note 1265700.1を参照してください: Oracleパッチ保証 - Data Guardスタンバイ・ファースト・パッチの適用.

「データベース・ローリング・アップグレード」 - Active Data Guardおよび一時ロジカル・スタンバイでは、スタンバイ・データベースを使用して、スタンバイでの主要なデータベース・アップグレードなどの非ローリング・ソフトウェア変更を適用してからスイッチオーバーすることで、停止時間を最小限に抑えることができます。 Data Guardのスイッチオーバーにより、停止時間が数秒に最小化されます。 詳細は、技術概要を参照してください: Oracleデータベース12.1以降の場合は、Data Guardを使用したデータベースのローリング・アップグレードおよびOracle Active Data GuardおよびDBMS_ROLLINGを使用したMAA自動データベース・アップグレード。

「自動ブロック修復」 - フィジカル・スタンバイ・データベースの利点の1つは、物理ブロック破損を自動的に修復できることです。 プライマリおよびスタンバイ構成では、破損ブロックを自動的に修復でき、この操作はアプリケーションおよびデータベース管理者に完全にシームレスに実行できます。 ブロック修復機能はOracle Active Data Guardオプションの一部です。

「アプリケーション・コンティニュイティ(AC)」 - この機能は、リカバリ可能な停止の後に処理中のデータベース・セッションをリカバリすることで、エンド・ユーザーおよびアプリケーションからの停止をマスクするOracle Real Application Clusters (RAC)、Oracle RAC One NodeおよびOracle Active Data Guardオプションで使用できます。 停止後に影響を受けるデータベース・セッションの進行中の作業をリカバリすることで、エンド・ユーザーおよびアプリケーションの停止をマスクします。 アプリケーション・コンティニュイティはこのリカバリをアプリケーションの下で実行するため、停止はわずかに遅延した実行としてアプリケーションに認識されます。 アプリケーション・コンティニュイティは、計画外停止と計画メンテナンスの両方のユーザー・エクスペリエンスを向上させます。 これにより、Oracleデータベースを使用するシステムおよびアプリケーションのフォルト・トレランスが強化されます。

「ワークロードおよびアクティビティのオフロード」 - 名前にもかかわらず、スタンバイ環境はアイドル状態である必要はありません。 投資に対する全体的な利益を最大化するために積極的に使用できます。 フィジカル・スタンバイ・データベースを配置すると、いくつかの主要なアクティビティをスタンバイ環境にオフロードできます。 これには、次のものがあります。

  • 「読取り専用ワークロード」 -Oracle Active Data Guardオプションを使用すると、スタンバイ・データベースがスタンバイ・モードになり、プライマリ・データベースからREDOログの更新を受け入れるときに、読取り専用問合せワークロードに対してスタンバイ・データベースをオープンできます。 多くの場合、読取り専用ワークロードをスタンバイ・データベースにオフロードすることで、本番ワークロードを大幅に削減できるため、本番システムの使用可能な全体の容量が増加します。
  • 「バックアップ」 - Oracle Data Guardフィジカル・スタンバイ・データベースはプライマリ・データベースの物理コピーであるため、データベース・バックアップはスタンバイ環境に完全にオフロードでき、これらのバックアップは、障害またはデータベース損失が発生した場合にプライマリ・データベースをリストアおよびリカバリするために透過的に使用できます。 Oracle Active Data Guardオプションのライセンスがある場合、高速増分バックアップをスタンバイ・データベースで実行でき、さらにバックアップをスタンバイ・データベースにオフロードする手間がかかります。
  • 「スナップショット・スタンバイ」 - スナップショット・スタンバイ・データベースは、更新可能なスタンバイ・データベースで、プライマリ・データベースの完全なデータ保護を提供します。 プライマリからのREDOデータの受信は続行されますが、テスト目的でスタンバイ・データベースが読取り/書込み操作のためにオープンされている間は、適用プロセスが停止されます。 テストが完了すると、1つのコマンドはスタンバイ・データベースを元の状態に戻し、読取り/書込みモードでオープン中に行われた変更を破棄し、累積REDOログを適用してプライマリ・データベースの現在の状態と同期します。

関連項目

親トピック: Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ

Oracle Database ApplianceでOracle Data Guardを構成するためのベスト・プラクティス

この項では、Oracle Database ApplianceでOracle Data Guardを設定するためのベスト・プラクティスについて説明します。

Oracle Database Applianceベア・メタルおよびDBシステムの構成

Oracle Database Applianceは、KVMおよびDBシステムのサポートを備えたベア・メタル・プラットフォームとして構成できます。 Data Guard構成とODACLIの統合は、ベア・メタルおよびDBシステムのデプロイメントで優先される方法です。 ただし、この技術概要で概説されている手動のOracle Data Guardフィジカル・スタンバイ設定プロセスは、Oracle Database Applianceベア・メタル・システムとDBシステムの両方で使用できます。

Oracle Real Application Clusters (Oracle RAC)およびOracle Data Guardは、Oracle Maximum Availability Architecture (MAA)の基本的な必須コンポーネントです。 Oracle Database Appliance X6-2 S|M|L、X7-2 S|M、X8-2 S|Mハードウェア・モデル(小さい単一ノード構成)の間にOracle Data Guard構成を設定することもできますが、Oracle Real Application Clusters (Oracle RAC)はOracle Database Appliance高可用性ハードウェア・モデル(X5-2、X6-2 HA、X7-2 HA、およびX8-2 HA)でのみ実行されるため、このような構成はMAAのガイドラインに準拠しません。

Oracle Data Guardを使用すると、Oracle Database Applianceの初期デプロイメントから効果的なディザスタ・リカバリ保護戦略を即時にデプロイできます。 Oracle Data Guardフィジカル・スタンバイ環境は、ディザスタ・リカバリ・ソリューション以外に複数の目的で使用できます。 この技術概要で概説されているフィジカル・スタンバイ構成および設定プロセスは、迅速でシンプルであり、プライマリ・データベースで発生する停止時間なしで完了できます。 スタンバイ作成ステップのほとんどは、odacli、Oracle RMAN、Oracle Data Guard Brokerなどのツールを使用して自動化されています。

Oracle Database Appliance環境にも適用される一般的なOracle Data Guardベスト・プラクティスの完全なリストについては、https://www.oracle.com/database/technologies/high-availability/oracle-database-maa-best-practices.htmlにあるOracle Maximum Availability ArchitectureおよびOracle Data Guardのベスト・プラクティスを参照してください。

「最新のOracle Database Applianceリリースへのアップグレード」- データベース関連のメタデータの同期など、Oracleリリースで機能を変更できます。 バックアップおよびその他の一部の機能は、Oracle Database Applianceツールでは、スタンバイ・データベースの最新メタデータがないと機能しない場合があります。 Oracle Database Applianceリリース19.8以降では、Oracle Data GuardはOracle Database Applianceと統合されています。 ODACLIコマンドを使用して、別のOracle Database ApplianceでOracle Data Guardをすばやく設定および管理できます。

「プライマリおよびスタンバイ・データベース構成に一致」 - 一貫したサービス・レベルを維持し、プライマリ・データベースとスタンバイ・データベースを透過的に使用するには、プライマリ・システムとスタンバイ・システムのリソース、設定および構成を一致させることが重要です。 プライマリ・データベース構成とスタンバイ・データベース構成が大きく異なると、ロールが遷移したときにパフォーマンスが最適ではなく、予期しない動作が発生する可能性があります。 具体的には、次の推奨事項を考慮する必要があります:

  • 「プライマリ・データベースとスタンバイ・データベースを別々のOracle Database Appliancesで実行」 - プライマリ・データベースとスタンバイ・データベースは、地理的に離れたロケーションにある個別の専用Oracle Database Applianceユニットで実行することをお薦めします。
  • 「同じ構成でプライマリ・データベースとスタンバイ・データベースを実行」 - Oracle Database Applianceでは、Oracle RACデータベース、Oracle RAC Oneおよび単一インスタンスのEnterprise Editionデータベースの3つの異なるデータベース構成がサポートされています。 スタンバイ・データベースは、プライマリ・データベースと同じ構成タイプである必要があります。 したがって、プライマリ・データベースがOracle RACデータベースとして構成されている場合は、スタンバイ・データベースもOracle RACデータベースとして構成する必要があります。
  • 「プライマリ・サイトとスタンバイ・サイト間の対称性の維持」 - プライマリ・データベースとスタンバイ・データベースのインスタンスは、メモリー、CPU、ネットワークおよびストレージなどのデータベース・パラメータ設定の観点から相互に構成する必要があります。 これにより、データベース・スイッチのロールで予測不能性が回避されます。 また、オペレーティング・システム構成のカスタマイズはすべて、2つの環境でミラー化する必要があります。
  • 「プライマリ・データベースとスタンバイ・データベースの両方でのフラッシュバック・データベースの構成」 - フラッシュバック・データベース機能を使用すると、迅速なロール移行が可能となり、移行後にデータベース・ロールを再確立するために必要な労力が軽減されます。 ベスト・プラクティスとして、フラッシュバック・データベースはプライマリ・データベースとスタンバイ・データベースの両方で構成する必要があります。 FLASHBACKが再インスタンス化のためにのみ必要であるとみなされる場合は、保存時間をデフォルトの24時間から2時間に短縮することをお薦めします。 Oracle Database 19cリリースでは、すべてのリストア・ポイントがスタンバイ・データベースに自動的に伝播されることに注意してください。 Oracle統合Data Guard機能では、フラッシュバック・データベースが自動的に構成されます。
  • 「スタンバイ・トラフィックに専用ネットワークを使用」 - Oracle Database Applianceには、複数の冗長ネットワーク・インタフェースが事前に構築されています。 必要に応じて、スタンバイ・トラフィック用に別のネットワーク・パスを構成して、ユーザーおよびアプリケーション関連のワークロードに対するパフォーマンスへの影響を最小限に抑えることができます。 Oracle Data Guardはプライマリ・データベースに対する変更のみをプライマリ・データベースからスタンバイ・データベースに転送する必要があるため、不要な要件がネットワークに必要以上に課されることはありません。 したがって、Oracle Data Guardのデプロイメントの多くでは、プライマリとスタンバイ間のREDOログ転送に個別のネットワーク・パスが必要ない場合があります。 ただし、大量のアプリケーションや組織のベスト・プラクティスおよび標準によっては、REDOログの転送に個別のネットワーク・パスが必要になる場合があります。 Oracle Database Applianceは、この目的で使用できる各サーバー・ノードに追加のネットワーク・インタフェースを提供します。 Oracle Database Applianceでの障害リカバリを目的とした専用ネットワークの構成の詳細は、ドキュメントを参照してください。
  • 「Oracle Active Data Guardの使用」 - Oracle Active Data Guardを使用すると、プライマリ環境とスタンバイ環境間でREDO適用が継続的にアクティブのままであるため、近傍現行データの読取り専用スタンバイが可能になります。 これにより、読取り専用ワークロードをプライマリ環境からスタンバイ・データベースに分散またはオフロードし、スタンバイ・データベースへの投資対効果を高めることができます。 Oracle Active Data Guardを使用すると、高速増分バックアップをスタンバイ・データベースで実行できます。 高速増分バックアップによって、バックアップ期間が数時間から数分に短縮される可能性があります。 ローリング・アップグレードは、スタンバイ・データベースを使用して実行することもできるため、停止時間がほぼゼロに短縮されます。 また、リアルタイム適用のActive Data Guardにより、双方向自動ブロック破損修復が可能になり、ミッション・クリティカルなアプリケーションのデータ保護の別のレイヤーが提供されます。
  • 「Oracle Data Guardブローカの使用」 - Oracle Data Guard Brokerのインタフェースにより、使いやすさが向上し、Oracle Data Guard構成の管理とモニタリングが一元化されます。 全体的な管理を最小限に抑え、Oracle Data Guard構成の固有のチェックおよび残高があります。
  • 「Oracle Clusterwareロールベースのサービスの設定」 - 「高可用性Oracle Databasesのクライアント・フェイルオーバーのベスト・プラクティス」を参照してください。

詳細は、このドキュメントのトピック「Oracle Database Applianceリファレンス」を参照してください。

親トピック: Oracle Data Guardを使用したOracle Database Applianceでの障害時リカバリ