Autonomous Data Guardを使用したクリティカルなデータベースの障害や災害からの保護

Autonomous Data Guardについて

Autonomous Data Guardは、完全に分離された2つのデータベース・コピー(アプリケーションが接続して使用するプライマリ・データベースと、プライマリ・データベースの同期コピーであるスタンバイ・データベース)を作成してメンテナンスします。その後、なんらかの理由でプライマリ・データベースが使用できなくなると、Autonomous Data Guardはスタンバイ・データベースをプライマリ・データベースに変換できるため、アプリケーションの処理を開始します。

通常、プライマリ・データベースとスタンバイ・データベースは、互いのピア・データベースと呼ばれます。Autonomous Container Databaseごとに最大2つのスタンバイ・データベースを設定できます。

ノート:

Autonomous Data Guardによって提供されるデータベース可用性機能を最大限に活用するには、透過的アプリケーション・コンティニュイティ(TAC)を使用するようにアプリケーションを構成する必要があります。

次の図は、各スタンバイ・データベースとプライマリ・データベースの同期を維持する方法を示しています。

図autonomous-data-guard.epsの説明

プライマリ・データベースに対して行われた変更は、プライマリ・データベースのREDOログに記録されます。Autonomous Data Guardは、これらのREDOレコードをストリームとしてネットワーク経由でスタンバイ・データベースのREDOログに送信します。次に、スタンバイ・データベースがこれらのレコードをスタンバイ・データベースに適用します。このようにして、スタンバイ・データベースはプライマリ・データベースと常に同期されます。

同期はほぼ瞬時に行われますが、前述のプロセスで示したように、2つの操作(REDOレコードをスタンバイ・データベースに転送する操作と、REDOレコードをスタンバイ・データベースに適用する操作)に時間がかかります。この1つ目はトランスポート・ラグと呼ばれ、もう1つは適用ラグと呼ばれます。Autonomous Databaseの現在のラグ値は、サイド・メニューの「リソース」の「Autonomous Data Guard」の「リソース」の下にあるデータベースの「詳細」ページから表示できます。コンテナ・データベース内のすべてのAutonomous Databaseにわたる現在のラグ値は、同様の方法でコンテナ・データベースの「詳細」ページから表示できます。

ノート:

複数のスタンバイ・データベースでは、カスケードREDO転送はサポートされていません。

Autonomous Data Guardの構成

Autonomous Database on Dedicated Exadata Infrastructureでは、Autonomous Data GuardをAutonomous Container Database (ACD)レベルで構成および管理します。すでにプロビジョニングされているACDに対してAutonomous Data Guardを有効にし、Oracle Cloud Infrastructureコンソールを使用して「詳細」ページから最大2つのスタンバイACDを追加できます。手順については、Autonomous Container DatabaseでのAutonomous Data Guardの有効化および2番目のスタンバイAutonomous Container Databaseの追加を参照してください。

Autonomous Data Guardを構成する前に、次の点に注意してください:

Autonomous Data Guard設定でプライマリ・データベースとスタンバイ・データベース間のTCPトラフィックを許可するには、Exadata Cloud@CustomerにデプロイされたAutonomous Databaseでポート1522が開いている必要があります。
Autonomous Data Guardは、次の3日以内にスケジュールされたアクティブなメンテナンス実行があるACDでは有効にできません。最初にアクティブ・メンテナンスを実行してからAutonomous Data Guardを有効にするか、2番目のスタンバイ・データベースが追加されるまで開始されないようにメンテナンス実行スケジュールを変更できます。
2番目のスタンバイ・データベースを追加するには、最初のスタンバイ・データベースの自動非ローリング再起動が必要です。プライマリ・データベースは、この非ローリング再起動の影響を受けません。

顧客管理キーを使用したAutonomous Data Guardの構成

専用Exadataインフラストラクチャ上のAutonomous Databaseでは、Autonomous Container Database (ACD)レベルで顧客管理キーを使用してAutonomous Data Guardを構成および管理できます。Oracle Cloud Infrastructureコンソールを使用して、すでにプロビジョニングされているACDに対してAutonomous Data Guardを有効にし、その「詳細」ページから最大2つのスタンバイACDを追加できます。手順は、Autonomous Container DatabaseでのAutonomous Data Guardの有効化および2番目のスタンバイAutonomous Container Databaseの追加を参照してください。

顧客管理キーを使用してAutonomous Data Guardを構成する前に、次の点に注意してください:

Oracle Cloud Infrastructure Key Management System (OCI KMS)を使用しており、リージョン間Autonomous Data Guardを有効にする場合は、まず、スタンバイ・データベースを追加するリージョンにOCIボールトをレプリケートする必要があります。詳細は、ボールトおよびキーのレプリケートを参照してください。

ノート:
リージョン間ボールト・レプリケーション機能が導入される前に作成された仮想ボールトは、リージョン間でレプリケートできません。別のリージョンでレプリケートする必要があるボールトがあり、そのボールトでレプリケーションがサポートされていない場合は、新しいボールトおよび新しいキーを作成します。ただし、すべてのプライベート・ボールトはリージョン間レプリケーションをサポートしています。詳細は、仮想ボールトのクロス・リージョン・レプリケーションを参照してください。
Oracle Key Vault (OKV)を使用しており、リージョン間Autonomous Data Guardを有効にする場合は、OKVクラスタの接続IPアドレスをキー・ストアに追加していることを確認してください。

Autonomous Data Guardモデル

2025年3月以降、Autonomous Container Database (ACD)は、「詳細」ページからAutonomous Data Guardを有効にし、最大2つのスタンバイACDを作成できます。このリリースでは、以前のAutonomous Data Guardアソシエーション・モデルおよび関連付けられたAPIは非推奨になり、新しいAutonomous Data Guardグループ・モデルおよびAPIに置き換えられます。2025年3月より後にOracle Cloud Infrastructure (OCI)コンソールからプロビジョニングされたすべての新しいACDは、新しいAutonomous Data Guardグループ・モデルを自動的に使用します。

既存のACDを移行するには、OCIコンソールのACD「詳細」ページから「Autonomous Data Guardグループへのアップグレード」をクリックするか、MigrateAutonomousContainerDatabaseDataguardAssociation APIを使用して、新しいモデルに移行できます。

アップグレード時:

Autonomous Data Guard操作がAutonomous Container Database Data Guardアソシエーション・リソースではなくAutonomous Container Databaseリソースで実行される新しいユーザー・エクスペリエンスに切り替えます。
Autonomous Data Guardアソシエーション・リソースは、複数のスタンバイ・サポートがあるAutonomous Data Guardグループ・リソースに変換されます。既存のAutonomous DatabasesまたはData Guardの設定には影響しません。
Autonomous Data Guardは、Autonomous Data Guard機能を使用するようにプロビジョニングした後、ACDの「詳細」ページから有効にする必要があります。
プライマリACDまたはフェイルオーバーでロールをそれぞれ切り替えるスタンバイACDから、スイッチオーバーおよびフェイルオーバー操作を開始する必要があります。
Autonomous Data Guard構成を管理するためのAPIで置換APIとしてリストされた新しいAutonomous Data GuardグループAPIに切り替えます。既存のAutonomous Data Guardアソシエーション APIは非推奨であり、2026年3月からは使用できません。
Autonomous Data Guardイベント・タイプにリストされている新しいAutonomous Data Guardグループ・イベントをサブスクライブする必要があります。既存のAutonomous Data Guardアソシエーション・イベントは、古いAutonomous Data Guardアソシエーション APIでのみ機能し、これらのAPIとともに非推奨になります。

ロールの遷移および操作

Autonomous Container Database (ACD)の作成後、スイッチオーバー操作かフェイルオーバー操作のいずれかを使用して、ピア・データベースのロールを変更できます。自動フェイルオーバーが有効な場合、Autonomous Data Guardは、なんらかの理由でプライマリ・データベースが使用不可になるたびに、自動的にフェイルオーバー操作を実行します。

スイッチオーバーは、プライマリ・データベースとそのスタンバイ・データベースのロールを交替させることです。スイッチオーバーでは、データ損失がないことが保証されます。スイッチオーバー中、プライマリ・データベースはスタンバイ・ロールに遷移し、スタンバイ・データベースはプライマリ・ロールに遷移します。スイッチオーバー操作を実行するには、Autonomous Data Guard構成のロールの切替えを参照してください。

フェイルオーバーは、プライマリ・データベースが使用できない場合です。フェイルオーバーが行われると、スタンバイ・データベースがプライマリ・ロールに遷移します。自動フェイルオーバーが有効になっていない場合は、Autonomous Data Guard構成でのスタンバイへのフェイルオーバーの説明に従って、手動フェイルオーバーを実行できます。

フェイルオーバー操作後のデータベースの可用性およびステータスは、2つのリカバリ目標によって特徴付けられます:

リカバリ時間目標(RTO)。RTOは、フェイルオーバー後にアプリケーションでデータベースが使用可能になるまでに必要な最大時間であり、ある程度は障害発生時の適用ラグに関連しています。Autonomous Data Guardの場合、RTOは数秒から2分までです。
リカバリ・ポイント目標(RPO)。RPOは、障害が発生したプライマリ・データベースで起こる可能性のあるデータ損失の最大期間であり、ある程度は障害発生時のトランスポート・ラグに関連しています。Autonomous Data Guardの場合、RPOはほぼゼロです。

フェイルオーバー後、障害が発生したプライマリは無効なスタンバイになり、データベース接続では使用できなくなります。回復操作を実行することで、再度有効にし、正常なスタンバイに変えることができます。障害が発生したプライマリがスタンバイとして回復されたら、スイッチオーバーを実行して元のプライマリ・ロールに戻すことができます。回復操作を実行するには、Autonomous Data Guard構成の無効なスタンバイの回復を参照してください。

自動フェイルオーバーまたはファストスタート・フェイルオーバー

自動フェイルオーバーでは、リージョン障害、可用性ドメインの障害、ExadataインフラストラクチャまたはAutonomousのExadata VMクラスタ(AVMC)の障害、またはACD自体の障害によってプライマリACDが使用できなくなると、自動的にスタンバイACDにフェイルオーバーします。これは、ファストスタート・フェイルオーバーとも呼ばれます。

ACDでAutonomous Data Guardを構成している間は、自動フェイルオーバーを有効にできません。自動フェイルオーバーは、ACDの「詳細」ページからAutonomous Data Guard設定を更新している間のみ有効または無効にできます。

ノート:

自動フェイルオーバーは、クロスリージョンAutonomous Data Guardが設定されたExadata Cloud@CustomerにデプロイされたAutonomous Databaseに対して有効にできません。

最初のスタンバイACDに対して自動フェイルオーバーが有効になっている2番目のスタンバイACDは追加できません。そのため、2番目のスタンバイACDを作成する前にAutonomous Data Guard設定の更新を使用して自動フェイルオーバーを無効にし、必要に応じて後で再度有効にします。

最大パフォーマンス・モードと最大可用性保護モードの両方で、自動フェイルオーバーがサポートされています:

最大可用性モードでは、自動フェイルオーバーによってデータ損失ゼロが保証されます。
最大パフォーマンス・モードでは、自動フェイルオーバーにより、スタンバイ・データベースが「ファスト・スタート・フェイルオーバー・ラグ制限」に指定された値を超えてプライマリ・データベース遅れないことが保証されます。デフォルトでは、「ファスト・スタート・フェイルオーバー・ラグ制限」は30秒に設定され、最大パフォーマンス・モードにのみ適用されます。この場合、自動フェイルオーバーは、スタンバイの適用ラグ(潜在的なデータ損失)が構成済のラグ制限を超えない場合にのみ可能です。ファスト・スタート・フェイルオーバーのラグ制限は、5から3600までの任意の値に変更できます。

詳細は、Autonomous Data Guard設定の更新を参照してください。

ハードウェア障害、可用性ドメインの停止およびリージョンの停止の他に、次に示すように、ファストスタート・フェイルオーバーをトリガーする可能性のあるデータベースの状態がさらにいくつかあります:

データベース・ヘルス条件	説明
破損した制御ファイル	ディスク障害により、制御ファイルが完全に破損しました。
破損したディクショナリ	クリティカルなデータベースのディクショナリの破損。現時点では、この状態は、データベースが開いている場合にのみ検出されます。
データファイル書込みエラー	書き込みエラーは、一時ファイル、システム・データ・ファイル、UNDOファイルなど、あらゆるデータ・ファイルで発生します。

自動フェイルオーバーの結果、障害が発生したプライマリ・データベースのロールは無効スタンバイになり、しばらくすると、スタンバイ・データベースがプライマリ・データベースのロールを引き継ぎます。自動フェイルオーバーが終了すると、フェイルオーバーが発生したことを通知するメッセージが無効になっているスタンバイ・データベースの詳細ページに表示されます。

サービスが以前のプライマリAutonomous Container Databaseの問題を解決した後、手動スイッチオーバーを実行して、両方のデータベースを初期ロールに戻すことができます。スタンバイ・データベースをプロビジョニングしたら、次のようなスタンバイ・データベースに関連する様々な管理タスクを実行できます:

プライマリ・データベースをスタンバイ・データベースに手動でスイッチオーバーします。
プライマリ・データベースをスタンバイ・データベースに手動でフェイルオーバーします。
フェイルオーバー後にプライマリ・データベースをスタンバイ・ロールに戻します。
スタンバイ・データベースを終了します。

複数のスタンバイ・データベースおよび自動フェイルオーバーを使用したAutonomous Data Guard設定では、次のようになります:

手動フェイルオーバーでは、元のプライマリ・データベース(新しいスタンバイ・データベース)を手動で回復する必要があります。
自動フェイルオーバーが発生するたびに、専用Exadataインフラストラクチャ上のAutonomous Databaseは、古いプライマリをスタンバイとして回復しようとします。ただし、その試行が失敗した場合は、手動で修復する必要があります。

スナップショット・スタンバイ・データベース

スナップショット・スタンバイ・データベースは、スタンバイAutonomous Container Database (ACD)をスナップショット・スタンバイACDに変換することによって作成される、完全に更新可能なスタンバイ・データベースです。手順については、フィジカル・スタンバイからスナップショット・スタンバイへの変換を参照してください。

スナップショット・スタンバイ・データベースは、プライマリ・データベースからREDOデータを受信してアーカイブしますが、適用はしません。ただし、プライマリ・データベースからのリアルタイムの変更は適用されないため、リカバリ時間目標(RTO)は増加します。

スナップショット・スタンバイ機能は様々なユースケースをサポートしていますが、主なユースケースを次に示します。

プライマリおよびスタンバイ・アプリケーション・インスタンスを読取り/書込みモードでプライマリおよびスタンバイ・データベースに接続して、初期構成を実行します。
最初にスナップショット・スタンバイ・データベースにパッチを適用し、スタンバイ・アプリケーション・インスタンスでテストしてパッチの安定性を確認します。そのためには、まずフィジカル・スタンバイをスナップショット・スタンバイに変換する必要があります。そのため、パッチをスナップショット・スタンバイに適用できます。

ノート:

フィジカル・スタンバイAutonomous Container Databaseは、自動フェイルオーバーが有効になっているスナップショット・スタンバイには変換できません。

スナップショット・スタンバイへの変換中に、スナップショット・モードでのみアクティブな新しいデータベース・サービスをアクティブ化するか、プライマリ・データベースで使用される同じサービス・セットを使用できます。ただし、スナップショット・スタンバイ・データベースでプライマリ・データベース・サービスをアクティブ化すると、スナップショット・スタンバイ接続リクエストがプライマリ・データベースに転送されたり、不適切なデータベース接続文字列を使用した場合はその逆が起こります。したがって、プライマリおよびスナップショット・スタンバイ・データベースへの接続時には、適切な接続文字列を使用するように注意する必要があります。

ノート:

スナップショット・スタンバイを使用して新しいサービスを作成すると、スナップショット・スタンバイACD内のすべてのAutonomous Databaseのウォレットが更新されます。データベースにアクセスするには、スタンバイAutonomous Databaseからウォレットをリロードし、スナップショット・スタンバイ接続文字列を使用します。

Oracle Cloud Infrastructure (OCI)からスナップショット・スタンバイACDを手動でフィジカル・スタンバイACDに変換して戻すことができます。詳細な手順は、「スナップショット・スタンバイをフィジカル・スタンバイに変換」を参照してください。スナップショット・スタンバイは、手動でフィジカル・スタンバイに変換されない場合、作成から7日後にフィジカル・スタンバイに自動的に変換されます。いずれの場合も、スナップショット・スタンバイをフィジカル・スタンバイに戻すと、スナップショット・スタンバイ・データベースに対するすべてのローカル更新が破棄され、プライマリ・データベースから受信したREDOデータが適用されます。

スタンバイACDがスナップショット・スタンバイ・モードの場合、プライマリACDに対して次の操作は実行できません。

Autonomous Databasesの作成または終了
Autonomous Databasesのスケール・アップまたはスケール・ダウン
Autonomous Databasesのリストア

状況に応じて、プライマリ・データベースからスナップショット・スタンバイに手動でフェイルオーバーできます。その場合、フェイルオーバーは、スナップショット・スタンバイに対して行われたすべてのローカル更新を破棄し、プライマリ・データベースからデータを適用することで、スナップショット・スタンバイ・データベースをフィジカル・スタンバイ・データベースに変換します。ステップバイステップの手順については、Autonomous Data Guard構成でのスタンバイへのフェイルオーバーを参照してください。

プライマリ・データベースとそのスナップショット・スタンバイ・データベースのスイッチオーバーは許可されません。スイッチオーバーを試行する前に、スナップショット・スタンバイを手動でフィジカル・スタンバイに変換する必要があります。

クライアント・アプリケーションからのスタンバイ・データベースへのアクセス

Autonomous Data Guard構成では、クライアント・アプリケーションは通常、プライマリ・データベースに接続して操作を実行します。

フィジカル・スタンバイ・データベースへの接続

Autonomous Data Guardには、この通常の接続に加えて、スタンバイ・データベースで読取り専用操作を実行するクライアント・アプリケーションを接続するオプションもあります。このオプションを利用するために、クライアント・アプリケーションは、("読取り専用"を表す) "_RO"を含むデータベース・サービス名を使用してデータベースに接続します(Autonomous Databaseの事前定義済データベース・サービス名を参照)。

スナップショット・スタンバイ・データベースへの接続

Autonomous Data Guardでは、読取り/書込み操作を実行するクライアント・アプリケーションをスナップショット・スタンバイ・データベースに接続することもできます。これらの操作は、スナップショット・スタンバイ・データベースに対してローカルであり、プライマリ・データベースは変更されません。スナップショット・スタンバイ・データベースに接続するために、クライアント・アプリケーションは、Autonomous Databasesの事前定義済データベース・サービス名の説明に従って、_SSを含むデータベース・サービス名(スナップショット・スタンバイ用)を使用できます。

ノート:

スタンバイ・データベースがスナップショット・スタンバイ・モードの場合、名前に「_RO」サービスを含むすべてのデータベース・サービスは非アクティブであり、接続に使用できません。

タイム・ラグのモニタリング

Autonomous Data Guardを使用するデータベースの実行中は、サイド・メニューの「リソース」で「Autonomous Data Guardアソシエーション」を選択して、データベース(またはコンテナ・データベース)の「詳細」ページからトランスポート・ラグおよび適用ラグの時間をモニターできます。OCIコンソールまたは可観測性APIを使用して、トランスポート・ラグを監視し、アラームおよび通知を構成することもできます。詳細は、Autonomous Databaseメトリックを使用したデータベース可観測性を参照してください。

時間の経過とともに、データベースのワークロードの増減に伴って小さな変動はあるはずです。ただし、ラグの時間の継続的な上昇傾向に気付いた場合は、次のアクションを実行して状況を解決できます:

適用ラグの上昇傾向。適用ラグの継続的な上昇傾向は、スタンバイ・データベースにプライマリ・データベースからのREDOレコードに対応するための十分な容量がないことを示します。この状況を解決するには、専用Autonomous DatabaseへのCPUまたはストレージ・リソースの追加の説明に従って、データベースのOCPUをスケール・アップします。
トランスポート・ラグの上昇傾向。トランスポート・ラグの継続的な上昇傾向は、ネットワーク・パフォーマンスの問題を示します。Oracle Cloudの運用スタッフがネットワーク・パフォーマンスを常にモニターしているため、ユーザーは何もアクションを実行しなくても状況は解決します。ただし、必要な場合は、My Oracle Supportでのサービス・リクエストの作成の説明に従って、サービス・リクエストを発行し、運用スタッフに状況の対処を依頼することができます。

Autonomous Data Guard構成オプション

Autonomous Data Guardを有効にしてAutonomous Container Databaseを作成する場合、スタンバイ・データベースを作成するExadataインフラストラクチャおよびAutonomous Exadata VMクラスタ・リソースを指定し、使用するデータ保護モードを指定します。

スタンバイに使用するExadataインフラストラクチャおよびAutonomous Exadata VMクラスタ・リソースを指定する場合、次の選択肢があります:

プライマリ・データベースのExadataインフラストラクチャおよびAutonomous Exadata VMクラスタとは異なるリージョン:
これを選択すると、リージョン全体への外部ネットワーク接続や電力の大幅な損失などの障害に対して最高レベルの保護が提供されます。

このクロスリージョン保護を最大限に利用するには、クロスリージョン保護をサポートするようにアプリケーション層を構成する必要もあります。そのため、アプリケーション層がすでにこのように構成されている場合、またはクロスリージョン保護をサポートするようにアプリケーション層を再構成する場合は、このオプションを選択することをお薦めします。

別のリージョンでスタンバイ・データベースを検索する場合は、Oracleでは「最大パフォーマンス」保護モードを使用することをお薦めします。
プライマリ・データベースのExadataインフラストラクチャおよびAutonomous Exadata VMクラスタとは異なる可用性ドメイン(AD):
これを選択すると、リージョン内のアベイラビリティ・ドメインへの外部ネットワーク接続や電力の大幅な損失などの障害に対して高レベルの保護が提供されます。

これを選択すると、データ保護とアプリケーション層の構成のシンプルさとのバランスをうまく取ることができます。

別の可用性ドメインでスタンバイ・データベースを検索する場合、Oracleでは「最大可用性」保護モードを使用することをお薦めします。
プライマリ・データベースのExadataインフラストラクチャおよびAutonomous Exadata VMクラスタと同じ可用性ドメイン(AD):
これを選択すると、障害に対する保護は最小レベルになります。これを選択することはお薦めしません。

プライマリ・データベースのExadataインフラストラクチャおよびAutonomous Exadata VMクラスタ・リソースが、可用性ドメインが1つのみのリージョンにある場合、「異なるリージョン」オプションを使用することをお薦めします。

同じ可用性ドメインでスタンバイ・データベースを検索するように選択した場合、Oracleでは最大可用性保護モードを使用することをお薦めします。
プライマリ・データベースのExadataインフラストラクチャおよびAutonomous Exadata VMクラスタとは異なるテナンシ:
適用対象: Oracle Public Cloudのみ

この選択により、別のテナンシからスタンバイ・データベースを追加でき、データベースのフェイルオーバーまたはクロステナンシ・スタンバイ・データベースへのスイッチオーバーが可能になります。リモート・テナンシにスナップショット・スタンバイを作成することもできます。クロステナンシ・スタンバイ・データベースを持つことは、テナンシ間でのデータベースの移行に役立ちます。

クロステナンシ・スタンバイ・データベース:
- ECPUまたはOCPUコンピュート・モデルのいずれかで有効化できます。スタンバイ・データベースは、プライマリ・データベースと同じコンピュート・モデルを使用する必要があります。
- 自動フェイルオーバーをサポートしません。かわりに手動フェイルオーバーのみを使用できます。
- Oracle Cloud Infrastructureコンソールを使用して追加することはできません。クロス・テナンシ・スタンバイ・データベースは、CLIまたはREST APIを使用してのみ追加できます。

保護モードについて

Autonomous Data Guardには、次のデータ保護モードがあります:

最大可用性この保護モードは、プライマリ・データベースの可用性に影響を与えない範囲の最上位レベルのデータ保護を提供します。

プライマリ・データベースは、データが(ディスクに書き込まれたことではなく)スタンバイで受信されたことを確認するまで、トランザクションをコミットします。プライマリ・データベースが30秒以内にこの確認を受信しない場合、最大パフォーマンス・モードであるかのように動作して、確認を再受信するまでプライマリ・データベースの可用性を保持します。

この保護モードでは、特定の二重障害の場合(スタンバイ・データベースの障害発生後のプライマリ・データベースの障害など)を除いて、ゼロ・データ損失が保証されます。
最大パフォーマンスこれはデフォルトの保護モードです。これは、プライマリ・データベースのパフォーマンスに影響を与えない範囲で可能な最高レベルのデータ保護を提供します。

プライマリ・データベースは、トランザクションによって生成されたすべてのREDOデータがそのオンラインREDOログに書き込まれるとすぐに、そのトランザクションをコミットします。また、REDOデータをスタンバイ・データベースに送信しますが、これはトランザクション・コミットとは非同期に実行されるため、プライマリ・データベースのパフォーマンスはスタンバイ・データベースへのREDOデータの書込みの遅延の影響を受けません。

この保護モードを使用すると、最大可用性モードよりもデータ保護が若干弱くなり、プライマリ・データベースのパフォーマンスへの影響は最小限になります。

Oracle Cloud Infrastructure (OCI)コンソールからAutonomous Data Guard設定で保護モードを変更できます。ステップバイステップの手順については、Autonomous Data Guard設定の更新を参照してください。

(Autonomous Data Guard機能の基礎となる) Oracle Data Guardの保護モードの詳細は、『Oracle Data Guard概要および管理』のOracle Data Guardの保護モードに関する項を参照してください。

Autonomous Data Guardの構成時のベスト・プラクティス

Autonomous Databaseでは、Autonomous Data Guardを使用して最大2つのスタンバイACDを作成できますが、要件に応じて、単一または複数のスタンバイACDを使用できます。ただし、Autonomous Databaseが提供する最も回復性の高いディザスタ・リカバリ・オプションを使用するには、1つのローカル・スタンバイACDおよび1つのリモートまたはクロスリージョン・スタンバイACDをデータ保護モードとして最大可用性で追加できます。

この設計の利点について説明します。

ローカル・スタンバイ:
- 同じリージョン内のローカル・スタンバイへの自動フェイルオーバーにより、ローカル・ディザスタの大幅な分離およびアプリケーション・フェイルオーバーの簡略化が行われます。
- ローカル・スタンバイ・データベースのビジネス価値は、データ損失ゼロのフェイルオーバーおよびアプリケーションの停止時間が数秒に短縮された状態で確認されます。
- アプリケーションは自動的に透過的にローカル・スタンバイにフェイルオーバーし、アプリケーション・サーバーとデータベース間で同じレイテンシを維持します。これは、OLTPおよびパッケージ・アプリケーションにとって特に重要です。レイテンシが大きいと、スループットおよびアプリケーション全体のレスポンス時間に大きく影響する可能性があるためです。
リモート・スタンバイ:
- リージョン障害が発生すると、プライマリ・スタンバイ・システムとローカル・スタンバイ・システムにアクセスできなくなり、アプリケーションとデータベースはリモート・スタンバイにフェイルオーバーできます。
- リージョン障害が発生したときにデータベースの停止時間がまだ非常に短い場合でも、DNS、アプリケーション、およびセカンダリ・リージョンへのデータベースのフェイルオーバー操作に必要な追加のオーケストレーションにより、アプリケーションの停止時間が長くなる可能性があります。
最大可用性:
- 自動フェイルオーバーまたはファスト・スタート・フェイルオーバー(FSFO)が有効になっている場合、プライマリACDが使用できなくなると、Autonomous Data Guardはローカル・スタンバイにフェイルオーバーし、データ損失はゼロになり、アプリケーションのデータベース・レイテンシは変更されません。
- 自動フェイルオーバーまたはファスト・スタート・フェイルオーバー(FSFO)が有効な場合、プライマリ・リージョン全体にアクセスできなくなると、システムはリモート・スタンバイにフェイルオーバーし、データ損失が発生する可能性があります。

Autonomous Data Guardが標準管理操作に与える影響

Autonomous Container DatabaseでAutonomous Data Guard構成のプライマリ・コンテナ・データベースおよびスタンバイ・コンテナ・データベースに実行する標準管理操作は、標準のコンテナ・データベースと比較して、その仕組みが異なる場合があります。次のリストでは、これらの違いについて説明します。

メンテナンス・スケジュールの変更
プライマリ・コンテナ・データベースとそのスタンバイのメンテナンス・スケジュールはリンクされています: スタンバイのメンテナンスは、プライマリ・コンテナ・データベースのメンテナンスの何日か前に実行されます。デフォルトは7日です。プライマリ・コンテナ・データベースを作成するとき、または後でメンテナンス詳細を編集するときに、1日から7日までの値を選択できます。
メンテナンス・タイプの変更
プライマリ・コンテナ・データベースとそのスタンバイのメンテナンス・タイプは同じである必要があります。プライマリ・コンテナ・データベースを作成するとき、または後でメンテナンス詳細を編集するときに、プライマリとスタンバイの両方のメンテナンス・タイプを選択します。
自動バックアップの無効化
Autonomous Data Guardを使用したAutonomous Container Database (ACD)のプロビジョニング中は、自動バックアップを無効にできません。
スケジュール済メンテナンスの管理
プライマリ・コンテナ・データベースとそのスタンバイのスケジュール済メンテナンスは、個別に管理できます。ただし、2つのメンテナンスはリンクされているため、スケジュール済メンテナンス時間を上書きするように選択した場合は、プライマリの前にスタンバイでスケジュール済メンテナンスを実行する必要があります。
別のコンパートメントへの移動
プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースは、標準のコンテナ・データベースと同じように、個別に移動できます。ただし、標準のコンテナ・データベースの場合と同様に、適切なクラウド・ユーザー・グループからのみコンテナ・データベースをアクセス可能な状態に保つために、コンテナ・データベースを移動する際には細心の注意を払う必要があります。
再起動
プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースは、標準のコンテナ・データベースと同じように、個別に再起動できます。
暗号化キーのローテーション
暗号化キーは、プライマリACDまたはプライマリ・データベースからローテーションできます。
終了
プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースは個別に終了できます。ただし、プライマリ・コンテナ・データベースの終了とスタンバイ・コンテナ・データベースの終了の結果は異なります:
- プライマリ・コンテナ・データベースを終了すると、プライマリ・コンテナ・データベースとスタンバイ・コンテナ・データベースの両方が終了します。Autonomous Databaseを含むプライマリ・コンテナ・データベースは終了できません。
- スタンバイ・コンテナ・データベースを終了すると、スタンバイ・コンテナ・データベースが終了し、Autonomous Data Guard構成から削除されます。プライマリが残っている場合、Autonomous Data Guard構成は削除され、プライマリがスタンドアロン・コンテナ・データベースになります。

ステップバイステップ・ガイド

Autonomous Container DatabaseでのAutonomous Data Guard構成の管理に関するステップバイステップのガイダンスは、次を参照してください:

APIを使用して、Autonomous Data Guard構成を表示および管理することもできます。詳細は、Autonomous Data Guard構成を管理するためのAPIを参照してください。