ExaDB-DとExaDB-XSで実現！クロスサービスData Guardでコスト最適化

以前の記事で、Oracle Exadata Database Service on Exascale Infrastructure（エクサスケール。以下、ExaDB-XSと表記）の小規模利用、スモールスタートが可能、柔軟なスケーリングといった特徴とメリットについて紹介しました。

Oracle Exadata Exascaleとは？注目のPaaSサービスが登場！その特徴とメリットに迫る
Exascaleがついに登場！「Oracle CloudWorld 2024」にてリリースされたOracle Cloudの注目のPaaSサービス「Oracle Exadata Database Service on Exascale Infrastructure（エクサスケール。略称：ExaDB-XS）」の特徴をまとめてみました！

そのExaDB-XSについて、2025年8月度のOracle Cloud Infrastructure（以下、OCI）サービスアップデートにてExaDB-XSとExadata Database Service on Dedicated Infrastructure（以下、ExaDB-D）間でData Guard構成を構築できるようになりました。このData Guard構成を「クロスサービスData Guard」と呼びます。

※Oracle Cloud Infrastructure: 2025年8月度サービス・アップデート（P.47）（オラクル社のサイトに移動します）
https://speakerdeck.com/oracle4engineer/oracle-cloud-update-summary-202508

本記事ではクロスサービスData Guardに焦点を当て、実際にクロスサービスData Guardを構成する検証と検証結果をとおして見えたメリットをご紹介します。

Index

検証の目的

今回の検証では、ExaDB-DとExaDB-XS間でクロスサービスData Guardが構成できることを確認します。
ExaDB-Dはユーザーが物理的な基盤を専有して利用できる専有インフラストラクチャで提供されていますが、ExaDB-XSはクラウドユーザー同士が物理的な基盤を共有して利用する共有インフラストラクチャです。

今回ポイントとなるのが、各サービスのストレージのアーキテクチャです。
ExaDB-XSは独自のストレージ管理方式を採用しているため、ExaDB-Dなどの従来のストレージ管理の方式（ASＭ）とは異なります。その異なるストレージの管理方式で稼働するサービス間でData Guard構成が構築できることを、今回は検証します。

検証環境の情報

今回、検証を実施したExaDB-DとExaDB-XSはそれぞれ以下の構成です。
※各サービスで利用するために必要なリソースが異なるため、CPU数やメモリ容量などの詳細なパラメータについては割愛します。

	ExaDB-D	ExaDB-XS
仮想マシン数（ノード数）	2	1
DB数	1	1

コスト比較

前提条件

まず、ExaDB-DとExaDB-XSのコストを比較しました。
それぞれのサービスで構築に必要な最低条件で1か月間稼働させたコストをCost Estimator_（※1）で試算しています。コスト試算のスペックと比較結果は以下のとおりです。

※1 Cost Estimator（オラクル社のサイトに移動します）
https://www.oracle.com/jp/cloud/costestimator.html

	ExaDB-D	ExaDB-XS
仮想マシン（台）	2	1
ストレージ	ストレージサーバー×3台	VMファイル・ストレージ：220（GB）データベース・ストレージ：300（GB）
仮想マシンあたりの有効ECPU数	8	8

コスト比較の結果

	ExaDB-D	ExaDB-XS	コスト差
インフラストラクチャの1か月あたりの金額（744h）	1,673,985 円	30,284 円	1,643,701 円
ECPU数の1か月あたりの金額（744h）	619,960 円	309,980 円	309,980 円
合計金額	2,293,945 円	340,264 円	1,953,681 円

上記のコスト比較の表から分かるように、クロスサービスData Guardを利用することで、インフラストラクチャの面で圧倒的なコストパフォーマンスを得ることができます。

サービス構築に必要な最低条件の場合、インフラストラクチャの面でExaDB-Dは、ExaDB-XSと比較すると約55倍のコストであることが分かります。ECPU数の面では、サービスが異なっていても単価は同一であり、仮想マシンが1台少ない分ExaDB-XSが1か月間のコストも半額になることがわかりました。インフラストラクチャとECPU合計金額の差額は約195万円となり、これは年間で換算すると約2,340万円（差額195万円 × 12ヶ月）の削減になります。

なお、ExaDB-XSは最小構成で試算をしていますが、スタンバイ環境として運用する場合はシステムの可用性や性能要件に応じてスペックを検討する必要があります。コスト面から考えたとき、このクロスサービスData Guardは、「本番環境は高性能なExaDB-Dが必要だが、スタンバイ環境は稼働頻度が極めて低い」といったお客様にとって、理想的な構成だと言えます。本検証の構成でも、上述のように、約2,340万円の削減効果が見込めます。

クロスサービスData Guard構築の検証結果

続いて、クロスサービスData Guardの検証結果は以下のとおりです。
検証ではExaDB-Dをプライマリ環境、ExaDB-XSをスタンバイ環境として構築し、検証しました。
構築したデータベース・ホームのバージョンは23.26.0.0.0のバージョンで検証を実施しています。

クロスサービスData Guard構築の流れは以下のとおりです。
①ネットワークの構築
はじめに、ExaDB-D、ExaDB-XSを構築するネットワーク（VCNやサブネットなど）を構築します。
②プライマリ環境（ExaDB-D）の構築
次に、プライマリ環境となるExaDB-D環境（インフラストラクチャ、VMクラスタ、データベース・ホーム、データベース）を構築します。

③スタンバイ環境（ExaDB-XS）の構築
続けて、スタンバイ環境となるExaDB-XS環境（VMクラスタ、データベース・ストレージ、データベース・ホーム）を構築します。
データベースはクロスサービスData Guardの有効化の際に作成されるため、プライマリ環境と同一バージョンのデータベース・ホームを作成します。

④クロスサービスData Guradの有効化
最後にOCIコンソールでクロスサービスData Guardを有効にします。
ExaDB-DのVMクラスタ画面でクロスサービスData Guardを有効にするデータベースを選択します。データベースの詳細画面でData Guradアソシエーションのタブを選択し「スタンバイの追加」をすることで、クロスサービスData Guradを有効化します。

クロスサービスData Guard作成時には以下を入力しました。

項目	値
Data Guardリソース・タイプ	新規Data Guradグループ・リソースの使用
ピア・リージョン	Japan East（Tokyo）（任意のリージョンを選択）
可用性ドメイン	自動入力
サービスの選択	Oracle Exadata Database Service on Exascale Infrastructure
VMクラスタ	作成したExaDB-XSのVMクラスタを選択
Data Guardタイプ	Actice Data Gurad
データベース・ホーム	作成したExaDB-XSのデータベース・ホームを選択
スタンバイ・データベース	指定無し（自動で「CDB_xxx_nrt」（xxxはランダム英字3字）に命名されます。）
データベース・パスワード	任意の値
TDEウォレット・パスワード	任意の値
Oracle SID接頭辞	sby（任意の値）

40分ほどでエラーもなく構築が完了しました。
実際に仮想マシンに接続してData Guardの状態を確認します。
今回の検証では、Oracle DatabaseのData Guard構成を管理・監視・自動化するためのフレームワークである「Oracle Data Guard Broker」で確認しました。

[oracle@xxxxxxxxxx ~]$ dgmgrl /
DGMGRL for Linux: Release 23.26.0.0.0 - for Oracle Cloud and Engineered Systems on Fri Oct 31 16:44:15 2025
Version 23.26.0.0.0
　　
Copyright (c) 1982, 2025, Oracle and/or its affiliates.  All rights reserved.
　　
Welcome to DGMGRL, type "help" for information.
Connected to "TESTCDB_xxx_nrt"
Connected as SYSDG.
DGMGRL> show configuration verbose;
　　
Configuration - testcdb_dgconf
　　
  Protection Mode: MaxPerformance
  Members:
  TESTCDB_xxx_nrt - Primary database
    TESTCDB_yyy_nrt - Physical standby database 
　　
  Properties:
    BystandersFollowRoleChange      = 'ALL'
    CommunicationTimeout            = '180'
    ConfigurationSimpleName         = 'testcdb_dgconf'
    ConfigurationWideServiceName    = 'TESTCDB_CFG'
    DrainTimeout                    = '0'
    ExternalDestination1            = ''
    ExternalDestination2            = ''
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverLagGraceTime   = '0'
    FastStartFailoverLagLimit       = '30'
    FastStartFailoverLagType        = 'APPLY'
    FastStartFailoverPmyShutdown    = 'TRUE'
    FastStartFailoverThreshold      = '30'
    ObserverOverride                = 'FALSE'
    ObserverPingInterval            = '0'
    ObserverPingRetry               = '0'
    ObserverReconnect               = '0'
    OperationTimeout                = '30'
    PrimaryDatabaseCandidates       = ''
    PrimaryLostWriteAction          = 'CONTINUE'
    TraceLevel                      = 'USER'
　　
Fast-Start Failover:  Disabled
　　
Configuration Status:
SUCCESS   (status updated 35 seconds ago)

上記の実行結果より、TESTCDB_xxx_nrtがプライマリ環境、TESTCDB_yyy_nrtがスタンバイ環境であることが確認できます。Data GuradのステータスもSUCCESSであり、正常な状態です。

続いて各データベースの状態を確認します。

DGMGRL>  show database verbose B TESTCDB_xxx_nrt
　　
Database - TESTCDB_xxx_nrt
　　
  Role:                PRIMARY
  Intended State:      TRANSPORT-ON
  Redo Rate:           112 Byte/s  in 15 seconds (computed 14 seconds ago) 
  Instance(s):
    TESTCDB1
    TESTCDB2
　　
  Properties:
    AlternateLocation               = ''
    ApplyInstanceTimeout            = '0'
    ApplyInstances                  = '0'
    ApplyLagThreshold               = '30'
    ApplyParallel                   = 'AUTO'
    ArchiveLocation                 = ''
    Binding                         = 'OPTIONAL'
    DGConnectIdentifier             = 'TESTCDB_xxx_nrt'
    DelayMins                       = '0'
    FastStartFailoverTarget         = 'TESTCDB_yyy_nrt'
    InconsistentLogXptProps         = '(monitor)'
    LogXptMode                      = 'ASYNC'
    LogXptStatus                    = '(monitor)'
    MaxFailure                      = '0'
    NetTimeout                      = '30'
    PreferredApplyInstance          = ''
    PreferredObserverHosts          = ''
    RecvQEntries                    = '(monitor)'
    RedoCompression                 = 'DISABLE'
    RedoRoutes                      = ''
    ReopenSecs                      = '300'
    SendQEntries                    = '(monitor)'
    SidName(*)
    StandbyAlternateLocation        = ''
    StandbyArchiveLocation          = ''
    StaticConnectIdentifier(*)
    TopWaitEvents(*)
    TransportDisconnectedThreshold  = '30'
    TransportLagThreshold           = '30'
    UserManagedParams               = ''
    (*) - Please check specific instance for the property value
　　
  Log file locations(*):
    (*) - Check specific instance for log file locations.
　　
Database Status:
SUCCESS
　　
DGMGRL> show database verbose TESTCDB_yyy_nrt
　　
Database - TESTCDB_yyy_nrt
　　
  Role:                PHYSICAL STANDBY
  Intended State:      APPLY-ON
  Transport Lag:       0 seconds (computed 1 second ago)
  Apply Lag:           0 seconds (computed 1 second ago)
  Average Apply Rate:  4.00 KByte/s
  Active Apply Rate:   177.00 KByte/s
  Maximum Apply Rate:  177.00 KByte/s
  Real Time Query:     ON
  Instance(s):
    sby1
　　
  Properties:
    AlternateLocation               = ''
    ApplyInstanceTimeout            = '0'
    ApplyInstances                  = '0'
    ApplyLagThreshold               = '30'
    ApplyParallel                   = 'AUTO'
    ArchiveLocation                 = ''
    Binding                         = 'OPTIONAL'
    DGConnectIdentifier             = 'TESTCDB_yyy_nrt'
    DelayMins                       = '0'
    FastStartFailoverTarget         = 'TESTCDB_xxx_nrt'
    InconsistentLogXptProps         = '(monitor)'
    LogShipping                     = 'ON'
    LogXptMode                      = 'ASYNC'
    LogXptStatus                    = '(monitor)'
    MaxFailure                      = '0'
    NetTimeout                      = '30'
    ObserverConnectIdentifier       = ''
    PreferredApplyInstance          = ''
    PreferredObserverHosts          = ''
    RecvQEntries                    = '(monitor)'
    RedoCompression                 = 'DISABLE'
    RedoRoutes                      = ''
    ReopenSecs                      = '300'
    SendQEntries                    = '(monitor)'
    SidName                         = '(monitor)'
    StandbyAlternateLocation        = ''
    StandbyArchiveLocation          = ''
    StaticConnectIdentifier         ='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.xxx)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=TESTCDB_yyy_nrt_DGMGRL.xxxxxxxxxxx.oraclevcn.com)(INSTANCE_NAME=sby1)(SERVER=DEDICATED)))'
    TopWaitEvents                   = '(monitor)'
    TransportDisconnectedThreshold  = '30'
    TransportLagThreshold           = '30'
    UserManagedParams               = ''
　　
  Log file locations:
    '/u02/app/oracle/diag/rdbms/TESTCDB_yyy_nrt/sby1/trace'
　　
Database Status:
SUCCESS
　　
DGMGRL>
)

データベースの状態も正常であることが確認できます。プライマリ環境のExaDB-DのDBはTESTCDB_xxx_nrtであり、ノードが2つ存在しています。スタンバイ環境のExaDB-XSはノードが1つであることも確認できます。

上記の結果より、異なるサービス間、ストレージのアーキテクチャでも正常にData Guard構成を構築することができました。

クロスサービスData Guardのメリット

クロスサービスData Guardの構築検証結果を通じて、ストレージ管理方式の異なるExaDB-DとExaDB-XS間でも問題なくData Guardを構成できることが確認できました。この仕組みを活用する最大の利点は、前述のコスト比較結果が示すとおり、優れたコストパフォーマンスを実現できる点にあります。スタンバイ環境のコストを最適化しながらも、高い可用性を確保したいシナリオにおいて、理想的な選択肢となるでしょう。

その他にもクロスサービスData Guardは、ExaDB-D、ExaDB-XSの各サービス間の移行にも活用できます。Oracle Data Guradの機能を利用することで、サービスのダウンタイムを最小に抑え、サービス継続性を確保したままDB移行を実現できます。

さいごに

今回はExaDB-XSとExaDB-D間でData Guardを構成するクロスサービスData Guardの概要と実際の検証結果、利用するメリットをご紹介しました。

プライマリ環境の性能を維持したまま、スタンバイ環境のランニングコストを下げることができるため、システムのコスト効率を重視する企業にとって理想的な選択肢といえるでしょう。

次回以降もOCIの新機能をご紹介する予定です！

執筆者情報

深谷憲司（ふかやけんじ）

2024年に中途入社。前職では主にOracleのオンプレミス環境の設計構築から運用保守と幅広い業務を経験。
現在はOCIのポストセールス業務を中心に担当。
趣味はパフェ巡り。

■本記事の内容について
　本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。

■商標に関して
　・Oracle®、Java及びMySQLは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
　・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
　　文中の社名、商品名等は各社の商標または登録商標である場合があります。

【Oracle AI Database 26ai】同時リフレッシュでON COMMITマテリアライズド・ビューのenqueue待ちにサヨナラ！OLTP／DWHスループットを実測検証

本記事では、従来のON COMMIT MViewが抱えてきたこのようなスループット低下や待機イベントのボトルネックを振り返りつつ、Oracle AI Database 26aiが提供する「同時リフレッシュ（Concurrent Refresh）」によって、OLTP／DWHそれぞれのユースケースでどのような改善が見込めるのかを検証していきます。