この記事はSinan Petrus TomaとSebastian SolbachによるImplement Disaster Recovery with Data Guard across Oracle Database@Azure and Oracle Cloudの日本語翻訳版記事です。

2026年1月21日

ディザスタ・リカバリを実現するために、特にOracle Database@Azureが1つのAvailability Zone（AZ）でしか利用できず、かつデータを同一リージョン内に保持する規制要件がある場合は、同じリージョン内で物理的に隔離されたOCI のAvailability Domain（AD）にスタンバイ・データベースを作成できます。複数のADが存在するリージョンでは、可用性をさらに高めるために、Azureゾーンにリンクしていない別のADを選択することを推奨します。

本記事では、同一リージョン内にある Oracle Database@Azure と Oracle Cloud Infrastructure（OCI）の間で、Oracle Exadata Database Service on Exascale Infrastructure 上での Oracle Active Data Guard 構成を解説します。同じ手法は Oracle Exadata Database Service on Dedicated Infrastructure に対しても適用可能です。

Oracle Database@Azure は、Oracle Real Application Clusters（Oracle RAC）による高可用性とスケーラビリティを標準で備え、Azure アプリケーションに低レイテンシを実現します。さらに、このソリューションを拡張し、同一リージョン内のOCI Availability Domainにある別の Oracle Exadata Database Service on Exascale Infrastructure にActive Data Guard スタンバイデータベースを配置することで、Azure 側の全体障害発生時にも可用性とデータ保護を強化できます。OCIとAzureデータセンターの物理的な近接性により同期レプリケーションが可能となり、ゼロデータロス構成も実現できます。

アーキテクチャ

このアーキテクチャは、Oracle Exadata Database Service on Exascale Infrastructure 上にActive Data Guardを構成し、プライマリ・データベースをOracle Database@Azureに、スタンバイ・データベースをOracle Cloud Infrastructureに配置した構成例を示しています。

Oracle Databaseは、Availability Zone内のExascale VMクラスタ上で稼働します。データ保護のため、Oracle Active Data Guardが同じ地理的リージョン内のOCIAvailability Domainにデータをレプリケーションします。

Active Data Guardのネットワーク・トラフィックは、専用のバックボーン経由でOCIネットワークを通じて送信されます。Oracle Database@AzureでExascale VMクラスタを作成すると、OCI側にも対応するVCN（Virtual Cloud Network）が自動的に作成されます。Oracle Cloud上のExascale VMクラスタは、それぞれ独自のVCNを利用し、AzureのVNETと同じIP CIDRレンジをマッピングしています。

このアーキテクチャでは、次の構成となります：

  • プライマリのExascale VMクラスタは、Azureアベイラビリティゾーン内のVCN1（CIDR：10.10.0.0/16、クライアントサブネットCIDR：10.10.1.0/24）に配置されています。VCN1はローカルピアリングゲートウェイ（LPG1）を持ちます。
  • スタンバイのExascale VMクラスタは、OCIアベイラビリティドメイン内のVCN2（CIDR：10.20.0.0/16、クライアントサブネットCIDR：10.20.1.0/24）に配置されています。
  • VCN2にはローカルピアリングゲートウェイ（LPG2）が設定されています。
  • VCN1とVCN2は、LPG1とLPG2を使ったローカルピアリング接続により相互接続されています。

推奨事項

Oracle Database@Azure上でOracle Exascale Database Service向けにディザスタ・リカバリを実装する際は、以下の推奨事項を出発点としてご活用ください。要件によっては、ここで説明するアーキテクチャと異なる場合があります。

  • データの総合的な損失防止や自動ブロック修復、オンライン・アップグレード・マイグレーション、スタンバイへのワークロードのオフロードによるリードスケールアウトを実現するために、Active Data Guardを活用しましょう。
  • 計画・非計画問わず障害時のデータベース停止をエンドユーザーから隠ぺいし、アプリケーションの継続的利用を担保するため、Application Continuityを有効にしましょう。
  • Oracle Data Guardによる保護がある場合も、バックアップ負荷を軽減するため、Oracle Database Autonomous Recovery Service（AzureおよびOCI両方）への自動バックアップを設定しましょう。これにより、週次フルバックアップが不要な“incremental forever”バックアップ戦略が利用できます。
  • スタンバイ環境からのバックアップを有効にして、Azure-OCI間でのバックアップ・レプリケーションを実現しましょう。
  • データベースのスイッチオーバーやフェイルオーバーの運用を自動化するために、OCI Full Stack Disaster Recoveryを活用しましょう。

検討事項

Oracle Database@Azure上のOracle Exascale Database Serviceで、Data Guardスタンバイ・データベースをOracle Cloud Infrastructureに配置して事業継続性を確保する場合、以下の点にご注意ください：

  • Oracle Database@Azureの子サイトでExascale VMクラスタを作成すると、それぞれのExascale VMクラスタは独自のOCI VCN（Virtual Cloud Network）内に作成されます。Data Guardでは、データベース間でリドゥデータを転送できるように通信が必要です。そのため、VCN同士をピアリングして通信を有効にする必要があり、Exascale VMクラスタ間のVCNではIP CIDRレンジが重複しないように構成する必要があります。
  • Data Guardの保護モードは、Azure Availability ZoneとOCI Availability Domain間のネットワークレイテンシや、パフォーマンス・ゼロデータロスに対するアプリケーション要件に応じて選択してください。
  • 1つのプライマリ・データベースに対して、クラウドツール経由で最大6つまでのスタンバイ・データベースを作成できます。

ネットワーク構成

プライマリおよびスタンバイのExadata VMクラスタのVCN間でローカルピアリングを確立し、ルートテーブルやネットワークセキュリティグループを設定して、Availability Zone間のActive Data Guard用ネットワーク通信を有効にします。具体的な手順については、OCIのローカルVCNピアリングに関するドキュメントをご参照ください。

DNS解決

Azure VNetとOCI VCNネットワーク間でホスト名を解決するためには、Oracle Private DNS機能の利用を推奨します。このソリューションにより、アプリケーションはAzureからOCIへのSCAN名、OCIからAzureへのSCAN名の両方を利用できます。

さらに、Private DNSを利用すると、VCN間やVCNとオンプレミス・ネットワーク間のDNS解決も実現できます。詳細は「VCN間のDNS解決」に関するドキュメントをご参照ください。

Data Guardの導入

Data GuardまたはActive Data Guardスタンバイデータベースは、OCIのクラウドツールを使って作成できます。

新しいData Guard GroupリソースとAPIを利用すると、複数のスタンバイデータベースの追加や、さらなる機能強化が可能になります。既存のData Guard Association APIを使ってData Guardの自動化運用を行っている場合は、新しいAPIへ移行し、これらの新しい機能をご活用ください。詳細については、「Oracle Exadata Database Service on Exascale InfrastructureでData Guardを有効化する方法」のドキュメントをご覧ください。

アプリケーションのレプリケーションと接続性

プライマリおよびスタンバイ・データベースへのアプリケーションのレプリケーションや接続については、以下のシナリオをもとに説明します。

データベース障害への対応

データベース障害が発生した場合でも、Azureアプリケーションは引き続き稼働し、VPN経由またはOracle Interconnect for Azure経由でOCI上のデータベースに接続できます。Oracle Interconnect for Azureは、低レイテンシー、高スループット、専用のプライベート接続を実現できるため、特に推奨されるソリューションです。OCIデータベースへのレイテンシは、Azure内のローカルデータベースに比べて若干高くなる場合がありますが、それでもOracle Interconnect for Azureでは、1桁台のミリ秒という低レイテンシが実現されます。

高可用性と、プライマリ・スタンバイ両方のデータベースへの接続性を確保するため、アプリケーションでは次の接続文字列を使用してください。

Alias = (DESCRIPTION =
(CONNECT_TIMEOUT= 90)(RETRY_COUNT=100)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=1000ms)(LOAD_BALANCE=off)
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=azure-scan)(PORT=1521)))
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=oci-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = my_service)))

アプリケーションの観点でOCI上のデータベースへのレイテンシが許容できない場合は、アプリケーションもOCI側にレプリケーションし、データベースとともにアプリケーションもフェイルオーバーさせる必要があります。これについては「サイト障害保護」のユースケースで説明します。

ステートフルアプリケーション向けのサイト障害保護

データセンター障害からシステム全体を保護するには、アプリケーションやその他のコンポーネントも両クラウド環境にまたがってレプリケーションしましょう。こうすることで、AzureアプリケーションはAzureのローカル・データベース、OCIアプリケーションはOCIのローカルデータベースにアクセスするため、アプリケーションからデータベースへのレイテンシが最小になります。

ステートフルアプリケーションの場合は、両アプリケーション間を同期させるためにOracle Interconnect for Azureが必要です。さらに、Oracle Interconnect for Azureを利用することで、通常運用時に両方のアプリケーションからいずれのデータベースにもアクセスできる柔軟性も得られます。

Azureアプリケーションが主にAzureデータベースへ接続する場合は、次の接続文字列を使用してください。

Alias = (DESCRIPTION =
(CONNECT_TIMEOUT= 90)(RETRY_COUNT=100)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=1000ms)(LOAD_BALANCE=off)
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=azure-scan)(PORT=1521)))
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=oci-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = my_service)))

OCIアプリケーションが主にOCIデータベースへ接続する場合は、次の接続文字列を使用してください。

Alias = (DESCRIPTION =
(CONNECT_TIMEOUT= 90)(RETRY_COUNT=100)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=1000ms)(LOAD_BALANCE=off)
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=oci-scan)(PORT=1521)))
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=azure-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = my_service)))

ステートレスアプリケーション向けのサイト障害保護

ステートレスアプリケーションでは同期処理が不要なため、各アプリケーションがローカルデータベースのみにアクセスする場合は、Oracle Interconnect for Azureは必須ではありません。
もしデータベース障害やサイト全体の障害が発生した場合は、アプリケーションとデータベースの両方でフェイルオーバーが必要となります。
この構成では、AzureアプリケーションがAzure内のローカルデータベース、OCIアプリケーションがOCI内のローカルデータベースにアクセスするため、アプリケーションからデータベースへのレイテンシが最小になります。

AzureアプリケーションがAzureデータベースのみに接続する場合は、次の接続文字列を使用してください。

Alias = (DESCRIPTION =
(CONNECT_TIMEOUT= 90)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=1000ms)
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=azure-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = my_service)))

OCIアプリケーションがOCIデータベースのみに接続する場合は、次の接続文字列を使用してください。

Alias = (DESCRIPTION =
(CONNECT_TIMEOUT= 90)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=1000ms)
(ADDRESS_LIST =
(LOAD_BALANCE=on)
(ADDRESS = (PROTOCOL = TCP)(HOST=oci-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = my_service)))

参考情報

Data Guardを活用したディザスタリカバリの実装についてさらに詳しく知りたい方は、以下のリソースをご参照ください。