Oracle Autonomous Database on Dedicated Exadata Infrastructureの場合のOracle MAA

デフォルトの高可用性オプションを使用したAutonomous Database Dedicated (MAA Silver)

高可用性は、稼働時間の要件が厳しく、データ損失の許容範囲がゼロであるか小さいすべての開発、テストおよび本番データベースに適しています。

デフォルトでは、Autonomous Databaseは高可用性であり、局所的なソフトウェア障害とハードウェア障害から保護するためのマルチノード構成が組み込まれています。

それぞれのAutonomous Databaseアプリケーション・サービスは、少なくとも1つのOracle Real Application Clusters (Oracle RAC)インスタンスに配置され、計画外停止または計画メンテナンス・アクティビティの際に別の使用可能なOracle RACインスタンスにフェイルオーバーするオプションを備えており、ゼロまたはゼロに近い停止時間を実現します。

Autonomous Databaseの自動バックアップはOracle Cloud Infrastructure Object Storageに格納され、使用可能な別のドメイン(存在する場合)にレプリケートされます。Exadata Cloud at Customerを使用するAutonomous Databaseの場合は、NFS、Oracle Cloud Infrastructure Object StorageまたはZero Data Loss Recovery Appliance (ZDLRA)にバックアップするというオプションがあります。ただし、NFSまたはZDLRAでのこれらのバックアップのレプリケーションはお客様の責任となります。

自動バックアップは、様々なバックアップ保持ポリシー/期間、またはオンデマンド手動バックアップ(長期バックアップを含む)を使用して設定できます。障害発生時には、これらのバックアップを使用してデータベースをリストアできます。「専用Exadataインフラストラクチャ上のAutonomous Databaseのバックアップおよびリストア」を参照してください

1か月当たりの稼働時間に関するサービスレベル目標(SLO)は99.95% (1か月当たり最大22分の停止時間)です。ほぼ毎月停止時間ゼロであるアプリケーション稼働時間SLAを達成するには、「シームレスなアプリケーション・フェイルオーバーのためのアプリケーションの準備」を参照してください。

次の表は、様々な停止のリカバリ時間目標およびリカバリ・ポイント目標(データ損失の許容範囲)を示しています。

表33-1 Autonomous Database Dedicatedの場合のデフォルトの高可用性ポリシーのリカバリ時間(RTO)およびリカバリ・ポイント(RPO)に関するサービスレベル目標

障害およびメンテナンス・イベント	データベースの停止時間	サービスレベルの停止時間(RTO)	潜在的なサービス・レベルのデータ損失(RPO)
次のものを含む、局所的なイベント: Exadataクラスタ・ネットワーク・トポロジの障害ストレージ(ディスクおよびフラッシュ)の障害データベース・インスタンスの障害データベース・サーバーの障害ソフトウェアおよびハードウェアの定期的なメンテナンス更新	ゼロ	ほぼゼロ	ゼロ
スタンバイ・データベースが存在しないため、バックアップからのリストアを必要とするイベント: データ破損人的エラーデータベース全体の障害全面的なストレージ障害マルチADリージョンの可用性ドメイン(AD)	数分から数時間 (Autonomous Data Guardなし)	数分から数時間 (Autonomous Data Guardなし)	Autonomous Database on Dedicated Infrastructure (Autonomous Data Guardなし)の場合、15分
非ローリング・ソフトウェア更新またはデータベース・アップグレードを必要とするイベント	Autonomous Database on Dedicated Infrastructureの場合、数分から1時間 (Autonomous Data Guardなし)	Autonomous Database on Dedicated Infrastructureの場合、数分から1時間 (Autonomous Data Guardなし)	ゼロ

障害およびメンテナンス・イベント

データベースの停止時間

サービスレベルの停止時間(RTO)

潜在的なサービス・レベルのデータ損失(RPO)

次のものを含む、局所的なイベント:

Exadataクラスタ・ネットワーク・トポロジの障害
ストレージ(ディスクおよびフラッシュ)の障害
データベース・インスタンスの障害
データベース・サーバーの障害
ソフトウェアおよびハードウェアの定期的なメンテナンス更新

ゼロ

ほぼゼロ

ゼロ

スタンバイ・データベースが存在しないため、バックアップからのリストアを必要とするイベント:

データ破損
人的エラー
データベース全体の障害
全面的なストレージ障害
マルチADリージョンの可用性ドメイン(AD)

数分から数時間

(Autonomous Data Guardなし)

数分から数時間

(Autonomous Data Guardなし)

Autonomous Database on Dedicated Infrastructure (Autonomous Data Guardなし)の場合、15分

非ローリング・ソフトウェア更新またはデータベース・アップグレードを必要とするイベント

Autonomous Database on Dedicated Infrastructureの場合、数分から1時間

(Autonomous Data Guardなし)

Autonomous Database on Dedicated Infrastructureの場合、数分から1時間

(Autonomous Data Guardなし)

ゼロ

上の表において、バックアップからのリストアを必要とするイベントの停止時間は、障害の性質によって異なります。最も楽観的なケースでは、物理的なブロック破損が検出され、ブロック・メディア・リカバリを使用してブロックが数分で修復されます。この場合、影響を受けるのはデータベースのごく一部のみであり、データ損失はゼロです。より悲観的なケースでは、データベースまたはクラスタ全体で障害が発生し、すべてのアーカイブを含む最新のデータベース・バックアップを使用して、データベースがリストアおよびリカバリされます。

データ損失は、最後に成功したアーカイブ・ログ・バックアップによって制限されます。この頻度は、専用Exadataインフラストラクチャ上のAutonomous Databaseの場合は15分ごとです。アーカイブ・ログまたはREDOログは、Oracle Cloud Infrastructure Object Storage、または専用Exadataインフラストラクチャ上のサポートされているAutonomous Databaseのバックアップ先にバックアップされます。データ損失は数秒間となるか、または最悪の場合は、最後に成功したアーカイブ・ログと、バックアップ保存先にアーカイブされなかったオンラインREDOログ内の残りのREDOの前後における、数分間のデータ損失となる可能性があります。

組込みのExadata HAの利点とOracle Cloud Infrastructureの冗長性によって、あらゆるローカル障害によるデータベース停止時間がゼロになります。また、アプリケーションのブラウンアウトはほぼゼロまたは10秒未満です。ソフトウェアおよびハードウェアのメンテナンス更新では、オンライン更新、Oracle RACローリング更新およびアプリケーション・フェイルオーバーのベスト・プラクティスによってデータベース停止時間がゼロになり、アプリケーションへの影響がゼロになる可能性があります。「シームレスなアプリケーション・フェイルオーバーのためのアプリケーションの準備」を参照してください。

Autonomous Data Guardオプションを使用したAutonomous Database Dedicated (MAA Gold)

Autonomous Data Guardは、データの破損による障害やデータベースまたはサイトの障害に対する稼働時間の要件がより厳しく、同時にAutonomous Databaseの高可用性オプションの利点も求められるミッションクリティカルな本番データベースについて有効化します。また、読取り専用のスタンバイ・データベースにより、レポート作成、問合せ、および一部の更新をオフロードするための拡張されたアプリケーション・サービスが提供されます。

フィジカル・スタンバイ・データベースをスナップショット・スタンバイに変換することもできますが、それは、特定のスタンバイにスイッチオーバーまたはフェイルオーバーする必要がある場合にリカバリ時間目標(RTO)に影響します。

Autonomous Data Guardを有効にすると、同じ可用性ドメイン、別の可用性ドメインまたは別のリージョンに配置されたExadataラックに、対称スタンバイ・データベースが1つ追加されます。プライマリ・データベース・システムとスタンバイ・データベース・システムは、Data Guardのロール・トランジション後にパフォーマンス・サービス・レベルが維持されるように、対称的に構成されます。2つまでのスタンバイ・データベースがサポートされています。

さらに保護するために、一般的なMAA Goldアーキテクチャは、自動フェイルオーバーが有効になっているローカル・スタンバイと、障害時リカバリ用のクロスリージョン・スタンバイからなります。Autonomous Data Guard構成の管理の詳細は、「Autonomous Data Guard構成のステータスの表示」を参照してください

データベースやクラスタの障害について、またはサイト障害についても、バインドされたリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)に関するサービスレベル目標を達成するには、OCIコンソールのAutonomous Data Guard設定で自動フェイルオーバーを有効にします(「Autonomous Data Guard設定の更新」を参照)。Autonomous Data Guard設定を更新することで、自動フェイルオーバーのターゲットにするスタンバイを選択できます。

RPO=0またはデータ損失ゼロにする必要がある場合、MAAのお客様は通常は、スタンバイ・データベースが同じ可用性ドメインに、または同じリージョン内の別の可用性ドメインに配置されているローカル・スタンバイをデプロイします。MAAでは、スタンバイを別の可用性ドメイン(使用可能な場合)に配置することをお薦めしています。可用性ドメイン間のラウンドトリップ待機時間は通常は1ミリ秒未満であり、ほとんどの場合、アプリケーションのパフォーマンスへの影響は最小限です。

MAAでは、許容可能なパフォーマンスを確保するために、データ損失ゼロ構成、またはData Guard同期転送モードを使用した最大可用性保護モードを評価することをお薦めしています。RPOがほぼゼロであるか、最小データ損失を許容可能である場合は、任意のスタンバイ・データベースを選択して自動フェイルオーバーを有効にし、自動フェイルオーバーの開始前に、バインドされた最大データ損失に対してファスト・スタート・フェイルオーバーのラグ制限を構成できます。

ターゲットがクロスリージョン・スタンバイであり、リージョンをまたいだ障害時リカバリ・オーケストレーションが必要な場合、MAAでは、データベースとアプリケーション、また場合によってはネットワークDNSのフェイルオーバー操作およびスイッチオーバー操作を調整するために、適用可能な場合はOCI Full Stack Disaster Recoveryサービスを有効にすることをお薦めしています。専用Exadataインフラストラクチャ上のAutonomous DatabaseでのOCI Full Stack Disaster Recoveryの使用を参照してください。

バックアップ

バックアップは、スタンバイ・データベースに対して自動的にスケジュールされ、Oracle Cloud Infrastructure Object Storageに格納されます。

Exadata Cloud at Customerを使用するAutonomous Databaseでは、NFS、Oracle Cloud Infrastructure Object StorageまたはZero Data Loss Recovery Applianceにバックアップするというオプションが用意されています。ただし、これらのバックアップのレプリケーションは、お客様の責任となります。プライマリ・データベースとスタンバイ・データベースの両方が失われる二重障害が発生したときには、これらのバックアップを使用してデータベースをリストアできます。

自動バックアップは、様々なバックアップ保持ポリシー/期間、またはオンデマンド手動バックアップ(長期バックアップを含む)を使用して設定できます。「専用Exadataインフラストラクチャ上のAutonomous Databaseのバックアップおよびリストア」を参照してください。

Autonomous Data Guardのリカバリ時間(RTO)およびリカバリ・ポイント(RPO)に関するサービス・レベル目標

1か月当たりの稼働時間に関するサービスレベル目標(SLO)は99.995% (1か月当たり最大132秒の停止時間)であり、下の表に記載されているように、リカバリ時間目標(停止時間)とリカバリ・ポイント目標(データ損失)は低くなっています。

ほぼ毎月停止時間ゼロであるアプリケーション稼働時間SLAを達成するには、「シームレスなアプリケーション・フェイルオーバーのためのアプリケーションの準備」を参照してください。ターゲットの稼働時間SLOである99.995は、プラガブル・データベースが25個未満であるコンテナ・データベースに適用され、スタンバイへの自動フェイルオーバーのためのデフォルトの検出時間である30秒は含みません。

障害およびメンテナンス・イベント	サービスレベルの停止時間(RTO)¹	潜在的なサービス・レベルのデータ損失(RPO)
次のものを含む、局所的なイベント: Exadataクラスタ・ネットワーク・ファブリックの障害ストレージ(ディスクおよびフラッシュ)の障害データベース・インスタンスの障害データベース・サーバーの障害プライマリまたはスタンバイでの定期的なソフトウェアおよびハードウェア・メンテナンス更新	ゼロまたはほぼゼロ	ゼロノート: メンテナンスは、通常は最初にスタンバイで適用されます。データベース・ソフトウェアの更新の場合は、スタンバイのソフトウェアが最初に適用され、約1週間後にプライマリのデータベース・ソフトウェアが更新されます。
次のものを含む、Autonomous Data Guardを使用してスタンバイ・データベースにフェイルオーバーする必要があるイベント: データ破損(Active Data Guardには物理的な破損に対する自動ブロック修復が含まれているため2、フェイルオーバー操作は、論理的な破損または広範囲に及ぶデータ破損についてのみ必要です) データベース全体の障害全面的なストレージ障害可用性ドメインまたはリージョンの障害3	数秒から2分⁴	最大可用性保護モード(同期REDO転送を使用)ではゼロ。リージョン内スタンバイ・データベースで最もよく使用されます。最大パフォーマンス保護モード(非同期REDO転送を使用)ではほぼゼロ。リージョン間スタンバイ・データベースで最もよく使用されます。リージョン内スタンバイ・データベースにも、アプリケーションへの影響をゼロにするために使用されます。RPOは、通常は10秒未満です。RPOは、プライマリ・クラスタとスタンバイ・クラスタの間のネットワーク帯域幅およびワークロード・スループットによって影響を受ける可能性があります。

障害およびメンテナンス・イベント

サービスレベルの停止時間(RTO)¹

潜在的なサービス・レベルのデータ損失(RPO)

次のものを含む、局所的なイベント:

Exadataクラスタ・ネットワーク・ファブリックの障害
ストレージ(ディスクおよびフラッシュ)の障害
データベース・インスタンスの障害
データベース・サーバーの障害
プライマリまたはスタンバイでの定期的なソフトウェアおよびハードウェア・メンテナンス更新

ゼロまたはほぼゼロ

ゼロ

ノート:

メンテナンスは、通常は最初にスタンバイで適用されます。データベース・ソフトウェアの更新の場合は、スタンバイのソフトウェアが最初に適用され、約1週間後にプライマリのデータベース・ソフトウェアが更新されます。

次のものを含む、Autonomous Data Guardを使用してスタンバイ・データベースにフェイルオーバーする必要があるイベント:

データ破損(Active Data Guardには物理的な破損に対する自動ブロック修復が含まれているため2、フェイルオーバー操作は、論理的な破損または広範囲に及ぶデータ破損についてのみ必要です)
データベース全体の障害
全面的なストレージ障害
可用性ドメインまたはリージョンの障害3

数秒から2分⁴

最大可用性保護モード(同期REDO転送を使用)ではゼロ。リージョン内スタンバイ・データベースで最もよく使用されます。

最大パフォーマンス保護モード(非同期REDO転送を使用)ではほぼゼロ。リージョン間スタンバイ・データベースで最もよく使用されます。リージョン内スタンバイ・データベースにも、アプリケーションへの影響をゼロにするために使用されます。RPOは、通常は10秒未満です。RPOは、プライマリ・クラスタとスタンバイ・クラスタの間のネットワーク帯域幅およびワークロード・スループットによって影響を受ける可能性があります。

¹ サービス・レベルの停止時間(RTO)では、自動フェイルオーバーの開始前にソースにアクセスできないようにするために、複数のハートビートを含む検出時間が除外されます。

² 物理的な破損用のActive Data Guard自動ブロック修復機能は、Autonomous Data Guard on Dedicated Infrastructureでのみ使用可能です。

³ リージョンの障害保護は、スタンバイが別のリージョンにある場合にのみ使用できます。

⁴ バックエンドのAutonomous Data Guardロール・トランジションのタイミングは、クラウド・コンソールのリフレッシュ率で示される時期よりもはるかに早くなります。

Autonomous Database on Dedicated Infrastructureは、MAA Goldの検証と認定を受けています。Autonomous Database on Dedicated Infrastructureは、同じリージョン内のスタンバイ・データベース、および別のリージョン内のスタンバイ・データベースを使用して検証されました。また、前述のSLOは、スタンバイ・ターゲットがプライマリと対称であったときに達成されました。RTOおよびRPOのSLOは、最大1100 MB/秒のREDO率で達成されました。

ワークロードによっては、プライマリ・クラスタまたはスタンバイ・クラスタで、Autonomous Exadata VMクラスタのシステム・リソースをスケーリングする必要がある場合があります。Autonomous Exadata VMクラスタのリソースの管理の手順に従ってください。

Autonomous Data Guard設定の更新

Autonomous Data Guardスタンバイの設定は、構成においてプライマリAutonomous Container Databaseの詳細ページから更新できます。

必要なIAMポリシー:

use autonomous-container-databases

Autonomous Data Guard構成においてプライマリAutonomous Container Databaseの詳細ページに移動します。

手順については、「Autonomous Container Databaseの詳細の表示」を参照してください。
「その他のアクション」から、「Autonomous Data Guardの更新」をクリックします。

「Autonomous Data Guardの更新」ダイアログに、保護モードと自動フェイルオーバーについて現在の設定が表示されます。
このダイアログから次の更新を実行できます:
1. 保護モード: ドロップダウン・リストから「最大パフォーマンス」または「最大可用性」を選択します。
2. 自動フェイルオーバー: RTOおよびRPOをバインドするには、自動フェイルオーバーを有効にする必要があります。
  
  自動フェイルオーバーがまだ有効になっていない場合は、「自動フェイルオーバーの有効化」を選択するとそれを有効にできます。同様に、「自動フェイルオーバーの有効化」の選択を解除して、このAutonomous Data Guard設定に対して自動フェイルオーバーを無効にできます。
  
  スタンバイ・データベースの1つがプライマリ・データベースと同じリージョンにあり、2つ目が別のリージョンにある場合は、ローカル・スタンバイ・データベースが、自動フェイルオーバー・ターゲットとしてリモート・スタンバイよりも優先されます。自動フェイルオーバーを有効にすると、すべてのスタンバイ・データベースが自動フェイルオーバー・ターゲットとみなされます。
  
  ノート:
  Exadata Cloud@Customerデプロイメント上の、クロスリージョンAutonomous Data Guardが設定されているデータベースに対して自動フェイルオーバーを有効にすることはできません。
3. ファスト・スタート・フェイルオーバーのラグ制限: 自動フェイルオーバーが有効になっており、保護モードが最大パフォーマンスである場合、ファスト・スタート・フェイルオーバーのラグ制限値は秒単位で表示されます。デフォルトではこの値は30秒に設定されていますが、5秒から3600秒までの任意の値に変更できます。
変更内容を保存してください。

Autonomous Data Guardのライフ・サイクル管理

自動フェイルオーバーを使用したスタンバイの設定またはスタンバイの追加: 「Autonomous Data Guard構成の管理」を参照してください
転送ラグと適用ラグの監視
1. 「リソース」の下でAutonomous Data GuardグループまたはAutonomous Data Guardアソシエーションを選択すると、Autonomous Data Guardの詳細を表示できます。Autonomous Data Guard表には、ピア・コンテナ・データベース、現在の適用ラグと転送ラグ、状態、最後のロール変更、および作成日に関する情報が表示されます。Autonomous Data Guard構成でのプライマリ・データベースおよびスタンバイ・データベースの管理を参照してください。
2. ApplyLagとTransportLagについてアラームを設定して、スタンバイが同期されておりプライマリ・データベースが保護されていることを確認します。「コンソールの使用」を参照してください
Data Guardロール・トランジションまたはスタンバイの回復: 「Autonomous Data Guard構成の管理」でスイッチオーバーまたはフェイルオーバーのトピックを参照してください
自動フェイルオーバーの通知は、「専用Exadataインフラストラクチャ上のAutonomous Databaseのイベント」にある情報を使用して設定できます

MAAでのAutonomous Data GuardのRTOとRPOの観測結果

次の表では、MAAのテストと評価で99.995のSLOを達成した構成を示します。これは、様々なデータベース停止とクラスタ停止での、何百回ものロール・トランジションの後に達成されました。

プライマリ・クラスタ	スタンバイ・クラスタ	PDB	データ・ファイル	サービス	タイミング(分)
2ノード	2ノード	1	14	2	1:18
2ノード	2ノード	5	50	10	1:20
2ノード	2ノード	25	300	250	1:44
4ノード	4ノード	1	500	12	1:17

Autonomous Data Guardのフェイルオーバーの改善

次の表では、Oracle 23aiでロール・トランジション時間がどのように改善しているかを示します。

単一PDBがある大規模なCDB: Data Guardのフェイルオーバーの改善

プライマリExadata (4ノードRAC)とスタンバイExadata (4ノードRAC) X9の間で構成されたData Guard
PDB1つ、データファイル500個およびサービス12個があるCDBバージョン23.4
実行中のワークロード: ロール・トランジション中のPDBに対するOLTP Swingbench
CDBレベルでのREDO率100MB/秒(ラグなし)

Oracleリリース	クローズしてマウント	期間リカバリ	メディア・リカバリ	プライマリに変換	CDBオープン	PDBオープン+サーバー起動	合計
Oracle 19c (19.22)	00:14	00:17	00:05	00:01	00:06	00:50	01:17
Oracle 23ai (23.4)リリース・ラベル	00:04	00:07	00:08	00:01	00:06	00:07	00:29 (62%低下)

PDBが5個あるCDB: Data Guardのフェイルオーバーの改善

プライマリExadata (2ノードRAC)とスタンバイExadata (2ノードRAC)の間で構成されたData Guard
PDBが5個あるCDBバージョン23.4
5個のPDBにわたり分散された合計50個のデータファイル
サービス10個 - PDBごとに2個
実行中のワークロード: ロール・トランジション中の各PDBに対するOLTP Swingbench
CDBでのREDO率は最大60MB/秒
タイミングに関する改善はすべてコード修正の結果である

Oracleリリース	クローズしてマウント	期間リカバリ	メディア・リカバリ	プライマリに変換	CDBオープン	PDBオープン+サーバー起動	合計
ExaCS Oracle 19c (19.18 +修正)	00:19	00:25	00:05	00:01	00:15	00:24	)1:20
Oracle 23ai (23.4)リリース・ラベル	00:02	00:03	00:01	00:01	00:04	00:04	00:15 (81%低下)

Autonomous Data GuardオプションおよびOracle GoldenGateを使用したAutonomous Database (MAA Platinum)

Autonomous Database on Dedicated Infrastructureを使用したMAA Platinumは構成可能です。GoldenGateおよびアプリケーション・フェイルオーバーの構成は手動であるため、保証されたSLAは提供されません。

MAA PlatinumやNever-Down Architectureでは、ほぼゼロのリカバリ時間目標(RTO、つまり、停止中に発生した停止時間)と、ゼロである可能性があるかほぼゼロのリカバリ・ポイント目標(RPO、つまり、データ損失の可能性)が提供されます。

Autonomous Database on Dedicated Infrastructureを使用したMAA Platinumでは、次のことが実現されます:

RTO = すべてのローカル障害に対してゼロまたはほぼゼロ
RTO = データベース、クラスタまたはサイト障害などの障害に対してゼロまたはほぼゼロ。Autonomous Data GuardまたはOracle GoldenGateレプリカを使用するAutonomous Databaseにアプリケーションをリダイレクトすることで実現されます
ソフトウェア更新とハードウェア更新のための停止時間ゼロのメンテナンス
別のAutonomous Database on Dedicated Infrastructureに存在するアップグレード済のOracle GoldenGateレプリカにアプリケーションをリダイレクトすることで停止時間ゼロでデータベースまたはアプリケーションをアップグレード
RPO = Autonomous Data Guardを使用したAutonomous Databaseで同期REDO転送ありのOracle Data Guard最大可用性保護モードを選択したか最大パフォーマンス保護モードを選択したかに応じてデータ損失ゼロまたはほぼゼロ
Cloud MAA GoldenGate HubおよびOracle GoldenGateのベスト・プラクティスを使用して障害発生後にOracle GoldenGateソース・データベースとターゲット・データベースの間で高速で再同期されRPOがゼロまたはほぼゼロ
データベース障害の発生後に、そのスタンバイ・データベースへの自動フェイルオーバーが、統合されたData Guardファスト・スタート・フェイルオーバー(FSFO)を使用して自動的に実行されます。その後、ロール・トランジションの後に新しいプライマリからOracle GoldenGateソース・データベースとターゲット・データベースの間の自動再同期が再開されます。同期トランスポートの場合、これにより、データ損失は最終的にゼロになります。

前提条件:

GoldenGate競合解決をサポートするには、Autonomous Database on Dedicated InfrastructureでOracle Databaseソフトウェア・リリース19.20以降が実行されている必要があります
Autonomous Data Guardおよび自動フェイルオーバーを使用するAutonomous Databaseは、障害発生後の高速GoldenGate再同期用に構成する必要があります
GoldenGate設定は、Cloud MAAのベスト・プラクティスに従って手動で行う必要があります
使用可能なGoldenGateレプリカまたは新しいプライマリ・データベースへのアプリケーション・フェイルオーバーを構成する必要があります。現在、グローバル・データ・サービス(GDS)は、このアーキテクチャではAutonomous Databaseとともに使用できません。

MAA Platinumソリューションの実装

MAA Platinumソリューションを実現するには、次の手順において参照されている技術概要およびドキュメントを確認し活用します。

Oracle ExadataのOracle MAA Platinum層を確認して、MAA Platinumの利点とユースケースについて理解してください。
1. アプリケーションのニーズに基づいてプライマリ・データベースの場所を決定します。プライマリ・データベースは、Autonomous Database on Dedicated Infrastructure内に配置されます。
2. 障害分離の要件に基づいてスタンバイ・データベースの場所を決定します。
3. Autonomous Data Guardを有効にします。
4. RPOの許容範囲に基づいてAutonomous Data Guard保護モードを選択し、自動フェイルオーバーを設定します。
OracleクラウドでMAA GoldenGate Hubを設定します。
1. すべてのプライマリ・データベース(GoldenGateレプリカ)が同じリージョンにある場合は、「リージョン内のクラウド: MAA Platinumの場合のOracle GoldenGate Hubの構成」を参照してください。
  
  プライマリ・データベース(GoldenGateレプリカ)が2つのリージョンに分散されている場合は、「複数リージョンにわたるクラウド: MAA Platinumの場合のOracle GoldenGate Hubの構成」を参照してください。
2. 双方向レプリケーションと自動競合検出および解決。「Oracle GoldenGate Microservices Architectureの双方向レプリケーションの設定」または最新のOracle GoldenGate 21cドキュメントを参照してください。
データベース、クラスタまたはサイト障害が発生した場合にアプリケーションを自動的にフェイルオーバーできるように、カスタム・アプリケーション・フェイルオーバー・オプションを構成します。

シームレスなアプリケーション・フェイルオーバーのためのアプリケーションの準備

テナンシのAutonomous Databaseリソースにアクセスできるように、Oracle Cloud Infrastructureへのネットワーク接続の信頼性が高いことを確認します。

ガイドラインに従ってAutonomous Databaseに接続します(専用Exadataインフラストラクチャ上のAutonomous Databaseを参照)。アプリケーションは、事前定義されたサービス名に接続し、適切なtnsnsames.oraファイルおよびsqlnet.oraファイルを含むクライアント資格証明をダウンロードする必要があります。要件に合うように、特定のアプリケーション・サービスのdrain_timeout属性を変更することもできます。

計画停止および計画外停止を通して継続的なアプリケーション・サービスを実現する方法の詳細は、「アプリケーションの継続的な可用性の構成」を参照してください。

データベース・インスタンスの再起動が必要なExadata Cloud計画メンテナンス・イベントの場合は、Oracle RACインスタンスの停止前に、Oracleによって自動的に、別の使用可能なOracle RACインスタンスにサービスが再配置されセッションがドレインされます。MAAチェックリストに準拠するOLTPアプリケーションについては、サービスの排出および再配置によってアプリケーションの停止時間がなくなります。

実行時間が長いバッチ・ジョブやレポートなど、一部のアプリケーションでは、ドレイン・タイムアウトを長くしても、ドレインと再配置を正常に実行できない場合があります。そうしたアプリケーションについては、これらのタイプのアクティビティを除外してソフトウェアの計画メンテナンス・ウィンドウをスケジュールするか、計画メンテナンス・ウィンドウの前にこれらのアクティビティを停止することをお薦めします。たとえば、バッチ・ウィンドウ外になるように計画メンテナンス・ウィンドウを再スケジュールしたり、計画メンテナンス・ウィンドウの前にバッチ・ジョブを停止できます。