はじめに
お疲れ様です。矢儀 @yuki_ink です。
Oracle Database@AWS は、AWS データセンター内の OCI（Oracle Cloud Infrastructure）管理インフラ上で Oracle Exadata を動かすサービスです。
Oracle Database@AWS を使用すると、データベースや関連するアプリケーションへの変更を最小限に抑えて、または変更を加えることなく Oracle Real Application Clusters (RAC) を含む Oracle Exadata Database ワークロードを簡単かつ迅速に移行できます。
Oracle RACがAWSで使える!! 嬉しい!!
そして現在、東京リージョンと大阪リージョンでも利用可能!! 嬉しい!!
Oracle AI Database 26ai が @AWS でも利用可能になったタイミングで、「Oracle Database@AWS」から「Oracle AI Database@AWS」とブランド表記が変わっているようです。
この記事では、以下「ODB@A」と表記します。
ODB@A の主要コンポーネント
本記事の前提として、ODB@A の主要コンポーネントをまとめておきます。
| コンポーネント | 概要 |
|---|---|
| Exadataインフラストラクチャ | 特定 AZ に固定された物理サーバー群（後から AZ は変更不可） |
| ODBネットワーク | Exadata の上に作る仮想ネットワーク（作成すると OCI 上に VCN が自動生成され、ODB ネットワークと VCN が 1:1 でマッピングされる） |
| ODBピアリング | AWS の VPC と ODB ネットワークを接続するリソース（VPC ピアリング同様、推移的ピアリングはサポートされていない） |
| VMクラスタ | ODB ネットワーク内に作る VM 群（この上にDBを作る） VMクラスタの作成時に ODB ネットワークと Exadata インフラストラクチャを指定する |
「Exadataインフラストラクチャ」がサーバをホストする物理レイヤ、「ODBネットワーク」が論理的なネットワークレイヤで、両者に縦串を通すのが「VMクラスタ」、AWS環境との接続を担うのが「ODBピアリング」という理解です。
関係性を図示するとこんな感じです。
AWSのデータセンターの中に「OCI child site」があり、その中でリソースが配置されるようですね。
「OCI child site」は「OCI parent region（＝OCIリージョン）」の拡張という扱いです。
そしてコントロールプレーンは「OCI parent region」側にあります。
「コントロールプレーンはOCI側にある」ということで、お察しかもしれませんが、Exadata インフラストラクチャのスケーリングや、VMクラスタやDBの作成はOCIコンソールでやらないといけません。
「Oracle Database@AWS」という名前ですが、全然AWSで完結しません。
AWSアカウントと紐づけるOCIテナンシの用意が必須で、OCIコンソールへのログイン環境も必須です😭
この点は今後の改善に期待したいところです。
課題意識
ODB@A を使い始めるとき、最初に直面する課題の1つがリソースの大きさ＝固定費の高さです。
Exadata インフラストラクチャは最小構成が「2つのDBサーバ + 3つのストレージサーバ」となっています。
Exadata X11Mのスペックは以下の通りですから、
A single database (DB) server contains 760 ECPUs and 1390 GB of memory.
A single storage server contains 80 TB of usable disk storage capacity.
ODB@AでExadata インフラストラクチャを作ろうとすると、最低でもこれだけのスペックのモノが出来上がるということです。
| 項目 | 最小構成 |
|---|---|
| CPU | 760 ECPU × 2 = 1,520 ECPU |
| メモリ | 1,390 GB × 2 = 2,780 GB |
| ストレージ容量 | 80 TB × 3 = 240 TB |
ちなみにお値段はこちら。
2階建ての構成となっており、「筐体部分は固定費として発生、その上にVMが起動すればその分（ECPUに基づいて）従量課金が発生」というスタイルです。
1階部分＝固定費だけで毎月約170万円!! やば!!
ということで、こんなものを、たった1つのアプリケーションのためだけに用意するなんてケースはあまりないのではと思います。
そんなことをしても、キャパシティを持て余してしまうでしょう。
そこで現実的な解が「1つの Exadataインフラストラクチャを複数のアプリケーションで共用する」という構成です。
ODB@A はこれを想定した設計になっており、1 つの Exadata インフラストラクチャの上に複数の ODB ネットワーク（仮想ネットワーク）と VMクラスタ（DB の実行環境）を載せることができます。
この記事では、「1つの Exadata インフラストラクチャを複数のアプリケーションで共用する」際の勘所を整理します。
1つのExadataインフラストラクチャのリソースを、複数のODBネットワーク上のVMクラスタで共用できる!!
まず大前提として、Exadataインフラストラクチャ（物理）と ODBネットワーク（論理）は独立したコンポーネントです。
1つのExadataインフラストラクチャのリソースを、複数のODBネットワーク上のVMクラスタで共有して利用することも可能です。
そして、そのODBネットワークとアプリケーションVPCをピアリングさせることで、次のような構成をとることができます。
クロスアカウント前提で図を書いてしまいましたが、「バイヤーアカウント」の中に存在するVPCとODBネットワークとをピアリングすることも当然可能です!!
「バイヤーアカウント」とは、ODB@Aの利用前提となる「プライベートオファー」をリクエストし、OCIテナンシーとリンクされたAWSアカウントの呼称です。
ODB@Aの利用料に対する請求はバイヤーアカウントに集約されます。
「Multiple ODB Peerings」がサポートされてから、取れる選択肢が増えました。
上図に書けてないパターンもあるので（1つのVPCから複数のODBネットワークに接続するパターン）、こちらも併せてご確認ください。
クロスアカウントでExadataインフラストラクチャを共有するときの留意点
特にエンタープライズ環境では、アプリケーションごとにAWSアカウントを分離する構成が多く採用されています。
1つのExadataインフラストラクチャを複数アプリで共用する構成でも、クロスアカウントが前提となるケースがほとんどだと思います。
ここでは、クロスアカウントでODB@Aを利用する際に押さえておくべき留意点を整理します。
バイヤーアカウント1つにつき OCI テナンシーは1つだけ
ODB@A を使うには、「バイヤーアカウント」となるAWSアカウントからOracle にプライベートオファーをリクエストする必要があります。
そして、プライベートオファーが発行され、いざバイヤーアカウントでODB@AをアクティベートするときにOCIテナンシーを紐付けすることになります（OCIテナンシーは新規作成もできるし、既存のテナンシーを選択することもできる）。
このとき、プライベートオファー・バイヤーアカウント・OCIテナンシーの関係は、1:1:1になります。
本番環境・開発環境などで、OCI テナンシーごと分離する要件がある場合は、バイヤーアカウントおよびプライベートオファーを環境ごとに分離する必要があります。
クロスアカウント共有のやり方は2パターンある
ODB@Aのリソースをバイヤーアカウント以外のアカウントから利用させる方法は、大きく2つあります。
- Entitlement Sharing（AWS License Managerによるサブスクリプション共有）
- Resource Sharing（AWS Resource Access Managerによるリソース共有）
①Entitlement Sharing（AWS License Managerによるサブスクリプション共有）
バイヤーアカウント（権限付与者）が、AWS License Managerを通じて、ODB@Aのサブスクリプションそのものを別アカウント（権限受領者）に共有する方法です。
Resource Sharingとは異なり、権限受領者アカウントは独立したODB@A利用者として、ExadataインフラストラクチャやODBネットワークを自ら作成・管理できるようになります。
| 項目 | 内容 |
|---|---|
| 共有の仕組み | AWS License Managerで「付与（Grant）」を作成 |
| 共有先でできること | Exadataインフラストラクチャ・ODBネットワーク・VMクラスタの作成・管理（＝フル操作） |
| 注意点 | 権限受領者アカウントは同時に1つの権限付与者からしか付与を受け取れない。 共有は同一AWS Organization内のみ。 1付与者が共有できる権限受領者は最大50アカウント。 Entitlement Sharingの操作（付与の作成）は、バージニア北部リージョン（us-east-1）からのみ実行可能。 |
②Resource Sharing（AWS Resource Access Managerによるリソース共有）
AWS Resource Access Manager（RAM）を使って、バイヤーアカウントで作成済みのExadataインフラストラクチャおよびODBネットワークを別アカウントに共有する方法です。
共有先アカウントは共有されたリソースを「借りて使う」形となり、VMクラスタの作成など一部の操作は共有先から行えますが、ExadataインフラストラクチャおよびODBネットワーク自体の変更・削除はバイヤーアカウントのみが行えます。
| 項目 | 内容 |
|---|---|
| 共有の仕組み | AWS RAMでリソース共有（Resource Share）を作成 |
| 共有先でできること | VMクラスタの作成・DBの利用（Exadataインフラストラクチャ・ODBネットワーク自体の変更・削除は不可） |
| 注意点 | 後述の制約（同一Organization内のみ、1バイヤーからのみ受け取り可能等）あり |
どちらを選ぶか
前提として、共有の受け側は 1 バイヤーアカウントからのみという点は理解しておく必要があります。
いずれのパターンでも、共有の受け側のAWSアカウントでODB@Aをアクティブ化する必要がありますが、そのアクティベーションプロセスの中で、バイヤーアカウント（＝プライベートオファー）と紐づけを1:1にする必要があるようです。
つまり、プライベートオファーを1本しか持っていなければ、「Entitlement Sharing」であれ「Resource Sharing」であれ、裏側で紐づくOCIテナンシーは1つだけで、結局は全てのリソースは1つのOCIテナンシーの中でホストされます。
それであれば、ODB@Aリソースを管理するAWSアカウントはバイヤーアカウント1つに絞る、つまり「Entitlement Sharing」ではなく「Resource Sharing」を前提として設計する方がシンプルで合理的だと思います。
「ODB@Aの管理アカウントは複数あるけど、それに紐づくOCIテナンシーは1つだけ」という状況は避けた方が無難です。
OCIテナンシーのことを全く考えなくていいなら話は違いますが、現状、ODB@Aの構築・保守運用ではOCIテナンシーへログインして操作することが必須です。
AWSとOCIでアカウント分離の考え方が異なるのは大きなストレスです。
また、「1つのExadataインフラストラクチャを共用する」という趣旨を踏まえると、ODB@Aの管理アカウントは単一にして「基盤化」しておいた方が良いでしょう。
そのため、この記事では「Resource Sharing」を推奨し、以下の内容はそれを前提として記述します。
クロスアカウント共有の制約
バイヤーアカウントとRAM 共有先は 1:多（1 バイヤー → 複数のアプリアカウントへ共有可）の関係になります。
他にも制約がありますので、これらを認識した上でクロスアカウント設計をするようにしましょう。
| 制約 | 詳細 |
|---|---|
| 同一 AWS Organization 内のみ | Organization 外のアカウントとは共有不可。 ODB@Aリソースの共有の前提として、Organizations内共有を有効化しておく必要がある。 |
| クロスリージョン共有不可 | 同一リージョン内のみ。 |
| 変更・削除はオーナーのみ | 共有先（トラステッドアカウント）はリソースの参照・利用のみ。変更・削除不可。 |
📎 参考にしたドキュメント
AZ の指定
ODB@A の Exadata インフラストラクチャは作成時に指定した AZ に固定されます（後から変更不可）。
この時に落とし穴になるのが AZ 名と AZ-ID の違いです。
AWS の AZ 名（例：ap-northeast-1a）はアカウントごとにシャッフルされているため、アカウント A の ap-northeast-1a とアカウント B の ap-northeast-1a が異なる物理 AZ を指していることがあります。
物理 AZ を一意に特定するのが AZ-ID（例：apne1-az4）です。
例えば、東京リージョンで ODB@A が利用可能な AZ-ID は apne1-az1 と apne1-az4 の 2 つですが、その2つのAZに対して各AWSアカウントでどのようなAZ名が割り振られているのかは、実際に確認してみないと分かりません。
# 自分のアカウントで AZ 名と AZ-ID の対応を確認する
aws ec2 describe-availability-zones \
--region ap-northeast-1 \
--query 'AvailabilityZones[*].{Name:ZoneName,ID:ZoneId}' \
--output table
クロスアカウント構成では、アカウントをまたいで AZ-ID を照合しないと、意図せず AZ 間通信が発生し、レイテンシも増加します。
AZ 名ではなく AZ-ID を基準に設計・実装することが根本的な対策です。
📎 参考にしたドキュメント
クロスアカウント構成を実現するための構築の流れ
以下のようなクロスアカウント構成を実現するための、基本的な環境構築の流れを整理します。
- 前提として、Organizations管理アカウントでOrganizations内共有を有効化しておく
- バイヤーアカウントで、ODBネットワークとExadataインフラストラクチャを作成する
- バイヤーアカウントで、アプリアカウントに対して、ODBネットワークとExadataインフラストラクチャをRAMで共有する
- アプリアカウントでVMクラスタを作成する
- アプリアカウントでODBピアリングを作成し、App VPC側のルートテーブルを設定する
ここまで来たら、OCIコンソール側でDBの構築を進めるだけです。
各操作の具体的な手順は、公式ドキュメントを参照してください。
その他の設計ポイント
クロスアカウント共有の留意点を踏まえた上で、実際の設計で考えるべきその他のポイントを書いていきます。
ODB@A の名前解決をするための Route 53 Resolver の利用
ODB ネットワークにピアリングで接続しただけでは、Exadata の SCAN アドレス（*.oraclevcn.com ドメイン）の名前解決ができません。
ODB ネットワーク作成時、それと紐づくVCNがOCI側で作成されるタイミングで、DNS リスニングエンドポイントが自動生成されるため、AWS 側から DNS クエリをそこへ転送する設定が必要です。
具体的には、Route 53 Resolver のアウトバウンドエンドポイントを作成し、*.oraclevcn.com 向けの FORWARD ルールで OCI 側の DNS リスニングエンドポイントに転送するように設定します。
Exadata インフラストラクチャを複数アプリで共用する構成で、アプリアカウントも複数になる場合では、 Route53 Resolver アウトバウンドエンドポイントをアカウントごとに作るのではなく、1つのアカウントにだけ作成し、リゾルバールールを RAM で各アプリアカウントに共有する構成を推奨します。
エンドポイントの管理を1か所に集約でき、新しいアプリアカウントを追加するたびにエンドポイントを追加する必要がないため、コストメリットがあります。
バイヤーアカウントにアウトバウンドエンドポイントを作るなら、こんな感じ。
Route53 Resolver アウトバウンドエンドポイントを作成するのは、必ずしもODB@Aのバイヤーアカウントである必要はありません。
既にアウトバウンドエンドポイントを用意されている環境では、それを使い回してください。
ODB ネットワークを追加するたびに、そのドメイン向けのリゾルバールールを新たに作成して、各アカウントに共有し、VPCに関連付ける必要があります。
📎 参考にしたドキュメント
EC2 を Exadata の近くに配置するためのプレイスメントグループと ODCR の利用
ODB ネットワークを作成するとクラスタープレイスメントグループが自動作成されます。
EC2 起動時にこれを指定することで Exadata と物理的に近い場所に配置され、レイテンシを最小化できます。
なんと追加費用なし!! ぜひ利用しましょう。
あわせて On-Demand Capacity Reservation（ODCR） でインスタンスキャパシティを事前確保しておくことを推奨します。
プレイスメントグループを指定しても、その AZ でキャパシティが枯渇していれば起動できないためです。
📎 参考にしたドキュメント
Exadata 上の DB から AWS マネージドサービスへアクセスするための VPC Lattice の利用
Exadata 上の DB から S3 や SQS などの AWS マネージドサービスにアクセスしたい場合、VPC Lattice を使う方法があります。
ODB ネットワークは通常の VPC とは異なる経路で接続されるため、VPC エンドポイント（PrivateLink）を直接 ODB ネットワーク側に作成することができません。
VPC Lattice を経由することで、ODB ネットワーク内のリソースから AWS マネージドサービスへのプライベートアクセスが実現します。
📎 参考にしたドキュメント
将来的なExadataインフラストラクチャのスケールアウトの想定
Exadata インフラストラクチャは作成後にスケールアウト（DB サーバー・ストレージサーバーの追加）が可能です。
当初は最小構成（DB 2台・ストレージ 3台）で始めても、後から増強できる点は安心材料です。
現時点でスケールアウトの操作は OCI コンソールまたは OCI CLI からしか行えません。
AWS コンソール・AWS CLI からは実施できないため、OCIへのアクセス手段を確保しておく必要があります。
OCI テナンシー側のサービスクオータ上限緩和が必要
デフォルトの OCI サービスクオータは DB サーバー 2台・ストレージサーバー 3台（＝最小構成）に設定されています。
スケールアウトするには事前に OCI テナンシー側でサービスクオータの上限緩和申請が必要です。
スケールアウトを検討している場合は、実際に増強が必要になってから上限緩和では時間がかかるため、設計段階で必要な上限値を見積もって早めに申請しておくことを推奨します。
Exadataインフラストラクチャに作れるVM / VMクラスタの上限
スケールアウトでリソースを増やせるとはいえ、1つのExadataインフラストラクチャに作成できるVMクラスタは最大8個という制限があります。
また、1つのDBサーバ上で起動できるVMも最大8個です。
With support for multiple virtual machine clusters (MultiVM), you can support up to eight VMs per database server and host a total of eight VM clusters per Exadata database system.
（日本語訳）マルチ仮想マシン クラスタ (MultiVM) のサポートにより、データベース サーバーごとに最大 8 台の VM をサポートし、Exadata データベース システム全体で合計 8 台の VM クラスタをホストできます。
（出典）Oracle Database@AWSでOracle Exadata Database Serviceをプロビジョニングする
共用するアプリケーション数が増える見込みがある場合は、この上限を考慮した上で Exadata インフラストラクチャ構築の計画を立てる必要があります。
1台のDBサーバのリソース配分
VM1台あたりに搭載できるECPU、メモリ、ローカルファイルシステム(/u02)は以下の通りです。
ただ、「じゃあ各パラメータをとりあえずMAXにしておくか!!」とお行儀の悪いアプリが出てきた場合、そのアプリだけでDBサーバのリソースを食い潰してしまうかもしれません。
特にローカルファイルシステムについては、意外と余裕がありません😓
ローカルファイルシステムを贅沢に使ってしまうと、「ECPUとメモリはめちゃくちゃ余っているのにローカルファイルシステムの残容量がないから、これ以上このDBサーバにVMを追加できない!!」となるケースも出てくると思います。
この点を踏まえ、それぞれのVMクラスタをどのDBサーバで起動するか（どのDBサーバにVMを立てるか）という、ジグゾーパズルのような計画が重要になります。
CIDR 設計
ODB ネットワーク（クライアントサブネット・バックアップサブネット）のCIDRは後から変更できません。
複数の ODB ネットワークを作成して同一 Exadata インフラストラクチャのリソースを共用する構成も含め、IP アドレス計画は事前に行ってください。
- 既存の VPC・オンプレミスとの CIDR 重複を避ける
- AZ ごとに異なる CIDR ブロックを割り当てる（マルチ AZ 構成を見越す場合）
-
169.254.0.0/16等の OCI リンクローカル CIDR とも衝突しないこと
詳しくはこちらを参照してください。
IAM 設計
ExadataインフラストラクチャおよびODBネットワークをResource Sharing構成で複数アプリに共用する場合、1つのAWSアカウント/OCIテナンシーにリソースが集中します。
各アプリ担当者にVMクラスタやその上のVM・DBの操作を行わせる場合、IAMの設計が重要になってきます。
アプリAの担当者がアプリBのDBを消しとばす、ということはあってはなりません!!
IAM設計については、長くなりそうなので、別途記事を書きたいと思います。
参考リンク
最後に、ODB@Aの利用にあたり、読んでおきたいドキュメントをまとめます。
サービス概要・アーキテクチャ
| 内容 | URL |
|---|---|
| Oracle ドキュメント: Oracle AI Database@AWS（公式サイト・日本語） | https://www.oracle.com/jp/cloud/aws/ |
| Oracle ドキュメント: Oracle AI Database@AWS 全体ドキュメント | https://docs.oracle.com/en-us/iaas/Content/database-at-aws/oaaws.htm |
| AWS ドキュメント: Oracle Database@AWS の仕組み | https://docs.aws.amazon.com/odb/latest/UserGuide/how-it-works.html |
| AWS ドキュメント: Oracle Database@AWS 入門 | https://docs.aws.amazon.com/odb/latest/UserGuide/getting-started.html |
| Oracle ドキュメント: 利用可能リージョン一覧 | https://docs.oracle.com/en-us/iaas/Content/database-at-aws/oaaws-regions.htm |
| AWS ブログ: Oracle Database@AWS の Well-Architected 設計 | https://aws.amazon.com/jp/blogs/database/well-architected-design-for-resiliency-with-oracle-databaseaws/ |
ODB ネットワーク・ピアリング設計
| 内容 | URL |
|---|---|
| Oracle ドキュメント: ODB ネットワーク設計（ピアリング上限・旧ネットワーク再作成制約） | https://docs.oracle.com/en-us/iaas/Content/database-at-aws/oaaws-network-odb-network.htm |
| AWS ドキュメント: ODB ピアリングの設定（DNS 設定含む） | https://docs.aws.amazon.com/odb/latest/UserGuide/configuring.html |
| Oracle ドキュメント: Oracle Database@AWS のネットワーク設計全体 | https://docs.oracle.com/ja/solutions/deploy-oracle-db-aws/#GUID-76C09F0C-1550-4520-9741-22A2EB88B720 |
High Performance Networking・プレイスメントグループ・ODCR
| 内容 | URL |
|---|---|
| AWS ドキュメント: High Performance Networking の概要 | https://docs.aws.amazon.com/odb/latest/UserGuide/high-performance-networking.html |
| AWS ドキュメント: High Performance Networking の設定手順 | https://docs.aws.amazon.com/odb/latest/UserGuide/hpn-getting-started.html |
| AWS ドキュメント: プレイスメントグループのクロスアカウント共有 | https://docs.aws.amazon.com/odb/latest/UserGuide/hpn-sharing-placement-group.html |
DNS 名前解決（Route 53 Resolver）
| 内容 | URL |
|---|---|
| AWS ドキュメント: ODB ピアリングの DNS 設定手順 | https://docs.aws.amazon.com/odb/latest/UserGuide/configuring.html#configuring-dns |
| AWS ドキュメント: Route 53 Resolver による VPC 間 DNS クエリの解決 | https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html |
| AWS ドキュメント: Route 53 Resolver エンドポイントと転送ルールの RAM 共有 | https://docs.aws.amazon.com/whitepapers/latest/hybrid-cloud-dns-options-for-vpc/route-53-resolver-endpoints-and-forwarding-rules.html |
バックアップ・AWS マネージドサービスへのアクセス（S3・VPC Lattice）
| 内容 | URL |
|---|---|
| AWS ドキュメント: Oracle Database@AWS のバックアップ | https://docs.aws.amazon.com/odb/latest/UserGuide/managing-backups.html |
| AWS ドキュメント: VPC Lattice を使った OCI マネージドバックアップ（S3 連携） | https://docs.aws.amazon.com/vpc-lattice/latest/ug/vpc-lattice-oci-managed-backup.html |
| AWS ブログ: Oracle Database@AWS のバックアップ・リカバリ選択肢の整理 | https://aws.amazon.com/blogs/database/navigating-backup-and-recovery-options-for-oracle-databaseaws/ |
| AWS re:Post: VPC Lattice を使った ODB ネットワークから AWS マネージドサービスへのアクセス | https://repost.aws/ja/articles/AR2TOdAL0KT-mTYZUefV_hPQ/accessing-aws-managed-services-from-odb-network-using-amazon-vpc-lattice |
AWS RAM 共有・クロスアカウント構成
| 内容 | URL |
|---|---|
| AWS ドキュメント: Oracle Database@AWS のリソース共有（制約一覧） | https://docs.aws.amazon.com/odb/latest/UserGuide/resource-sharing.html |
| AWS ドキュメント: Oracle Database@AWS リソースのクロスアカウント共有手順 | https://docs.aws.amazon.com/odb/latest/UserGuide/sharing-resources-task.html |
| AWS ドキュメント: トラステッドアカウントでの共有リソースの操作 | https://docs.aws.amazon.com/odb/latest/UserGuide/working-with-shared-resources.html |
MAA 認定・Data Guard
| 内容 | URL |
|---|---|
| Oracle ブログ: Oracle Database@AWS の Gold MAA 認定取得（Silver・Gold 両認定の詳細） | https://blogs.oracle.com/maa/oracle-databaseaws-achieves-gold-maa-certification |
| Oracle ブログ: Diamond ティアの追加（2026/02）と次世代 MAA の概要 | https://blogs.oracle.com/maa/ascend-to-the-diamond-tier-introducing-the-next-gen-oracle-maximum-availability-architecture-maa |
| Oracle ドキュメント: Oracle Database@AWS の MAA 参照アーキテクチャ（Silver/Gold） | https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/oracle-maximum-availability-architecture-oracle-databaseaws.html |
クロス AZ Data Guard・FSFO
| 内容 | URL |
|---|---|
| Oracle ドキュメント: Oracle Database@AWS でのクロス AZ Data Guard 実装手順 | https://docs.oracle.com/en/solutions/cross-zone-dr-db-at-aws/ |
クロスリージョン Data Guard・Far Sync
| 内容 | URL |
|---|---|
| Oracle ドキュメント: Oracle Database@AWS でのクロスリージョン Active Data Guard | https://docs.oracle.com/en/solutions/implement-dr-cross-region-dg-odb-aws/index.html |
| Oracle ドキュメント: Oracle Database@AWS でのリージョン間 Active Data Guard Far Sync | https://docs.oracle.com/en/solutions/dr-active-dg-farsync-db-at-aws/index.html |