Oracle AI Database@Azure で Exadata を 2 系統用意できたら、次にやりたくなるのはやはり Active Data Guard です。 ただ、実際に運用を考えると、Standby を作るだけでは足りません。Switchover / Failover / Reinstate が正しく動くこと、接続先サービスをロールに応じて切り替えられること、さらにアプリケーション側から見た継続性まで考えておきたいです。
Oracle Active Data Guard を使用することで、エンタープライズ データの高可用性、データ保護、および災害復旧を保証します。計画的または計画外の停止のために本番データベースが使用できなくなった場合、スタンバイ・データベースをプライマリ・ロールに切り替えて、ダウンタイムを最小限に抑えることができます。
また、Oracle Data Guard を使用すると、管理者はオプションで、リソースを大量に消費するDWHレポート処理や検証作業をスタンバイ システムにオフロードすることで、本番データベースのパフォーマンスを向上させることができます。
Active Data Guard の機能にはつぎのものがあります。
-
複数のスタンバイ・データベースの障害時リカバリ
稼動中のデータベースの1つまたは複数の同期コピーを管理するため、プライマリ・データベースの予期しない停止が発生した場合でも、データ損失ゼロを実現できます。 -
インメモリー・データベース・レプリケーション
ディスク破損などの根本的な破損から確実に分離でき、レプリケートされたデータブロックの包括的な自動検証機能を利用できます。 -
読み取り専用以上のワークロードをスタンバイ・データベースにオフロード
Oracle DMLリダイレクトにより、アプリケーションはスタンバイ・データベースからデータを操作できるため、プライマリ・データベースの重要なリソースを解放できます。スタンバイ・データベースの使用量が増え、最終的には投資利益率も向上します。 -
ファスト・スタート・フェイルオーバー（FSFO）
Oracle Data Guard Brokerは、人の介入を必要とせずにスタンバイ・データベースに自動的にフェイルオーバーできます。 -
自動ブロック修復
スタンバイ・データベースの破損したデータベースをユーザーに意識させることなく自動的にリカバリします。 -
遠隔同期
ネットワーク・レイテンシを発生させずに、サイトの障害時にあらゆる距離でデータ損失ゼロを実現します。 -
アプリケーション・コンティニュイティ
リカバリ可能な停止の後に処理中のデータベース・トランザクションをリカバリすることで、エンドユーザーやアプリケーションへの停止の影響を排除します。 -
データベースのローリング・アップグレード
システムに別のソフトウェアを追加する手間をかける必要なく、データベースのバージョン・アップグレードによる停止時間を短縮します。
ということで今回は、Oracle Database@Azure 上の Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) を Zone2 / Zone3 に配置し、Active Data Guard 構成を実施しました。
さらに、Data Guard 用の接続 Service、Transparent Application Continuity (TAC)、Active Data Guard の DML リダイレクト、Autonomous Recovery Service まで含めて、単なる構成確認で終わらない「実運用を見据えた高可用性構成」を確認してみてみます。
■ 概要
今回の構成
事前準備
Active Data Guard 設定
Switchover 実行
Failover 実行
Reinstate 実行
Standby 側の REDO 適用遅延(LAG)確認
Data Guard用 接続 Service 確認と作成
Transparent Application Continuity (TAC) 設定
Standby Database の DML 操作有効化
Oracle Database Autonomous Recovery Service の設定
技術解説
Switchover / Failover / Reinstate の違い
- Switchover: 計画停止やメンテナンス時に、データ損失なく Primary / Standby を切り替える
- Failover: Primary 障害時に Standby を昇格する
- Reinstate: Failover 後に旧 Primary を Standby として復帰させる
■ 今回の構成
今回は、アベイラビリティ・ゾーンをまたいだネットワーク構成で Data Guard を構成します。
Oracle MAAは、災害復旧設定における可用性ゾーン間のネットワーク接続に関するベストプラクティスを推奨しています。以下の点を確認してください。
- Oracle Exadataインフラストラクチャ（ExaDB-D）は、2つのアベイラビリティゾーン（AZ）にプロビジョニングされます。各Exadataインフラストラクチャは、プライマリ環境とスタンバイ環境を構成するために、少なくとも1つのExadata VMクラスタを別々の仮想ネットワーク（VNet）にデプロイします。
- プライマリクライアントとスタンバイクライアント、およびバックアップサブネットは、IP CIDR範囲が重複しない別々の仮想ネットワーク（VNet）であることを確認してください。
- Azure Kubernetes Servicesは少なくとも2つのAZにまたがり、VNetはプライマリおよびスタンバイVMクラスタの各VNetとピアリングされています。
- データベースのバックアップおよび復元操作は、高帯域幅ネットワークを介してOCIオブジェクトストレージに対して実行されます。
● 今回の前提条件
- Oracle Database@Azure 上の ExaDB-D を 2 系統作成済み
- Azure Japan East の Zone2 / Zone3 に配置済み
- Primary 側 Database は作成済み
- Standby 側は同一 Version の Database Home を作成済み、またはこれから作成する
- Primary / Standby 間でネットワーク疎通がある
- Active Data Guard を利用するため、対応ライセンス前提
● 事前確認チェックリスト
- Primary / Standby 間で ping 疎通できる
- Primary / Standby 間で TCP 1521 が疎通している
- Standby 側に Primary と同じ Version の Database Home がある
- DB_UNIQUE_NAME を決めている
- 管理者パスワードを確認済み
- TDE Wallet パスワードを確認済み
- 事前チェックの実行を有効にしている
■ 事前準備
次を参考に Azure Japan East(Tokyoリージョン) の Zone2 と Zone3 へ ExDB-D を構築し、Primary 側に Database を作成してきます。
・ Oracle Exadata Database@Azure を作成してみてみた
今回は、次のように Database を作成しました。これを使用して Zone3 へ Standby Database を作成します。
<PRIMARY_DB_UNIQUE_NAME> : CDB_TokyoZ2
<INSTANCE_NAME_NODE1> : CDB1
<INSTANCE_NAME_NODE2> : CDB2
<PDB_NAME> : pdb
■ OCI コンソールへ切り替え
OCIコンソールで データベースの作成管理同様、Data Guard 構成は、OCIコンソールを使用して設定管理します。
1) Azure コンソール VM Cluster 画面
OCIコンソールに移動するには、VM Cluster画面にある [Go to OCI]をクリックします。
2) OCI コンソール画面
ログインすると、Oracle Cloud コンソールでの VM Cluster画面になります。
■ Active Data Guard 設定
● Standby 側 DB_HOME 作成
・ DB バージョンと必要パッチが整合している必要があります。
今回は、既存のプライマリ DB と同じ Version の Database Home を作成します。
1) Primary の Database homes 画面
[データベース・ホームの作成] をクリック
2) Create database home 画面
既存のプライマリ DB と同じ Version の Database Home を作成します。
データベース・ホームの作成ダイアログで、次のように入力し、[作成]をクリック
・ データベース・ホームの表示名: データベース・ホームの表示名
・ データベース・イメージ: データベースに使用されるOracle Databaseバージョンを決定します。
・ データベース・イメージの変更をクリックして、目的のOracle公開イメージまたは事前に作成したカスタムデータベース・ソフトウェア・イメージを使用し、イメージ・タイプを選択します:
3) Create database home 完了
● ネットワーク疎通確認
Primary / Standby の両方向で、ネットワーク疎通を確認します。
・ ping疎通確認
[oracle@exa-z31-hkmas ~]$ ping 10.20.1.230 -c 3
PING 10.20.1.230 (10.20.1.230) 56(84) bytes of data.
64 bytes from 10.20.1.230: icmp_seq=1 ttl=64 time=1.26 ms
64 bytes from 10.20.1.230: icmp_seq=2 ttl=64 time=1.20 ms
64 bytes from 10.20.1.230: icmp_seq=3 ttl=64 time=1.22 ms
--- 10.20.1.230 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 1.202/1.227/1.258/0.046 ms
・ 1521 Port 疎通確認
両Server 間で TCP 1521 が通ることを確認
Standby を作成するサーバーから、oracleユーザーで Primary Database へ SQL 接続できることを確認
[oracle@exa-z31-hkmas ~]$ sql system/<SYSTEM_PASSWORD>//10.20.1.85:1521/CDB_TokyoZ2.ociclientsubne.ocivnettokyoz2.oraclevcn.com
SQLcl: Release 25.4 Production on Sat Mar 28 12:20:10 2026
Copyright (c) 1982, 2026, Oracle. All rights reserved.
Last Successful login time: Sat Mar 28 2026 12:20:11 +09:00
Connected to:
Oracle AI Database 26ai EE Extreme Perf Release 23.26.1.0.0 - Production
Version 23.26.1.0.0
SQL> select NAME, DB_UNIQUE_NAME from v$database;
NAME DB_UNIQUE_NAME
_______ _________________
CDB CDB_TokyoZ2
・ qperf レイテンシ測定
[oracle@exa-z31-hkmas ~]$ qperf -vvu 10.20.1.230 -t 10 tcp_lat udp_lat
tcp_lat:
latency = 507 us
msg_size = 1 bytes
time = 10 sec
timeout = 5 sec
udp_lat:
latency = 497 us
msg_size = 1 bytes
time = 10 sec
timeout = 5 sec
● Data Guard 設定
VMクラスタの詳細ページの「データベース」セクションで、プライマリにするデータベースの名前をクリックします。
「データベースの詳細」ページの「リソース」で、「Data Guard Group」をクリックします。
1) Data Guard グループ画面
[Add Standby]をクリック
2) Enable Data Guard 画面
以下項目を設定し、[Enable Data Guard]をクリック
・ ピア・リージョン: スタンバイ・データベースを検索するリージョンを選択します。 プライマリ・データベースが存在するリージョンがデフォルトで選択されます。 スタンバイ・データベースは、別のリージョンに配置することもできます。 このフィールドに関連付けられたヒントのテキストで、プライマリ・データベースが配置されているリージョンがわかります。
・ 可用性ドメイン: スタンバイ・データベースの可用性ドメインを選択します。 このフィールドに関連付けられたヒントのテキストで、プライマリ・データベースが配置されている可用性ドメインがわかります。
・ サービスの選択: Exadata Database Service on Dedicated InfrastructureまたはExadata Database Service on Exascale Infrastructure。
・ Exadataインフラストラクチャの選択: 「サービスの選択」ドロップダウン・リストから「Exadata Database Service on Dedicated Infrastructure」を選択した場合にのみ適用されます。
・ Data Guardピア・リソース・タイプ: VMクラスタを選択します。
・ VMクラスタ: ドロップダウン・リストからクラウドVMクラスタを選択します。
・ Data Guardエクスペリエンスの選択:
-[新しいData Guardグループ・リソースの使用]このオプションでは、新しいData Guard構成がData Guardグループ・リソースとして作成されます。 このオプションは、新しいAPIとともに、複数のスタンバイ・データベースの追加をサポートし、その他の機能拡張を提供します。 現在、既存のData Guard関連付けAPIを使用してData Guard操作を管理する自動化がある場合は、新しいAPIを使用してこれらの新機能を利用するようにアプリケーションを更新できます。
-[既存のData Guard関連付けリソースの使用] Data Guard操作の管理の自動化が既存のData Guard関連付けAPIに依存する場合は、このオプションを選択します。 ただし、複数のスタンバイ・データベースを追加することはできず、新しいAPIによって提供される機能強化も得られません。
・ Data Guardタイプ: 「Active Data Guard」または「Data Guard」を選択します。 Active Data Guardは、次のような追加機能を提供: リアルタイム問合せおよびDMLオフロード、自動ブロック修復、スタンバイ・ブロック変更トラッキング、遠隔同期、グローバル・データ・サービスおよびアプリケーション・コンティニュイティ。 Active Data GuardにはOracle Active Data Guardライセンスが必要です。 Active Data Guardの詳細は、Active Data Guardを参照してください。 両方のData Guardタイプの完全な概要は、「Oracle Data Guardの紹介」を参照してください
・ 保護モード: 保護モードは、最大パフォーマンスまたは最大可用性です。 これらのオプションの詳細は、「Oracle Data Guardの保護モード」を参照してください。
・ トランスポートタイプ: このData Guardグループに使用されるREDO転送タイプ。 これらのオプションの詳細は、「REDO転送サービス」を参照してください。
・ 保護モードおよび輸送タイプ: スタンバイ・データベース作成のルール
・ データベース・ホームの選択: 新しいデータベース・ホームにスタンバイ・データベースを追加するには、スタンバイ・データベースを追加する前にデータベース・ホームを作成する必要があります
・ データベースの一意の名前: オプションで、DB_UNIQUE_NAMEデータベース・パラメータの値を指定します。 この値は、プライマリおよびスタンバイのクラウドVMクラスタ全体で一意である必要があります。 一意の名前は次の要件を満たす必要があります:
最大30文字であること
英数字またはアンダースコア(_)文字のみを含みます
先頭はアルファベット
VMクラスタ全体で一意。 テナンシ全体で一意になるようにすることをお薦めします。
・ データベース・パスワード: プライマリ・データベースのデータベース管理者パスワードを入力します。 これと同じデータベース管理者パスワードをスタンバイ・データベースで使用します。
・ TDEウォレット・パスワード: TDEウォレット・パスワードを入力します。
・ Oracle SIDプレフィクス: Oracle Databaseインスタンス番号は、INSTANCE_NAMEデータベース・パラメータを作成するために、SIDプレフィクスに自動的に追加されます。 INSTANCE_NAMEパラメータはSIDとも呼ばれます。 指定しない場合、SID接頭辞はデフォルトでdb_unique_nameの最初の12文字に設定されます。
SIDプレフィクスは要件を満たしている必要があります:
最大12文字
英数字のみを含みます
先頭はアルファベット
VMクラスタ内、およびプライマリ・データベースとスタンバイ・データベース間で一意
今回の構成では、主に次の項目を設定しました。
- ピア・リージョン: Japan East
- 可用性ドメイン / ゾーン: Zone3 側を選択
- Data Guard タイプ: Active Data Guard
- Data Guard ピア・リソース・タイプ: VMクラスタ
- Standby 側 DB Home: Primary と同一 Version のものを選択
- 事前チェックの実行: 有効
スタンバイ・データベースを追加する前に、事前チェックを実行します。「事前チェックの実行」オプションを選択してください。
3) Data Guard 設定中
4) Data Guard 設定完了
State が Available になれば、Data Guard 構成は完了です。
● Data Guard 設定確認
ここからは、詳しくログ出力させながらコマンドで確認していきます。
・ DGMGRL 接続
1) 環境変数設定
いずれかの Database Node へ OS ログイン
[oracle@exa-z21-hkmas ~]$ . CDB.env
[oracle@exa-z21-hkmas ~]$ env | grep ORA
ORACLE_UNQNAME=CDB_TokyoZ2
ORACLE_SID=CDB1
ORACLE_BASE=/u02/app/oracle
ORACLE_HOME=/u02/app/oracle/product/23.0.0.0/dbhome_1
ORACLE_HOSTNAME=exa-z21-hkmas.ociclientsubne.ocivnettokyoz2.oraclevcn.com
2) DGMGRL 接続
Oracle Data Guard コマンドライン・インタフェース(DGMGRL)を使用して Data Guard 状態を確認します。
[oracle@exa-z21-hkmas ~]$ dgmgrl /
DGMGRL for Linux: Release 23.26.1.0.0 - Production on Fri Mar 27 09:17:12 2026
Version 23.26.1.0.0
Copyright (c) 1982, 2026, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected to "CDB_TokyoZ2"
Connected as SYSDG.
DGMGRL>
・ 現在の保護モード確認
DGMGRL> show configuration verbose
Configuration - cdb_dgconf
Protection Mode: MaxPerformance
Members:
CDB_TokyoZ2 - Primary database
CDB_TokyoZ3 - Physical standby database
Properties:
BystandersFollowRoleChange = 'ALL'
CommunicationTimeout = '180'
ConfigurationSimpleName = 'cdb_dgconf'
ConfigurationWideServiceName = 'CDB_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 49 seconds ago)
・ Data Guard の設定確認: Zone2 の DB (CDB_TokyoZ2)
PRIMARY であることを確認
DGMGRL> show database verbose CDB_TokyoZ2
Database - CDB_TokyoZ2
Role: PRIMARY
Intended State: TRANSPORT-ON
Redo Rate: 208 Byte/s in 15 seconds (computed 14 seconds ago)
Instance(s):
CDB1
CDB2
Properties:
AlternateLocation = ''
ApplyInstanceTimeout = '0'
ApplyInstances = '0'
ApplyLagThreshold = '30'
ApplyParallel = 'AUTO'
ArchiveLocation = ''
Binding = 'OPTIONAL'
DGConnectIdentifier = 'CDB_TokyoZ2'
DelayMins = '0'
FastStartFailoverTarget = 'CDB_TokyoZ3'
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(*)
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> validate database verbose CDB_TokyoZ2
DGM-17567: Current database session was authenticated using operating system credentials.
Database Role: Primary database
Ready for Switchover: Yes
Flashback Database Status:
Database Status Retention Target
CDB_TokyoZ2 On 1440
CDB_TokyoZ3 On 1440
Force Logging Status:
Database Status Nonlogged Blocks
CDB_TokyoZ2 On 0
Capacity Information:
Database Instances Threads
CDB_TokyoZ2 2 2
Managed by Clusterware:
CDB_TokyoZ2: YES
Temporary Tablespace File Information:
CDB_TokyoZ2 Temp Files: 3
Data file Online Move in Progress:
CDB_TokyoZ2: No
Transport-Related Information:
Transport On: Yes
Log Files Cleared:
CDB_TokyoZ2 Standby Redo Log Files: Cleared
・ Data Guard の設定確認: Zone3 の DB (CDB_TokyoZ3)
PHYSICAL STANDBY であることを確認
DGMGRL> show database verbose CDB_TokyoZ3
Database - CDB_TokyoZ3
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: 15.00 KByte/s
Active Apply Rate: 1.36 MByte/s
Maximum Apply Rate: 1.91 MByte/s
Real Time Query: ON
Instance(s):
CDB1 (apply instance)
CDB2
Properties:
AlternateLocation = ''
ApplyInstanceTimeout = '0'
ApplyInstances = '0'
ApplyLagThreshold = '30'
ApplyParallel = 'AUTO'
ArchiveLocation = ''
Binding = 'OPTIONAL'
DGConnectIdentifier = 'CDB_TokyoZ3'
DelayMins = '0'
FastStartFailoverTarget = 'CDB_TokyoZ2'
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(*)
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
■ Switchover 実行(Primary:Zone2 -> Zone3)
メンテナンス用途などで、計画的にプライマリ・データベースとスタンバイ・データベースを切り替えます。
スイッチオーバー中にデータが失われることはありません。
● Data Guard Group 側作業
1) Data Guard Associations画面
対象 DB の右にあるドットをクリックし、[Switchover]をクリック
2) Switchover Database画面
admin パスワードを入力し、[OK]をクリック
3) Switchover中
4) Switchover完了
● Switchover 確認
・ Zone2 の DB (CDB_TokyoZ2)確認
PHYSICAL STANDBYへ切り替わっていることを確認
DGMGRL> show database CDB_TokyoZ2
Database - CDB_TokyoZ2
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: 14.00 KByte/s
Real Time Query: ON
Instance(s):
CDB1
CDB2 (apply instance)
Database Status:
SUCCESS
・ Zone3 の DB (CDB_TokyoZ3)確認
PRIMARYへ切り替わっていることを確認
DGMGRL> show database CDB_TokyoZ3
Database - CDB_TokyoZ3
Role: PRIMARY
Intended State: TRANSPORT-ON
Redo Rate: 201 Byte/s in 15 seconds (computed 16 seconds ago)
Instance(s):
CDB1
CDB2
Database Status:
SUCCESS
■ Failover 実行(Primary: Zone3 -> Zone2)
プライマリ・データベースの障害時に、スタンバイ・データベースをプライマリ・ロールに変更します。
フラッシュバック・データベースが使用可能になっている場合は、障害の原因が修正された後、Reinstateコマンドにより元どおり新しいプライマリ・データベースのスタンバイに戻すことができます。
● Standby DB (Zone3) 側作業
1) Data Guard Associations画面
対象 DB の右にあるドットをクリックし、[Failover 実行]をクリック
2) Failover Database画面
admin パスワードを入力し、[OK]をクリック
3) Failover中
4) Failover完了
● Failover 確認
・ Zone2 の DB (CDB_TokyoZ2)確認
PRIMARYへ切り替わっていることを確認
DGMGRL> show database CDB_TokyoZ2
Database - CDB_TokyoZ2
Role: PRIMARY
Intended State: TRANSPORT-ON
Redo Rate: (unknown)
Instance(s):
CDB1
CDB2
Database Status:
SUCCESS
・ Zone3 の DB (CDB_TokyoZ3)確認
PHYSICAL STANDBYへ切り替わり、Statusは DISABLED - ORA-16661であることを確認
DGMGRL> show database CDB_TokyoZ3
Database - CDB_TokyoZ3
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: (unknown)
Apply Lag: (unknown)
Average Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
CDB1
CDB2
Database Status:
DISABLED - ORA-16661: The standby database must be reinstated.
■ Reinstate 実行(障害が発生したプライマリ・データベース Zone3: CDB_TokyoZ3 の回復)
フェイルオーバーした障害プライマリ・データベースをスタンバイ・データベースとして復旧します
● Primary DB 側作業
1) Data Guard Associations 画面
対象 DB の右にあるドットをクリックし、[Reinstate実行]をクリック
2) Reinstate Database 画面
admin パスワードを入力し、[OK]をクリック
3) Reinstate 中
4) Reinstate 完了
● Reinstate 確認
・ Zone2 の DB (CDB_TokyoZ2)確認
Statusは変わらず、PRIMARYロールであることを確認
DGMGRL> show database CDB_TokyoZ2
Database - CDB_TokyoZ2
Role: PRIMARY
Intended State: TRANSPORT-ON
Redo Rate: 450 Byte/s in 38 seconds (computed 0 seconds ago)
Instance(s):
CDB1
CDB2
Database Status:
SUCCESS
・ Zone3 の DB (CDB_TokyoZ3)確認
Statusは DISABLED - ORA-16661から、SUCCESSへ変わっていることを確認
DGMGRL> show database CDB_TokyoZ3
Database - CDB_TokyoZ3
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: 60.00 KByte/s
Real Time Query: ON
Instance(s):
CDB1
CDB2 (apply instance)
Database Status:
SUCCESS
■ Standby 側の REDO 適用遅延(LAG)確認
V$DATAGUARD_STATSは、スタンバイ・データベース上での問合せに対して、Oracle Data Guardメトリックに関する情報を示します。
[oracle@exa-z3-tokyo1-hkmas ~]$ sql / as sysdba
SQLcl: Release 25.4 Production on Fri Mar 27 19:34:59 2026
Copyright (c) 1982, 2026, Oracle. All rights reserved.
Connected to:
Oracle AI Database 26ai EE Extreme Perf Release 23.26.1.0.0 - Production
Version 23.26.1.0.0
SQL> select name,value,time_computed,unit from gv$dataguard_stats;
NAME VALUE TIME_COMPUTED UNIT
_________________________ ___________________ ______________________ _______________________________
transport lag +00 00:00:00 03/27/2026 19:35:07 day(2) to second(0) interval
apply lag +00 00:00:01 03/27/2026 19:35:07 day(2) to second(0) interval
apply finish time +00 00:00:00.002 03/27/2026 19:35:07 day(2) to second(3) interval
estimated startup time 16 03/27/2026 19:35:07 second
transport lag +00 00:00:00 03/27/2026 19:35:07 day(2) to second(0) interval
apply lag 03/27/2026 19:35:07 day(2) to second(0) interval
apply finish time 03/27/2026 19:35:07 day(2) to second(3) interval
estimated startup time 12 03/27/2026 19:35:07 second
8 rows selected.
■ Data Guard用 接続 Service 確認と作成
Oracle Data Guard Broker によって管理されるロール移行により、人が介入することなく、スタンバイ・データベースのプライマリ・ロールへの自動移行、プライマリ・ロールに適したデータベース・サービスの開始、障害が発生したプライマリ・データベースとの接続の解除（TCP タイムアウトからの切り離し）のクライアントへの通知、および新しいプライマリ・データベースへのクライアントの接続を実行できます。
ここでは、自動で作成されたService と 手動で作成する Service の方法を説明します。
● 自動で作成されたService確認
Data Guardアソシエーションで Active Data Guard構成すると プライマリ・ロール と スタンバイ・ロールのService が作成されます。
・ Service 一覧
自動作成された Service を確認
[oracle@exa-z21-hkmas ~]$ srvctl status service -db CDB_TokyoZ2
Service CDB_PDB.paas.oracle.com is running on instances CDB1,CDB2
Service CDB_PDB_ro.paas.oracle.com is not running.
・ PRIMARY Role の Service 確認
Service role = PRIMARY が設定された Service が プライマリ・ロールのサービスです。
これを使用して、Switchover, Failover されてもこのサービス名を使用すればプライマリ・データベースへ接続できます。
[oracle@exa-z21-hkmas ~]$ srvctl config service -db CDB_TokyoZ2 -service CDB_PDB.paas.oracle.com | grep role
Service role: PRIMARY
[oracle@exa-z21-hkmas ~]$ srvctl config service -db CDB_TokyoZ2 -service CDB_PDB.paas.oracle.com
Service name: CDB_PDB.paas.oracle.com
Cardinality: 2
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: FALSE
AQ HA notifications: FALSE
Global: FALSE
Commit Outcome: FALSE
Commit Outcome Fastpath: FALSE
Reset State: NONE
Failover type: NONE
Failover method: NONE
Failover retries:
Failover delay:
Failover restore: NONE
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Pluggable database name: PDB
True Cache service:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Failback : no
Replay Initiation Time: 300 seconds
Drain timeout:
Template timeout: 86400 seconds
Stop option:
Session State Consistency:
Auto Connection Rebalance: DEFAULT
GSM Flags: 0
Service is enabled
Preferred instances: CDB1,CDB2
Available instances:
CSS critical: no
・ PHYSICAL_STANDBY Role の Service 確認
Service role = PHYSICAL_STANDBY が設定された Service が Active Standby Role のサービスです。
これを使用して、Switchover, Failover されてもこのサービス名を使用すれば、読み込み可能なスタンバイ・データベースへ接続できます。ダウンしているデータベースへは接続しません。
[oracle@exa-z21-hkmas ~]$ srvctl config service -db CDB_TokyoZ2 -service CDB_PDB_ro.paas.oracle.com | grep role
Service role: PHYSICAL_STANDBY
[oracle@exa-z21-hkmas ~]$ srvctl config service -db CDB_TokyoZ2 -service CDB_PDB_ro.paas.oracle.com
Service name: CDB_PDB_ro.paas.oracle.com
Cardinality: 2
Service role: PHYSICAL_STANDBY
Management policy: AUTOMATIC
DTP transaction: FALSE
AQ HA notifications: FALSE
Global: FALSE
Commit Outcome: FALSE
Commit Outcome Fastpath: FALSE
Reset State: NONE
Failover type: NONE
Failover method:
Failover retries:
Failover delay:
Failover restore: NONE
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Pluggable database name: PDB
True Cache service:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Failback : no
Replay Initiation Time: 300 seconds
Drain timeout:
Template timeout: 86400 seconds
Stop option:
Session State Consistency:
Auto Connection Rebalance: DEFAULT
GSM Flags: 0
Service is enabled
Preferred instances: CDB1,CDB2
Available instances:
CSS critical: no
● 新規で Service 作成する場合
今回、例として次の Service を作成します。
-
app_rw: Primary ロールのデータベースへ接続するためのサービス -
app_ro: PHYSICAL_STANDBY ロールのデータベースへ接続するためのサービス
1) Primary 側 DB に app_rw を作成
Primary 側 DB に Read/Write可能な Primary Databaseへ接続する app_rw サービスを作成
ここでは、クライアントが接続する preferredで優先するインスタンスを設定しています。
srvctl add service \
-db <PRIMARY_DB_UNIQUE_NAME> \
-service app_rw \
-pdb <PDB_NAME> \
-preferred "<PRIMARY_PREF_INST>" \
-available "<PRIMARY_AVAIL_INST>" \
-notification TRUE \
-clbgoal LONG \
-rlbgoal NONE \
-drain_timeout 300 \
-stopoption IMMEDIATE \
-role PRIMARY
2) Primary 側 DB に app_ro を作成
Primary 側 DB に、Read 可能な Active Standby Database へ接続する app_ro サービスを作成します。
ここでは、クライアントが接続する preferred で優先するインスタンスを設定しています。
srvctl add service \
-db <PRIMARY_DB_UNIQUE_NAME> \
-service app_ro \
-pdb <PDB_NAME> \
-preferred "<PRIMARY_PREF_INST>" \
-available "<PRIMARY_AVAIL_INST>" \
-notification TRUE \
-clbgoal LONG \
-rlbgoal NONE \
-drain_timeout 300 \
-stopoption IMMEDIATE \
-role PHYSICAL_STANDBY
3) Standby 側 DB に app_rw を作成
ここでは、クライアントが接続する preferredで優先するインスタンスを設定しています。
srvctl add service \
-db <STANDBY_DB_UNIQUE_NAME> \
-service app_rw \
-pdb <PDB_NAME> \
-preferred "<STANDBY_PREF_INST>" \
-available "<STANDBY_AVAIL_INST>" \
-notification TRUE \
-clbgoal LONG \
-rlbgoal NONE \
-drain_timeout 300 \
-stopoption IMMEDIATE \
-role PRIMARY
4) Standby 側 DB に app_ro を作成
ここでは、クライアントが接続する preferredで優先するインスタンスを設定しています。
srvctl add service \
-db <STANDBY_DB_UNIQUE_NAME> \
-service app_ro \
-pdb <PDB_NAME> \
-preferred "<STANDBY_PREF_INST>" \
-available "<STANDBY_AVAIL_INST>" \
-notification TRUE \
-clbgoal LONG \
-rlbgoal NONE \
-drain_timeout 300 \
-stopoption IMMEDIATE \
-role PHYSICAL_STANDBY
-role PRIMARY のサービスは Primary のときだけ、-role PHYSICAL_STANDBY のサービスは Physical Standby のときだけ起動します。-preferred / -available と -pdb を含む構文は現行 SRVCTL リファレンスに載っています。
5)もし 2 ノード両方で均等に受けたいなら
両ノード運用にしたいなら、-preferred を 2 インスタンスとも指定できます。
-preferred はカンマ区切りのリストです。
srvctl add service \
-db <PRIMARY_DB_UNIQUE_NAME> \
-service app_rw \
-pdb <PDB_NAME> \
-preferred "<PRIMARY_INST1>,<PRIMARY_INST2>" \
-notification TRUE \
-clbgoal LONG \
-rlbgoal NONE \
-drain_timeout 300 \
-stopoption IMMEDIATE \
-role PRIMARY
■ Transparent Application Continuity (TAC) 設定
Oracle Application Continuityを活用することで、計画メンテナンス時や予期しない障害時にも継続的な可用性を維持できるようアプリケーションの耐障害性を向上させます。
Data Guard 構成を組んだ場合、role-based service と組み合わせて Application Continuity / Transparent Application Continuity を設定できます。
今回は、Primary ロール用に作成した app_rw サービスへ Transparent Application Continuity (TAC) を設定します。
Transparent Application Continuity を有効化すると、計画停止や一時的な障害発生時に、アプリケーションから見るとエラーではなく「少し遅延しただけ」に近い形で処理を継続しやすくなります。
● 今回の設定
-
app_rw: Primary ロールのデータベースへ接続するサービス -
app_ro: PHYSICAL_STANDBY ロールのデータベースへ接続するサービス,ADG_REDIRECT_DML利用可能 - TAC は
app_rwに設定
● app_rw へ TAC を設定
PDB に接続し、DBMS_APP_CONT_ADMIN パッケージを使用してサービスへ設定します。
このパッケージは、アプリケーション継続性に関連する、DBAレベルの管理操作をまとめたものです。
・ ENABLE_TAC
この手順により、特定のサービスにおいて透過的なアプリケーション継続性（TAC）が有効になります。
DBMS_APP_CONT_ADMIN.ENABLE_TAC (
service_name IN VARCHAR2,
failover_restore IN VARCHAR2 DEFAULT 'AUTO'
replay_initiation_timeout IN BINARY_INTEGER DEFAULT 300
session_state_consistency IN VARCHAR2 DEFAULT 'AUTO');
・ ENABLE_RESET_STATE
この手順により、リクエスト間でセッション状態の使用状況をクリアできるため、新しいリクエストは毎回クリーンな状態で開始されます
DBMS_APP_CONT_ADMIN.ENABLE_RESET_STATE (
service_name IN VARCHAR2,
level IN VARCHAR2 DEFAULT AUTO); -- LEVEL: Oracle AI Database のリセットセッション状態構成のレベル。使用可能なオプションはNONEと ですLEVEL1。
・ SET_DRAINING
この手順では、タイムアウト値や停止オプションなど、サービスのドレインオプションを設定します。
DBMS_APP_CONT_ADMIN.SET_DRAINING (
service_name IN VARCHAR2,
drain_timeout IN BINARY_INTEGER DEFAULT 300 -- リソースのドレイン処理が完了するまでの許容時間を秒単位で指定
stop_option IN VARCHAR2 DEFAULT 'NONE');
今回の環境では、Physical Standby は READ ONLY でオープンしているため、DBMS_APP_CONT_ADMIN によるサービス属性変更を実行できません。
そのため、app_rw への TAC 設定は Primary ロール時に実施します。
実際に Standby 側で実行すると、次のように ORA-44317: database open read-only が発生します。
SQL> EXEC DBMS_APP_CONT_ADMIN.ENABLE_TAC('app_rw');
BEGIN DBMS_APP_CONT_ADMIN.ENABLE_TAC('app_rw'); END;
*
ERROR at line 1:
ORA-44317: database open read-only
ORA-06512: at "SYS.DBMS_SERVICE_ERR", line 54
ORA-06512: at "SYS.DBMS_SERVICE", line 455
ORA-06512: at "SYS.DBMS_APP_CONT_ADMIN", line 296
ORA-06512: at "SYS.DBMS_APP_CONT_ADMIN", line 400
ORA-06512: at line 1
1） サービス起動確認
app_rwサービスが起動していることを確認。
起動していない場合は起動しておきます。
srvctl start service -db <DB_UNIQUE_NAME> -service app_rw
srvctl status service -db <DB_UNIQUE_NAME> -service app_rw
[oracle@exa-z22-hsjyp ~]$ srvctl status service -db CDB_TokyoZ2 -service app_rw
Service app_rw is running on instances CDB1
[oracle@exa-z22-hkmas ~]$ srvctl status service -db CDB_TokyoZ3 -service app_rw
Service app_rw is running on instances CDB1
※ Zone3 側の app_rw 起動確認は、Switchover により Zone3 が Primary ロールへ切り替わった後の状態です。
2) Zone2 側でTAC設定
sql / as sysdba
ALTER SESSION SET CONTAINER=pdb;
EXEC DBMS_APP_CONT_ADMIN.ENABLE_TAC('app_rw');
EXEC DBMS_APP_CONT_ADMIN.ENABLE_RESET_STATE('app_rw', 'LEVEL1');
EXEC DBMS_APP_CONT_ADMIN.SET_DRAINING('app_rw', 300, 'IMMEDIATE');
3) Zone3 側でも同様にTAC設定
Switchover により CDB_TokyoZ3 が Primary になった後、同様に実施します。
sql / as sysdba
ALTER SESSION SET CONTAINER=pdb;
EXEC DBMS_APP_CONT_ADMIN.ENABLE_TAC('app_rw');
EXEC DBMS_APP_CONT_ADMIN.ENABLE_RESET_STATE('app_rw', 'LEVEL1');
EXEC DBMS_APP_CONT_ADMIN.SET_DRAINING('app_rw', 300, 'IMMEDIATE');
● 設定確認
設定後は、まずサービス定義を確認します。
1） サービス設定確認
サービスにTACが設定されていることを確認します。
srvctl config service -db <DB_UNIQUE_NAME> -service app_rw
[oracle@exa-z21-hsjyp ~]$ srvctl config service -db CDB_TokyoZ2 -service app_rw
Service name: app_rw
Cardinality: 1
Service role: PRIMARY
Management policy: AUTOMATIC
DTP transaction: FALSE
AQ HA notifications: TRUE
Global: FALSE
Commit Outcome: TRUE
Commit Outcome Fastpath: TRUE
Reset State: LEVEL1
Failover type: AUTO
Failover method: NONE
Failover retries: 30
Failover delay: 5
Failover restore: AUTO
Connection Load Balancing Goal: LONG
Runtime Load Balancing Goal: NONE
TAF policy specification: NONE
Edition:
Pluggable database name: pdb
True Cache service:
Maximum lag time: ANY
SQL Translation Profile:
Retention: 86400 seconds
Failback : no
Replay Initiation Time: 600 seconds
Drain timeout: 300 seconds
Template timeout: 86400 seconds
Stop option: immediate
Session State Consistency: AUTO
Auto Connection Rebalance: DEFAULT
GSM Flags: 0
Service is enabled
Preferred instances: CDB1
Available instances: CDB2
CSS critical: no
● クライアント側設定
Transparent Application Continuity を有効化しても、クライアント側が対応していないと効果を十分に得られません。
26ai では、AC/TAC が有効化されたサービスへ接続することが前提となります。
代表的には、次のような Oracle クライアント / 接続プールが対象です。
・ Oracle JDBC Replay Driver
・ Oracle UCP
・ ODP.NET
・ OCI Session Pool
・ WebLogic Active GridLink
また、planned / unplanned outage を素早く検知するため、FAN を利用できる構成が推奨されます。
接続文字列には、少なくとも次のようなタイムアウト / 再試行設定を入れておくと実運用しやすくなります。
・参考: 動的データベースサービスによるワークロード管理
APP_RW =
(DESCRIPTION=
(CONNECT_TIMEOUT=90)
(RETRY_COUNT=30)
(RETRY_DELAY=3)
(TRANSPORT_CONNECT_TIMEOUT=3)
(ADDRESS_LIST=
(LOAD_BALANCE=ON)
(ADDRESS=(PROTOCOL=TCP)(HOST=<SCAN1>)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=<SCAN2>)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=<SCAN3>)(PORT=1521))
)
(CONNECT_DATA=
(SERVICE_NAME=app_rw)
)
)
● 動作確認のポイント
Transparent Application Continuity 設定後は、app_rw を使用して接続しているアプリケーションから次を確認します。
- 計画停止前に service draining が有効に働くことを確認
- Switchover 実行時にセッション断ではなく、短時間の遅延後に処理継続できることを確認
- role-based service のため、切替後も app_rw で新しい Primary へ接続できることを確認
Active Data Guard の DML リダイレクトは便利な機能ですが、Application Continuity / Transparent Application Continuity と同時利用する前提ではありません。
更新系アプリケーションでは app_rw + TAC、参照系では app_ro、DML リダイレクトは用途を限定して使い分けるのが分かりやすい構成です。
■ Standby Database の DML 操作有効化
ACTIVE DATA GUARD DMLリダイレクトを有効化します。
これは Active Data Guard 限定の機能です。スタンバイ・データベースに対する DML 操作をプライマリ・データベースにリダイレクトできるようにし、ときおり書込みが発生するレポート・アプリケーションを Active Data Guard スタンバイ・データベースでアクティブに実行できるようにする機能です。
各 Database ごとに、セッション単位または永続設定で個別に有効化できます。
● セッション単位
現在のセッションの DML 操作の自動リダイレクトを構成するには、次のコマンドを使用します。
SQL> ALTER SESSION ENABLE ADG_REDIRECT_DML;
● 永続単位
Active Data Guard 環境で、すべてのスタンバイ・セッションの DML 操作の自動リダイレクトを構成するには、ADG_REDIRECT_DML 初期化パラメータを TRUE に設定します。
SQL> ALTER SYSTEM SET ADG_REDIRECT_DML=true SCOPE=BOTH;
■ Oracle Database Autonomous Recovery Service の設定
Oracle Database Autonomous Recovery Service は、Oracle Databaseをデータ損失やサイバー脅威から保護するために設計された、完全マネージド型のサービスです。データベースのオーバーヘッドを削減しながら高速なバックアップを実現し、検証済みのバックアップによる信頼性の高いリカバリ、そして障害やランサムウェア攻撃発生後1秒以内に復旧できるリアルタイム保護機能を提供します。このサービスは、集中管理型のデータ保護ダッシュボードを備えており、高い耐障害性を備えた Oracle Databaseのバックアップに推奨されます。
これは、Standby Database へも設定できます。
作成手順は次が参考になります。
■ まとめ
今回は、Oracle Database@Azure 上の ExaDB-D を使って、Active Data Guard の構成だけでなく、Switchover / Failover / Reinstate、Data Guard 用接続 Service、Transparent Application Continuity (TAC)、DML リダイレクトまで一通り確認できました。
単に Standby Database を作るだけでなく、切替時にどう接続し、どう継続し、どう復旧させるかまで見えてくると、Data Guard は一気に“使える高可用性構成”として面白くなります。
次は、Maximum Availability や Fast-Start Failover (FSFO)、さらにクライアント側の FAN / UCP / Replay Driver を含めた Application Continuity の動作確認まで進めてみようと思います。
■ 参考
-
Oracle AI Database@Azure概要
・ Oracle AI Database@Azure -
Oracle Cloud Documents
・ Oracle AI Database@Azure
・ Exadata Cloud Service
・ Network Setup for Exadata Cloud Service Instances
・ Exadata Cloud InfrastructureシステムでのOracle Databaseホームの作成 -
Oracle Documents
・ Introduction to Oracle Data Guard
・ Oracle Data Guard コマンドライン・インタフェース・リファレンス
・ Oracle Maximum Availability Architecture for Multicloud
・ Oracle Maximum Availability Architecture for Oracle Database@Azure
・ DMLリダイレクションの有効化
・ Managing Physical and Snapshot Standby Databases
・ 自動ブロック・メディア・リカバリによるデータ保護の詳細
・ Data Guardの遠隔同期の詳細
・ アプリケーション・コンティニュイティの詳細
・ DBMS_ROLLINGの活用方法の詳細 -
Architecture Center
・ Learn About Oracle Database@Azure
・ Oracle Database@Azure の Oracle 最大可用性アーキテクチャについて学ぶ
・ Oracle Database@Azure上のOracle Exadata Database Serviceのリージョン間災害復旧を実装する
・ Secure Shell to Oracle Exadata Database Service from a Microsoft Azure Linux VM in Oracle Database@Azure -
Oracle Blog
・ DMLリダイレクトが投資利益率とデータベースの効率を向上させる理由
・ Oracle Data Guard のリド トランスポートスループットが 2 倍から 9 倍に向上 -
Oracle Youtube
・ Oracle Data Guard構成でのファスト・スタート・フェイルオーバーの重要性
・ 概要: Oracle Active Data Guardの遠隔同期
・ デモ：Oracle Active Data Guardによる透過的アプリケーション・コンティニュイティ -
Microsoft Documents
・ Oracle on Azure のドキュメント
・ 概要 - Oracle Database@Azure
・ Oracle Exadata Database@Azureのビジネス継続性とディザスター リカバリーに関する考慮事項
■ 技術解説
止まらないHigh availabilityの仕組みをIT初心者でも理解できるよう解説しています