Oracle Autonomous Database Serverlessの場合のOracle MAA

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

Oracle Autonomous Database Serverlessの高可用性は、稼働時間の要件が厳しくデータ損失の許容度が低いすべてのデータベース環境(開発、テスト、本番)にお薦めしています。

Autonomous Databasesは、デフォルトで、高可用性を有効にしてプロビジョニングされ、局所的な障害から保護するためにマルチノード構成が採用されています。具体的に述べると、Autonomous Database Serverlessでは、Exadata Maximum Availability Architecture (MAA)のベストプラクティスが統合され、オンラインでのOracle RACローリング・ソフトウェア更新がサポートされており、統合されたバックアップとリカバリが含まれ、柔軟なリソース・スケーリングが提供されるため、堅牢で可用性の高い、非常にスケーラブルなサービス基盤が提供されます。

このサービス・アーキテクチャでは、各Autonomous Databaseアプリケーション・サービスが、少なくとも1つのOracle RACインスタンス内に配置されます。この設計により、計画外停止や計画メンテナンスの間に他の使用可能なRACインスタンスに自動フェイルオーバーしやすくなり、停止時間がゼロまたはほぼゼロになります。基盤となるExadataプラットフォームは、特有のデータ保護、ブラウンアウトの影響の低減、パフォーマンスのQoS (MAAの品質)、およびExadata Smartのパフォーマンスに関する利点の実現に大きく貢献しています。

自動バックアップは、外部のOracle Cloud Infrastructure (OCI) Object Storageに格納され、代替の可用性ドメイン(使用可能な場合)にレプリケートされます。これらのバックアップは、データベースのリカバリと障害対策に不可欠です。

統合されたソフトウェア・ライフサイクル・フレームワークにより、主要なデータベース・アップグレードが自動化されて、Autonomous Database Serverlessの必要な停止時間が大幅に短縮されます。

Autonomous Databaseでは、月次稼働時間に関するSLAである99.95% (最大22分の停止時間)が提供されます。より優れたアプリケーション稼働時間を実現するための戦略については、「アプリケーションの継続的な可用性の構成」を参照してください。

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

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

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

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

データ損失は、最後に成功したアーカイブ・ログ・バックアップによって制限されます。この頻度は、Autonomous Database Serverlessの場合には1分です。アーカイブ、およびオンラインREDOログからのREDOは、別のフォルト・ドメイン(使用可能な場合)にあるファイル・ストレージ・サービスにリアルタイムで送信され、さらに、将来のリカバリのためにOracle Cloud Infrastructure Object Storage内の他のリージョン、またはファイル・ストレージ・サービスにリモートで転送されます。データ損失は数秒間となるか、または最悪の場合は、最後に成功したアーカイブ・ログと、外部ストレージに転送されなかったオンラインREDOログ内の残りのREDOの前後における、数分間のデータ損失となる可能性があります。

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

データ破損による障害やデータベースまたはサイトの障害に対する稼働時間の要件がより厳しく、同時にAutonomous Databaseの高可用性オプションの利点を享受する必要がある、ミッションクリティカルな本番データベースに対してAutonomous Data Guardを有効にします。

Autonomous Database Serverlessでは、プラガブル・データベース(PDB)レベルで保護が提供されます。Autonomous Data Guardを有効にすると、同じリージョンまたは別のリージョンに配置されているExadataラックに、対称スタンバイ・データベースが1つ追加されます。プライマリ・データベース・システムとスタンバイ・データベース・システムは、Data Guardのロール・トランジション後にパフォーマンス・サービス・レベルが維持されるように、対称的に構成されます。

Autonomous Database Serverlessでは、複数のスタンバイ・データベースを構成できます。複数スタンバイ構成は、同じリージョン内の1つのローカル・スタンバイ・データベースと、1つ以上のクロスリージョン・スタンバイ・データベースからなります。クロスリージョン・スタンバイ・データベースは、リージョンごとに1つに制限されています。Autonomous Database ServerlessアーキテクチャのMAA Gold認定には、RTOとRPOのサービスレベル目標を達成するために自動フェイルオーバーありで構成されている、同じリージョン内のプライマリ・データベースとローカル・スタンバイ・データベースが含まれています。Autonomous Databaseサービスの代替MAA Goldアーキテクチャは、障害時リカバリのために自動フェイルオーバーおよび1つ以上のクロスリージョン・スタンバイ・データベースを使用して構成されている、同じリージョン内のプライマリ・データベースとローカル・スタンバイ・データベースです。

Oracle Autonomous Data Guardでは、アプリケーション・パフォーマンスへの影響をゼロにするために、デフォルトで非同期REDO転送(最大パフォーマンス・モード)が提供されます。

バックアップは、Autonomous Databasesに対して自動的にスケジュールされ、Oracle Cloud Infrastructure Object Storageに格納されます。プライマリ・データベースとスタンバイ・データベースの両方が失われる複合的な障害が発生した場合は、これらのバックアップを使用してデータベースをリストアできます。

Autonomous Database Serverlessでの自動Data Guardフェイルオーバーでは、スタンバイに自動フェイルオーバーされる前に満たす必要がある、最大データ損失値がサポートされています。データ損失ゼロ・フェイルオーバーは、Autonomous Database Serverlessの場合は保証されていませんが、プライマリ・データベースに障害が発生したときでも、プライマリ・システム・コンテナおよびインフラストラクチャがまだ使用可能な場合は可能です。この場合は、残りのREDOを同じリージョンまたはローカル・スタンバイ・データベースに送信して適用できます。クロスリージョン・スタンバイ・データベースへの自動フェイルオーバーは、OCIコンソールでは使用できません。

どのような場合でも、プライマリ・データベース、クラスタまたはデータ・センターの障害に対して、データ損失のサービス・レベルを保証できるときは、自動Autonomous Data Guardフェイルオーバーが発生します。ターゲット・スタンバイが新しいプライマリ・データベースになり、すべてのアプリケーション・サービスが自動的に有効になります。OCIコンソールには、手動のデータ・フェイルオーバー・オプションが用意されています。手動Data Guardフェイルオーバー・オプションの場合、稼働時間SLAの計算停止時間は、Data Guardフェイルオーバー操作を実行した時点で開始され、新しいプライマリ・サービスが有効化されると終了します。

アプリケーションやビジネスの要件に応じて、データベース・フェイルオーバー・サイトが同じリージョンにあるか、別のリージョンにあるかを選択できます。

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

障害およびメンテナンス・イベント	サービスレベルの停止時間(RTO)1	潜在的なサービス・レベルのデータ損失(RPO)
次のものを含む、局所的なイベント: Exadataクラスタ・ネットワーク・ファブリックの障害 ストレージ(ディスクおよびフラッシュ)の障害 データベース・インスタンスの障害 データベース・サーバーの障害 ソフトウェアおよびハードウェアの定期的なメンテナンス更新	ゼロまたはほぼゼロ	ゼロ
次のものを含む、Autonomous Data Guardを使用してスタンバイ・データベースにフェイルオーバーする必要があるイベント: データ破損 データベース全体の障害 全面的なストレージ障害 可用性ドメインまたはリージョンの障害	数秒から2分2	非同期REDO転送の使用によってほぼゼロ。RPOは、通常は10秒未満です。RPOは、プライマリ・クラスタとスタンバイ・クラスタの間のネットワーク帯域幅およびスループットによって影響を受ける可能性があります。 リージョンの障害保護は、スタンバイが別のリージョンにある場合のみ使用できます。手動フェイルオーバーのタイミングは、少し高い水準であり、検出時間を含みません。

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

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

Autonomous Database Serverlessは検証され、前述のSLOを達成しました。RTOとRPOのSLOは、ターゲットのAutonomous Data Guardプラガブル・プライマリ・データベースが存在するコンテナ・データベース(CDB)全体について、最大300 MB/秒のREDO率を達成しました。

自律型スタンバイ・データベースの追加

Autonomous Database Serverlessでは、同じリージョン内に最大1つのAutonomous Data Guardローカル・スタンバイ・データベース、および使用可能な各リージョンに複数のクロスリージョン・スタンバイ・データベース(リージョンごとに最大1つ)がサポートされています。これらの追加リージョンは、Oracleによって決定されます。プライマリごとに、ローカル・スタンバイ・データベースとクロスリージョン・スタンバイ・データベースを任意の組合せにできます。

プライマリ・データベースと同じリージョン内にスタンバイ・データベースを作成するときは、最大データ損失基準を指定して、データ損失がゼロでない状況のために自動フェイルオーバーを有効にできます。MAA Goldを達成するには、すべての構成において、障害発生時にRTOとRPOの値を低く抑えることができるように、少なくとも1つのローカル・スタンバイ・データベースを自動フェイルオーバーありで構成する必要があります。現在、クロスリージョン・スタンバイ・データベースについては自動フェイルオーバーは提供されていません。

ローカル・スタンバイ・データベースの追加

1. プライマリ・データベースのOCIコンソールの詳細ページにある「Autonomous Database情報」タブで、「ディザスタ・リカバリ」セクションに移動し、「ローカル」行の「アクション・メニュー」(3つのドット)を選択し、「Autonomous Data Guardにアップグレード」を選択します。

   
   
   
   図adbs-local-upgrade-b.pngの説明
   
   

2. 「ディザスタ・リカバリの更新」パネルで、ローカル・リージョンと「Autonomous Data Guard」が選択されていることを確認してから、「送信」を実行します。

   オプションで、「データ損失制限(秒)のある自動フェイルオーバー」で最大データ損失制限を有効にできます。プライマリ・クラスタまたはサイトが失われた場合は、REDOが非同期で送信されるためデータ損失が発生します。そのため、ほとんどのプライマリ・データベース、プライマリ・クラスタ、またはデータ・センター全体に障害が発生した場合のアプリケーションとデータベースの停止時間を短縮するには、ゼロ以外の値を入力することが合理的です。ゼロより大きい値に設定すると、自動フェイルオーバーは、算出されたデータ損失がその制限以下であるの場合のみ発生します。プライマリ・データベースのすべてのREDOにアクセスすることでデータ損失ゼロ・フェイルオーバーが可能な場合は、それが自動的に実行されます。データ損失がその設定よりも大きい場合、自動アクションは発生しません。

クロスリージョン・スタンバイ・データベースの追加

1. プライマリ・データベースのOCIコンソールの詳細ページで、「ディザスタ・リカバリ」タブを選択してから、「ピア・データベースの追加」を選択します。

   
   
   
   図adbs-standby-cross.pngの説明
   
   

2. 「ピア・データベースの追加」パネルで、「リージョン」リストからスタンバイ・データベースの場所を選択し、「追加」を実行します。

   
   
   
   図adbs-cross-region.pngの説明
   
   

   クロスリージョン・スタンバイ・データベースの場合、自動フェイルオーバーのオプションはありません。

   クロスリージョン・スタンバイを追加した後は、スタンバイ・データベース名を選択してその特性をリモート・リージョンに表示できます。

スタンバイ・データベースのリスト

ローカル・スタンバイ・データベースは、OCIコンソールやクライアントを使用して直接アクセスすることはできませんが、プライマリ・データベースの詳細ページの「ディザスタ・リカバリ」セクションに表示されます。

クロスリージョン・スタンバイは、データベース名を選択することでアクセスできる、それ固有のコンソール・ページで管理できます。クロスリージョン・スタンバイも、プライマリ・データベースの詳細ページの「ディザスタ・リカバリ」セクションに表示されます(データベース名にリージョンの略称が付加されています)。

図adbs-standby-listing.pngの説明

プライマリ・データベースの元のリージョンは、"ホーム・リージョン"と呼ばれます。各ホーム・リージョンには、クロスリージョン・スタンバイ・データベースを含めるために1つ以上のリモート・リージョン("バディ・リージョン")が関連付けられています。

適用ラグの監視

ローカル・スタンバイとクロスリージョン・スタンバイの両方のREDOについて、Autonomous Data Guard適用ラグを監視できます。データはほぼリアルタイムで提供されます。表示については、コントロール・プレーンへの収集とアップロードの間に短い遅延があります。また、データは特定のAutonomous DatabaseのみでなくPOD全体に適用されます。

ラグ情報にアクセスするには、OCIコンソールのAutonomous Database詳細ページにある「モニタリング」タブで、「すべてのデータベース・メトリックの表示」を選択します。

図adbs-lag-link.pngの説明

「サービス・メトリック」ページで、「ピア・ラグ」メトリックが表示されるまで下にスクロールします。

表示されているデータベースによって、メトリックでのデータが決まります。プライマリ・データベースを表示している場合、メトリック・データ表示はローカル・スタンバイ用になります。クロスリージョン・スタンバイを表示している場合、メトリック・データ表示はクロスリージョン・スタンバイ用になります。

転送ラグは通常は、ワークロードとピークに応じて、ローカル・スタンバイの場合は10秒未満、クロスリージョン・スタンバイの場合は60秒未満です。

図33-1 ローカル・スタンバイの場合の「ピア・ラグ」

図33-2 クロスリージョン・スタンバイの場合の「ピア・ラグ」

Autonomous Data Guardのロール・トランジション

ローカル・スタンバイ・データベースまたはクロスリージョン・スタンバイ・データベースを、ロール・トランジションのターゲット宛先として使用できます。

ローカル・スタンバイは、スイッチオーバー操作のプライマリ・ターゲットにして、ロール・トランジションの完了後に接続とネットワーク操作の待機時間がさらに発生しないようにする必要があります。

ローカル・スタンバイ・データベースへのスイッチオーバーを実行するには、OCIコンソールで、プライマリ・データベースの詳細ページ(ホーム・リージョン内)にある「ディザスタ・リカバリ」セクションにおいて、次の図で示すように「ローカル」行の「スイッチオーバー」を選択します。

図33-3 ローカル・スタンバイへのスイッチオーバー

「図33-3 ローカル・スタンバイへのスイッチオーバー」の説明

ローカル・スタンバイへのスイッチオーバーに失敗した場合は、クロスリージョン・スタンバイへのスイッチオーバーを実行します。

ノート:

クロスリージョンへのスイッチオーバーは、OCIコンソールで、プライマリ・データベース・ページからではなく、リモート・リージョンのクロスリージョン・スタンバイの詳細ページから開始する必要があります。

リモート(クロスリージョン)スタンバイ・データベースへのスイッチオーバーを実行するには、OCIコンソールで、クロスリージョン・データベースの詳細ページ(リモート・リージョン内)にある「ディザスタ・リカバリ」セクションにおいて、次の図で示すように「ロール」行の「スイッチオーバー」を選択します。

図33-4 クロスリージョン・スタンバイへのスイッチオーバー

「図33-4 クロスリージョン・スタンバイへのスイッチオーバー」の説明

スイッチオーバーに成功すると、「ロール」行のステータスが「スタンバイ」から「プライマリ」に変わります。

手動フェイルオーバー操作およびデータ損失の確認

データベースは共有環境にあり、ご使用の自律型データベースにしかアクセスできないため、問題が影響しているのがデータベースのみであるかPOD全体であるかがわかりません。常に、問題の影響はご使用のデータベースのみに対する局所的なものであるという前提で対応することをお薦めします。

自動フェイルオーバーを有効にしていない場合は、必ず、まずOCIコンソールを使用してスイッチオーバーを試みてください。スイッチオーバーに成功すると、必ずデータ損失はゼロになります。スイッチオーバーに失敗すると、OCIコンソール内のロール・トランジション・オプションが「フェイルオーバー」に変わります。

次の図は、クロスリージョン(リモート)スタンバイの詳細ページの「ディザスタ・リカバリ」セクションを示しています。スイッチオーバーのアクションが成功しなかったため、選択が「フェイルオーバー」になっています。

図adbs-crossregion-failover.pngの説明

この場合は、フェイルオーバー操作によって、使用可能なすべてのREDOが適用されます。ただし、それによってデータ損失ゼロは保証されません。これは、ローカルおよびクロスリージョンの両方のフェイルオーバー操作に当てはまります。

データ損失の確認

手動フェイルオーバー・ジョブごとに、作業リクエストが生成され、コンソールに表示されます。

ローカル・スタンバイへのフェイルオーバーの後のデータ損失の量を確認するには、Autonomous Databaseの詳細ページにある「作業リクエスト」タブに移動します。クロスリージョン・スタンバイの場合は、クロスリージョンの新しいプライマリで「作業リクエスト」を確認します。

フェイルオーバーの作業リクエストを選択し、フェイルオーバー中に発生したデータ損失をレポートしているログ・メッセージを表示します。

図adbs-failover-workrequest.pngの説明

自動フェイルオーバーの通知

自動フェイルオーバーは、ローカル・スタンバイ・データベースの場合のみ提供され、接続損失がプライマリ・データベースに対して検出されるとアクティブ化されます。

Oracleによって、接続マネージャ(CMAN)の接続ログがスキャンされて、接続失敗が検索されます。一定期間(通常は60秒から90秒)について障害が検出され、その期間に正常な接続が見つからなかった場合は、自動フェイルオーバーがトリガーされます。正常な接続が検出されると、そのチェックとタイミングがリセットされます。

自動フェイルオーバーの設定に関係なく、障害が検出されOracleでデータ損失ゼロを保証できる場合は、ローカル・リージョン・スタンバイへのフェイルオーバーが自動的に発生します。

データ損失がゼロでない状況が発生した場合は、Oracleによって、自動フェイルオーバーが有効になっているどうかがチェックされ、潜在的データ損失が、定義されている自動フェイルオーバー損失制限と比較されます。指定されている損失制限よりも潜在的データ損失が少ないと判断された場合は、自動フェイルオーバーが発生します。

ローカル・スタンバイの自動フェイルオーバー・ジョブでは、確認可能な作業リクエストは作成されません。ただし、イベントを作成して、そのフェイルオーバーに関連付けられているデータ損失の表示のみでなく、自動フェイルオーバー操作の開始と終了の通知を受信できます。イベントの作成の詳細は、「Autonomous Databaseイベントに関する通知の受信」を参照してください。通知には、通知が送信される条件を確立するためのルールが必要です。

ローカル・スタンバイの自動フェイルオーバーについて通知を有効にするには:

1. 通知サービスを開きます。

   OCIコンソールで、左上隅にあるハンバーガー・メニューを選択し、「開発者サービス」を選択してから、「アプリケーション統合」の下の「通知」を選択します。

2. 「トピックの作成」を選択し、名前と説明を指定します。

3. その新しいトピックを選択し、「サブスクリプションの作成」を選択します

4. 「サブスクリプションの作成」パネルで、通知タイプ(電子メール、Slack、ページャなど)を選択し、「作成」を選択します。

5. イベント・サービスの「ルール」ページを開きます。

   OCIコンソールで、左上隅にあるハンバーガー・メニューを選択し、「監視および管理」を選択してから、「イベント・サービス」の下の「ルール」を選択します。

6. 「ルール」ページで、「ルールの作成」を選択します。

   1つのルールで複数のイベントについて通知を生成できます。

7. 表示名と説明を指定し、「ルール条件」セクションで、自動フェイルオーバーの開始イベントと終了イベントについて通知するための次の条件を入力します。

   1. ルールのイベントのタイプを設定するには、次の値を使用して最初の条件を構成します:
      • 条件: イベント・タイプ
      • サービス名: データベース
      • イベント・タイプ: Autonomous Container Database - クリティカル
   2. ご使用のテナンシのみにそのルールを限定するには、次の値を使用した条件を追加します:
      • 条件: 属性
      • サービス名: compartmentId
      • 属性値: my.tenancy.id
   3. そのルールで自動フェイルオーバーの開始イベントと終了イベントの通知が送信されるようにするには、次の値を使用した別の条件を追加します:
      • 条件: 属性
      • 属性名: eventName
      • 属性値: AutomaticFailoverBeginとAutomaticFailoverEnd
   
   
   
   図adbs-event-rule.pngの説明
   
   

8. 「アクション」セクションの、同じダイアログにある「ルール条件」セクションの下で、次の設定を使用して、通知をトリガーするアクションにそのルールを関連付けます:

   • アクション・タイプ:: 通知。
   • 通知コンパートメント: ドロップダウン・リストにあるご使用のテナンシ名。
   • トピック: 前述のステップ2で作成したトピックを選択します。
9. 「ルールの作成」をクリックしてそのルールを保存します。

ルールと通知の作成が完了した後は、自動フェイルオーバー操作の開始と終了のたびに、設定したルールに基づいて通知が届きます。たとえば、電子メール・サブスクリプションを選択した場合は、次のような内容のメッセージを含む、"OCI Event Notification :com.oraclecloud.databaseservice.autonomous.database.critical"のような件名が付いた開始電子メール・メッセージが届きます:

{
  "eventType" : "com.oraclecloud.databaseservice.autonomous.database.critical",
  "cloudEventsVersion" : "0.1",
  "eventTypeVersion" : "2.0",
  "source" : "DatabaseService",
  "eventTime" : "2025-03-18T20:21:24Z",
  "contentType" : "application/json",
  "data" : {
    "compartmentId" : "<OCID of your Tenancy>",
    "compartmentName" : "<Tenancy Name>",
    "resourceName" : "<Autonomous Database name>",
    "resourceId" : "<OCID of the Autonomous Database involved",
    "additionalDetails" : {
      "dbName" : "<Autonomous Database name>",
      "eventName" : "AutomaticFailoverBegin",
      "description" : "Automatic failover for database <Autonomous Database name> has begun.",
      "autonomousDataType" : "Serverless",
      "workloadType" : "Data Warehouse"
    }
  },
  "eventID" : "<Event ID>",
  "extensions" : {
    "compartmentId" : "<OCID of your Tenancy>"
  }
}

その後、次のような内容を含む、同じ件名が付いた終了電子メール・メッセージが届きます。この終了電子メール・メッセージには、その操作からの算出されたデータ損失も含まれます。

{
  "eventType" : "com.oraclecloud.databaseservice.autonomous.database.critical",
  "cloudEventsVersion" : "0.1",
  "eventTypeVersion" : "2.0",
  "source" : "DatabaseService",
  "eventTime" : "2025-03-19T20:47:13Z",
  "contentType" : "application/json",
  "data" : {
    "compartmentId" : "<OCID of your Tenancy>",
    "compartmentName" : "<Tenancy Name>",
    "resourceName" : "<Autonomous Database name>",
    "resourceId" : "<OCID of the Autonomous Database>",
    "additionalDetails" : {
      "dbName" : "<Autonomous Database name>",
      "eventName" : "AutomaticFailoverEnd",
      "description" : "Automatic failover completed with 4 seconds data loss and <Autonomous Database name> is AVAILABLE and ready for user operations.",
      "autonomousDataType" : "Serverless",
      "workloadType" : "Data Warehouse"
    }
  },
  "eventID" : "<Event ID>",
  "extensions" : {
    "compartmentId" : "<OCID of your Tenancy>"
  }
}

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

次の表では、大量のワークロードを伴う数百回ものスイッチオーバー操作およびフェイルオーバー操作のMAA観測結果を示します。

なお、リストされているREDO率は、ロール・トランジションに関与するAutonomous Databasesのみではなく、POD全体に関するものです。Autonomous Database Serverlessでは、自分が所有していないAutonomous Databaseでのアクティビティを制御できません。手動フェイルオーバーでは、フェイルオーバー操作を発行する前に、人間による検出時間とスイッチオーバーの試行が必要です。リカバリ時間目標(RTO)の時間は、フェイルオーバーが発行された時点からの時間です。自動フェイルオーバーの場合、検出時間は通常は60秒から90秒です。

表33-4 Autonomous Data Guardのローカル・スタンバイの観測結果

ユースケース	操作タイプ	Autonomous Data Guardを使用したPDB	PODのREDO率	最大アプリケーションRTO	最大RPO
CDB障害	手動	6	250-270 MB/秒	検出時間+ 85秒	2秒
CDB障害	自動	6	250-265 MB/秒	検出時間+57秒	2秒
クラスタ障害	手動	6	250-280 MB/秒	検出時間+72秒	2秒
クラスタ障害	自動	6	250-280 MB/秒	検出時間+63秒	1秒
スイッチオーバー	手動	6	225-240 MB/秒	118秒	0

表33-5 Autonomous Data Guardのクロスリージョン・スタンバイの観測結果

ユースケース	操作タイプ	Autonomous Data Guardを使用したPDB	PODのREDO率	最大アプリケーションRTO	最大RPO
CDB障害	手動	5	175-200MB/秒	停止に対するユーザーの対応に基づきます。また、潜在的な、UIでのスイッチオーバー失敗の場合の5分間 106s	1秒-3秒
クラスタ障害	手動	5	175-200MB/秒	停止に対するユーザーの対応に基づきます。また、潜在的な、UIでのスイッチオーバー失敗の場合の5分間 126s	13s
スイッチオーバー	手動	5	175-200 MB/秒	407s	0
サイト障害	すべて	5	175-200 MB/秒	クラスタ障害と同じ	通常は、30-60秒 クロスリージョンのREDOプッシュは60秒ごと

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

データベースの接続文字列サンプルを取得するには、OCIコンソールで、Autonomous Databaseのホーム・リージョンの詳細ページにある「データベース接続」を選択します。

図adbs-database-connection.pngの説明

次の2つのオプションがあります。

• 「リージョナル・ウォレット」では、ご使用のテナンシのローカル・リージョン内のすべてのローカル・データベースについて接続文字列が提供されます。たとえば、アッシュバーン・リージョンに10個のデータベースがあり、そのうちの1つを表示している場合、OCIコンソールでは、10個すべてについてTNS別名が生成され、アッシュバーンのそれらのデータベースのコピーに接続するための必要なホスト名のみからなるアドレス・リストが示されます。

• リモート・リージョンで実行する場合、接続文字列については次の2つのオプションがあります:

  • OCIコンソールでリモート・リージョンに表示されているクロスリージョン・スタンバイに接続し、「データベース接続」セクションから「ウォレット・タイプ」の下の「リージョナル・ウォレット」を取得します。

    このダウンロードは、接続に必要な多数のファイルを含む1つのZIPファイルからなります。このZIPファイル内のtnsnames.oraには、そのリージョンのローカルにあるCMAN用のホストのみが含まれており、ご使用のテナンシのローカル・リージョンのすべてのローカル・データベースについて接続文字列が提供されています。

    たとえば、アッシュバーン・リージョンに10個のデータベースがあり、そのうちの1つを表示している場合、OCIコンソールでは、10個すべてについてTNS別名が生成され、アッシュバーンのそれらのデータベースのコピーに接続するための必要なホスト名のみからなるアドレス・リストが示されます。

  • ホーム・リージョンにあるプライマリ・データベースに接続し、「データベース接続」セクションから「ウォレット・タイプ」の下の「インスタンス・ウォレット」を取得します。

    このダウンロードは、接続に必要な多数のファイルを含む1つのZIPファイルからなります。このZIPファイル内のtnsnames.oraでは、アドレス・リストにホスト名が両方含まれており、最初にリモート・リージョンが示され、次にホーム・リージョンが示されています。

    インスタンス・ウォレットをそのまま使用すると、アドレス・リスト内の最初のホストへの接続は、リモート・リージョンへの接続を試みる前に失敗します。MAAの推奨事項に従うようにそれらの接続文字列を変更して、アドレス・リスト内の最初のホストへの接続がタイムアウトになるのまで待つことによって発生する遅延を回避できます。詳細は、「ステップ2: 高可用性のための接続文字列の構成」を参照してください。

ノート:

ローカル・スタンバイの場合は、そのリージョンの内部でそのデータベースがどこに存在していても、同じ接続文字列が機能します。ホスト・アドレスによってローカルの接続マネージャ(CMAN)に接続され、CMANによってその接続文字列の適切なプライマリ・データベースに接続されます。

MAAには、最大限の可用性とスムーズな移行を確保するための、接続文字列と方法に関する推奨事項があります。ここで示されている接続文字列を開始点として使用する必要があります。詳細は、「アプリケーションの継続的な可用性の構成」を参照してください。