【完全ガイド】Oracle Data Guard 完全ガイド｜Physical Standby・Protection Mode・DGMGRL・FSFO 徹底解説

Oracle DBA として災害対策（DR）と高可用性（HA）を実現する最重要ソリューション、それが Data Guard です:

$ dgmgrl sys/password@prod_pri

DGMGRL for Linux: Release 19.0.0.0.0

DGMGRL> SHOW CONFIGURATION;

Configuration - PROD_DG
  Protection Mode: MaxAvailability
  Members:
    prod_pri - Primary database
    prod_sby - Physical standby database
  Fast-Start Failover: ENABLED

Configuration Status:
SUCCESS   (status updated 5 seconds ago)

Oracle 公式標準の DR/HA ツールとして、以下の圧倒的優位性:

• 完全同期複製（Zero Data Loss 可能）
• 自動フェイルオーバー（FSFO、通常 30 秒以内）
• リードオンリー活用（Active Data Guard）
• 本番負荷ゼロのバックアップ（Standby でバックアップ）
• ローリングアップグレード（無停止で Oracle バージョンアップ）
• 地理的冗長化（別 DC / 別リージョン）
• RTO/RPO ゼロ目標達成可能
• Multi-Standby（複数 Standby 対応）
• Far Sync（長距離同期の中継）
• SQL Apply（Logical Standby で構造変更可能）

このソリューションの本質は、Oracle 公式 Data Guard Concepts and Administration が定義:

「Data Guard は Primary データベースの Redo を Standby データベースへ
  転送・適用することで、Primary の完全なコピーを常時維持する。
  災害時には Standby を Primary に昇格して業務継続。
  平常時は Standby を Read-Only 用途で活用可能」

DR (災害対策) vs HA (高可用性) の位置づけ

Oracle 冗長化ソリューションの階層:

【単一 DC】
  RAC (Real Application Clusters)
    → 複数ノードでの負荷分散 + ノード障害対応
    → 単一 DC 内、DC 障害には無効
    
【DC 間・地理的冗長化】
  Data Guard ← 本記事
    → 別 DC / 別リージョンへの複製
    → DC 全損に対応（DR）
    → Standby 活用（HA）
    
【組み合わせ】
  RAC + Data Guard
    → 究極の可用性

3 種類の Standby Database

Physical Standby（最も一般的）:

- Primary と完全同一（バイトレベル）
- Redo Apply で複製
- 実行計画も同じ
- Read-Only 可能（Active Data Guard）
- RMAN オフロード可能
- Rolling Upgrade 対応

Logical Standby:

- SQL Apply で複製（SQL レベル）
- テーブル構造変更可能
- 追加インデックス可能
- レポート最適化可能
- 一部データ型制限あり

Snapshot Standby:

- Physical を一時的に Read/Write 化
- テスト用途に最適
- 元に戻せる
- Redo は蓄積、後で追いつく

Protection Mode 3 種類の完全比較

Oracle Data Guard の心臓部、業務要件により選択:

Maximum Protection (最高保護):
  - 完全同期（Zero Data Loss 保証）
  - Standby 到達不可なら Primary も停止
  - 銀行等の金融機関向け
  - LogXptMode: SYNC AFFIRM

Maximum Availability (最高可用性、推奨):
  - 通常は Zero Data Loss（同期）
  - Standby 障害時は非同期に自動切替
  - Primary は継続
  - 一般エンタープライズ推奨
  - LogXptMode: SYNC AFFIRM
  
Maximum Performance (最高性能、デフォルト):
  - 非同期複製（Best Effort）
  - Primary パフォーマンス最優先
  - 少量のデータ損失可能性
  - 長距離レプリケーション向け
  - LogXptMode: ASYNC NOAFFIRM

現場で使う Data Guard の主要機能:

• Physical Standby 構築（RMAN DUPLICATE FOR STANDBY）
• Redo Transport（SYNC/ASYNC、LGWR/ARCH、AFFIRM/NOAFFIRM）
• Redo Apply（Real-Time Apply 推奨）
• Data Guard Broker（設定管理の統合）
• DGMGRL（コマンドラインインターフェース）
• Switchover（計画的な役割交換）
• Failover（緊急の役割交換）
• Fast-Start Failover (FSFO)（自動フェイルオーバー）
• Observer（FSFO の監視プロセス）
• Active Data Guard（Real-Time Query）
• Snapshot Standby（一時 Read/Write）
• Rolling Upgrade（無停止アップグレード）
• Far Sync（同期の中継、長距離用）
• 監視（V$DATABASE / V$DATAGUARD_STATS）

多くの日本語記事が「Data Guard を構築する」で終わりますが、実務では:

• Protection Mode の厳密な選択
• SYNC vs ASYNC の業務要件マッピング
• Real-Time Apply の必須設定
• Broker vs 手動管理の選択
• DGMGRL の完全コマンド体系
• Fast-Start Failover のObserver 配置戦略
• Active Data Guard のライセンス考慮
• Far Sync による長距離 Zero Data Loss
• Cascaded Standby（Standby から Standby へ）
• Autonomous Data Guard（OCI マネージド）
• Rails / Java / Python アプリの接続文字列（Primary / ADG 分離）

さらに、現代の Data Guard 実務での必須設定:

LOG_ARCHIVE_DEST_2='SERVICE=prod_sby 
  SYNC AFFIRM
  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
  DB_UNIQUE_NAME=prod_sby'

STANDBY_FILE_MANAGEMENT=AUTO
DB_FILE_NAME_CONVERT='prod_pri','prod_sby'
LOG_FILE_NAME_CONVERT='prod_pri','prod_sby'
FAL_SERVER='prod_pri'

本記事では、Oracle Data Guard の全てを実務レベルで完全網羅。基本概念、Protection Mode、Redo Transport/Apply、Broker、DGMGRL、Switchover/Failover、FSFO、Active Data Guard、Far Sync、Autonomous Data Guard、Rails/Java/Python 監視統合、実践シナリオ、トラブルシューティング、FAQまで。この1本で Oracle Data Guard をプロフェッショナルに扱えるようになります。

結論：Broker + FSFO + MaxAvailability

時間がない方向けに、最速の実務パターンを先に示します。

推奨構成（大多数のエンタープライズ）

【推奨】
Protection Mode: Maximum Availability
Redo Transport:  SYNC AFFIRM
Redo Apply:      Real-Time Apply
Broker:          Enabled
FSFO:            Enabled（Observer 配置）
Active DG:       Enabled（ライセンスあれば）

最速の Broker 設定（DGMGRL）

# 接続
$ dgmgrl sys/pw@prod_pri

DGMGRL> CREATE CONFIGURATION 'PROD_DG' AS
        PRIMARY DATABASE IS 'prod_pri'
        CONNECT IDENTIFIER IS prod_pri;

DGMGRL> ADD DATABASE 'prod_sby' AS
        CONNECT IDENTIFIER IS prod_sby
        MAINTAINED AS PHYSICAL;

DGMGRL> ENABLE CONFIGURATION;

DGMGRL> EDIT DATABASE 'prod_pri' SET PROPERTY LogXptMode='SYNC';
DGMGRL> EDIT DATABASE 'prod_sby' SET PROPERTY LogXptMode='SYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

# FSFO 設定
DGMGRL> EDIT DATABASE 'prod_pri' SET PROPERTY FastStartFailoverTarget='prod_sby';
DGMGRL> EDIT DATABASE 'prod_sby' SET PROPERTY FastStartFailoverTarget='prod_pri';
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold='30';
DGMGRL> ENABLE FAST_START FAILOVER;

# Observer 起動（別ホストで）
$ dgmgrl -logfile /tmp/observer.log sys/pw@prod_pri "START OBSERVER"

# 検証
DGMGRL> SHOW CONFIGURATION VERBOSE;
DGMGRL> VALIDATE DATABASE 'prod_sby';

6つの必須知識

詳細は以下で解説します。

Data Guard のアーキテクチャ

全体像

┌──────────────────────────────────────────────┐
│  Primary Database (prod_pri)                 │
│  ┌─────────────┐                             │
│  │ Users/Apps  │                             │
│  └──────┬──────┘                             │
│         ↓                                    │
│  ┌─────────────┐   Online   ┌─────────────┐  │
│  │ LGWR/ARCH   │─── Redo ──→│ Standby     │  │
│  │             │            │ Redo Log    │  │
│  └─────────────┘            └─────┬───────┘  │
│                                   ↓          │
│  ┌─────────────┐            ┌─────────────┐  │
│  │ Redo Log    │            │ MRP0        │  │
│  └─────────────┘            │ (Recover)   │  │
│                             └─────┬───────┘  │
│                                   ↓          │
│                             ┌─────────────┐  │
│                             │ Datafiles   │  │
│                             └─────────────┘  │
└──────────────────────────────────────────────┘
        Primary                Standby

Redo Transport の詳細

LGWR SYNC AFFIRM（Maximum Protection/Availability）:

Primary:
1. トランザクション実行
2. LGWR が Redo バッファに書き込み
3. LGWR が Standby にネットワーク送信（同期）
4. Standby: LNS/RFS が受信、Standby Redo Log に書き込み（AFFIRM）
5. Primary: Standby の書き込み完了確認後 COMMIT
6. アプリケーションに COMMIT 通知

→ Zero Data Loss 保証
→ Primary のパフォーマンスは若干低下（往復レイテンシ）

LGWR ASYNC NOAFFIRM（Maximum Performance）:

Primary:
1. トランザクション実行
2. LGWR が Redo バッファに書き込み
3. Primary で即 COMMIT（非同期）
4. LNS が別スレッドで Standby に送信

→ Primary のパフォーマンスに影響なし
→ Standby 到達前の障害でデータ損失可能

Redo Apply の 2 モード

Real-Time Apply（推奨）:

-- Standby で
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
  USING CURRENT LOGFILE DISCONNECT;

-- Redo 到着次第即座に適用
-- Apply Lag 最小
-- Active Data Guard 必須

Archived Redo Apply（旧型）:

-- ログスイッチ後に適用
-- Apply Lag 発生
-- 現代では非推奨

Standby Database の種類

Physical Standby（最も一般的）

特徴:
- Primary とバイトレベルで同一
- Redo Apply で複製
- Active Data Guard で Read-Only 可能
- RMAN バックアップオフロード可能
- Rolling Upgrade 対応（Physical→Logical→Physical 経由）

用途:
- DR (Disaster Recovery)
- レポート DB (Active DG)
- テスト DB (Snapshot Standby)

Logical Standby

特徴:
- SQL Apply で複製
- テーブル構造変更可能
- 追加インデックス可能
- Read/Write 可能（追加テーブル）
- 一部データ型制限（LOB 大サイズ等）

用途:
- レポート DB（構造最適化）
- ETL ソース
- Rolling Upgrade

Snapshot Standby

特徴:
- Physical を一時的に Read/Write 化
- Redo は蓄積（適用停止）
- 元に戻せる（元の状態＋蓄積 Redo 適用）
- テスト用途に最適

変換:
Physical → Snapshot: CONVERT TO SNAPSHOT STANDBY
Snapshot → Physical: CONVERT TO PHYSICAL STANDBY

Protection Mode 完全解説

Maximum Protection

設定:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

-- Broker
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION;

動作:

• 全 Standby が同期到達確認しないと COMMIT できない
• Standby 全喪失で Primary もシャットダウン
• Zero Data Loss 完全保証

使い所: 金融機関、決済システム、絶対にデータ損失できない業務。

必須:

• LogXptMode=’SYNC’ AFFIRM
• 複数 Standby 推奨（1 台喪失で Primary 停止するため）

Maximum Availability（推奨）

設定:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

動作:

• 通常は同期（Zero Data Loss）
• Standby 到達不可時は非同期に自動切替
• Primary は継続稼働
• Standby 復旧後、自動で同期に戻る

使い所: 一般的なエンタープライズ、推奨デフォルト。

必須:

• LogXptMode=’SYNC’ AFFIRM

Maximum Performance（デフォルト）

設定:

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPERFORMANCE;

動作:

• 非同期複製
• Primary パフォーマンス最優先
• 少量データ損失の可能性

使い所: 長距離レプリケーション、パフォーマンス最優先。

設定:

• LogXptMode=’ASYNC’ NOAFFIRM

比較表

Physical Standby 構築（RMAN DUPLICATE）

事前準備（Primary 側）

-- Primary で
-- 1. Force Logging
ALTER DATABASE FORCE LOGGING;

-- 2. Archivelog モード
ARCHIVE LOG LIST;
-- 未有効なら:
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

-- 3. Standby Redo Log 追加
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 200M;
-- 通常 REDO ログ数+1 個推奨

-- 4. パラメータ設定
ALTER SYSTEM SET DB_UNIQUE_NAME='prod_pri' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(prod_pri,prod_sby)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=
  'LOCATION=USE_DB_RECOVERY_FILE_DEST 
   VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=prod_pri';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=
  'SERVICE=prod_sby ASYNC 
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=prod_sby';
ALTER SYSTEM SET FAL_SERVER=prod_sby;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
ALTER SYSTEM SET DB_FILE_NAME_CONVERT='prod_sby','prod_pri' SCOPE=SPFILE;
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT='prod_sby','prod_pri' SCOPE=SPFILE;

tnsnames.ora / listener.ora

両サーバーで:

# tnsnames.ora
prod_pri =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = prihost)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = prod_pri)))

prod_sby =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = sbyhost)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = prod_sby)))

Standby 側準備

# 1. init ファイル作成
cat > /tmp/initprod_sby.ora <<EOF
DB_NAME='prod_pri'
DB_UNIQUE_NAME='prod_sby'
EOF

# 2. NOMOUNT 起動
export ORACLE_SID=prod_sby
sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='/tmp/initprod_sby.ora';

RMAN DUPLICATE

# Primary から実行
$ rman target sys/pw@prod_pri auxiliary sys/pw@prod_sby

RMAN> DUPLICATE TARGET DATABASE
  FOR STANDBY
  FROM ACTIVE DATABASE
  SPFILE
  PARAMETER_VALUE_CONVERT '/u01/prod_pri','/u01/prod_sby'
  SET DB_UNIQUE_NAME='prod_sby'
  SET DB_FILE_NAME_CONVERT='/u01/prod_pri','/u01/prod_sby'
  SET LOG_FILE_NAME_CONVERT='/u01/prod_pri','/u01/prod_sby'
  SET FAL_SERVER='prod_pri'
  SET LOG_ARCHIVE_DEST_2='SERVICE=prod_pri ASYNC 
    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 
    DB_UNIQUE_NAME=prod_pri';

RMAN 関連は Oracle RMAN バックアップ完全ガイドの記事も参照してください。

Standby で Recovery 開始

-- MOUNT 状態から
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
  USING CURRENT LOGFILE DISCONNECT;

-- 確認
SELECT process, status, thread#, sequence#
FROM v$managed_standby;

-- MRP0 が APPLYING_LOG で稼働

Data Guard Broker

有効化

Primary + Standby 両方で:

ALTER SYSTEM SET DG_BROKER_START=TRUE;
ALTER SYSTEM SET DG_BROKER_CONFIG_FILE1='/u01/dg/dr1.dat';
ALTER SYSTEM SET DG_BROKER_CONFIG_FILE2='/u01/dg/dr2.dat';

設定作成

$ dgmgrl sys/pw@prod_pri

DGMGRL> CREATE CONFIGURATION 'PROD_DG' AS
        PRIMARY DATABASE IS 'prod_pri'
        CONNECT IDENTIFIER IS prod_pri;

DGMGRL> ADD DATABASE 'prod_sby' AS
        CONNECT IDENTIFIER IS prod_sby
        MAINTAINED AS PHYSICAL;

DGMGRL> ENABLE CONFIGURATION;

検証

DGMGRL> SHOW CONFIGURATION VERBOSE;
DGMGRL> SHOW DATABASE VERBOSE 'prod_pri';
DGMGRL> SHOW DATABASE VERBOSE 'prod_sby';
DGMGRL> VALIDATE DATABASE 'prod_sby';

DGMGRL コマンド完全リファレンス

基本コマンド

-- 設定表示
SHOW CONFIGURATION;
SHOW CONFIGURATION VERBOSE;

-- データベース情報
SHOW DATABASE 'prod_pri';
SHOW DATABASE VERBOSE 'prod_pri';

-- 検証
VALIDATE DATABASE 'prod_sby';
VALIDATE DATABASE VERBOSE 'prod_sby';

設定変更

-- Protection Mode
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

-- Redo Transport
EDIT DATABASE 'prod_pri' SET PROPERTY LogXptMode='SYNC';
EDIT DATABASE 'prod_sby' SET PROPERTY LogXptMode='SYNC';

-- Redo Apply 遅延
EDIT DATABASE 'prod_sby' SET PROPERTY DelayMins='60';

-- Redo Apply 再開
EDIT DATABASE 'prod_sby' SET STATE='APPLY-ON';
EDIT DATABASE 'prod_sby' SET STATE='APPLY-OFF';

-- Transport
EDIT DATABASE 'prod_pri' SET STATE='TRANSPORT-ON';
EDIT DATABASE 'prod_pri' SET STATE='TRANSPORT-OFF';

Switchover

-- 計画的な役割交換
DGMGRL> SWITCHOVER TO 'prod_sby';

-- 完了後、逆になる
-- prod_sby: Primary
-- prod_pri: Physical Standby

Failover

-- 緊急時（Primary 喪失）
DGMGRL> FAILOVER TO 'prod_sby';

-- Primary は再インスタンス化必要
DGMGRL> REINSTATE DATABASE 'prod_pri';

Convert Snapshot

-- Physical → Snapshot（テスト用途）
DGMGRL> CONVERT DATABASE 'prod_sby' TO SNAPSHOT STANDBY;

-- Snapshot → Physical（元に戻す）
DGMGRL> CONVERT DATABASE 'prod_sby' TO PHYSICAL STANDBY;

Fast-Start Failover (FSFO)

概要

FSFO:
- Primary 障害を Observer が検知
- Threshold 経過後、自動 Failover
- Zero Data Loss（MaxAvailability + SYNC）
- 手動介入不要
- Primary 復旧後、自動 Reinstate

設定

DGMGRL> EDIT DATABASE 'prod_pri' SET PROPERTY LogXptMode='SYNC';
DGMGRL> EDIT DATABASE 'prod_sby' SET PROPERTY LogXptMode='SYNC';
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

-- Failover target 双方向
DGMGRL> EDIT DATABASE 'prod_pri' SET PROPERTY FastStartFailoverTarget='prod_sby';
DGMGRL> EDIT DATABASE 'prod_sby' SET PROPERTY FastStartFailoverTarget='prod_pri';

-- Threshold
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold='30';

-- 有効化
DGMGRL> ENABLE FAST_START FAILOVER;

Observer 起動

別ホストで（Primary/Standby 以外）:

$ dgmgrl -logfile /var/log/observer.log sys/pw@prod_pri "START OBSERVER"

状態確認

DGMGRL> SHOW FAST_START FAILOVER;

Fast-Start Failover: Enabled in Zero Data Loss Mode
  Protection Mode:     MaxAvailability
  Lag Limit:           0 seconds
  Threshold:           30 seconds
  Active Target:       prod_sby
  Observer:            observer_host
  Shutdown Primary:    TRUE
  Auto-reinstate:      TRUE

Active Data Guard

概要

Physical Standby を Read-Only で活用:

• Real-Time Query
• レポート実行
• バックアップオフロード
• Snapshot Standby ベース

⚠️ ライセンス: Active Data Guard オプション必要。

Real-Time Apply + Read-Only

-- Standby で
-- MOUNT 状態でスタート
STARTUP MOUNT;

-- Read Only Open + Recovery
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
  USING CURRENT LOGFILE DISCONNECT;

-- 確認
SELECT open_mode FROM v$database;
-- READ ONLY WITH APPLY

アプリからの利用

接続文字列を分離:

# tnsnames.ora
prod_write =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=prihost)(PORT=1521))
    (CONNECT_DATA=(SERVICE_NAME=prod_pri)))

prod_readonly =
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=sbyhost)(PORT=1521))
    (CONNECT_DATA=(SERVICE_NAME=prod_sby_ro)))

アプリ:

# Rails
# write
ActiveRecord::Base.establish_connection(:primary)
Order.create!(...)

# read
ActiveRecord::Base.connected_to(role: :reading) do
  Order.where(...).to_a
end

Rails 8 系の詳細は Rails 8 アップグレードガイドの記事も参照してください。

監視

主要ビュー

-- ロール確認
SELECT database_role, open_mode, protection_mode, 
       protection_level, switchover_status
FROM v$database;

-- Redo Transport 状態
SELECT process, status, thread#, sequence#, block#
FROM v$managed_standby;

-- Apply Lag / Transport Lag
SELECT name, value, unit
FROM v$dataguard_stats;

-- ログ適用状況
SELECT sequence#, applied, first_time, next_time
FROM v$archived_log
ORDER BY sequence# DESC
FETCH FIRST 10 ROWS ONLY;

-- Alert.log 相当
SELECT * FROM v$dataguard_status
WHERE severity IN ('Warning', 'Error')
ORDER BY timestamp DESC;

DGMGRL 監視

DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW DATABASE VERBOSE 'prod_sby';

-- 主要指標:
-- Transport Lag
-- Apply Lag
-- Real-Time Query
-- Average Apply Rate

Far Sync（長距離同期）

概要

Far Sync インスタンス:

• Redo のみ受信・転送する中間ノード
• データファイルなし
• 長距離への Zero Data Loss 実現
• 12c+ 機能

Primary → (SYNC) → Far Sync → (ASYNC) → Standby
   ↑近い←        →      ↑        遠い→       ↑
   
Primary からは SYNC で近くの Far Sync に到達
Far Sync から遠い Standby へは ASYNC

メリット:

• Primary のレイテンシ影響最小
• 遠隔地 Standby でも Zero Data Loss

Rolling Upgrade

DBMS_ROLLING（12c+）

-- 準備
BEGIN
  DBMS_ROLLING.INIT_PLAN(future_primary => 'prod_sby');
  DBMS_ROLLING.BUILD_PLAN;
END;
/

-- Standby でアップグレード
BEGIN
  DBMS_ROLLING.START_PLAN;
END;
/

-- Switchover
BEGIN
  DBMS_ROLLING.SWITCHOVER;
END;
/

-- 完了
BEGIN
  DBMS_ROLLING.FINISH_PLAN;
END;
/

無停止で Oracle アップグレードが可能。

Autonomous Data Guard

OCI Autonomous Data Guard

マネージドサービス:

- 自動プロビジョニング
- 別 Availability Domain または別 Region
- 自動 Failover
- Zero Data Loss（Cross AD）
- 5 秒 RPO（Cross Region）
- OCI Console から数クリック

設定:

oci db autonomous-database create \
  --autonomous-database-id $ADB_OCID \
  --enable-cross-region-data-guard true \
  --peer-cloud-provider oracle \
  --peer-region-code us-ashburn-1

実践シナリオ

シナリオ1：完全構築フロー

# 1. Primary 準備
sqlplus / as sysdba <<EOF
ALTER DATABASE FORCE LOGGING;
ALTER DATABASE ARCHIVELOG;
-- Standby Redo Log 追加
-- パラメータ設定
EOF

# 2. Standby 準備（NOMOUNT）
export ORACLE_SID=prod_sby
sqlplus / as sysdba <<EOF
STARTUP NOMOUNT PFILE='/tmp/initprod_sby.ora';
EOF

# 3. RMAN DUPLICATE
rman target sys/pw@prod_pri auxiliary sys/pw@prod_sby <<EOF
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE ...;
EOF

# 4. Standby Recovery 開始
sqlplus / as sysdba <<EOF
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
  USING CURRENT LOGFILE DISCONNECT;
EOF

# 5. Broker 設定
dgmgrl sys/pw@prod_pri <<EOF
CREATE CONFIGURATION 'PROD_DG' AS PRIMARY DATABASE IS 'prod_pri' ...;
ADD DATABASE 'prod_sby' ...;
ENABLE CONFIGURATION;
EOF

# 6. Protection Mode + FSFO
dgmgrl sys/pw@prod_pri <<EOF
EDIT DATABASE 'prod_pri' SET PROPERTY LogXptMode='SYNC';
EDIT DATABASE 'prod_sby' SET PROPERTY LogXptMode='SYNC';
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
ENABLE FAST_START FAILOVER;
EOF

# 7. Observer 起動（別ホスト）
dgmgrl -logfile /var/log/observer.log sys/pw@prod_pri "START OBSERVER" &

シナリオ2：定期 Switchover テスト

# 週次または月次で Switchover テスト
dgmgrl sys/pw@prod_pri <<EOF
SHOW CONFIGURATION;
SWITCHOVER TO 'prod_sby';
SHOW CONFIGURATION;
EOF

# アプリ動作確認後、元に戻す
dgmgrl sys/pw@prod_sby <<EOF
SWITCHOVER TO 'prod_pri';
EOF

シナリオ3：緊急 Failover 手順

# Primary 完全障害検知
dgmgrl sys/pw@prod_sby <<EOF
SHOW CONFIGURATION;
-- Primary 到達不可

FAILOVER TO 'prod_sby';
-- 新 Primary: prod_sby

SHOW CONFIGURATION;
EOF

# アプリの接続先を prod_sby に変更（DNS 更新等）

# Primary 復旧後
dgmgrl sys/pw@prod_sby <<EOF
REINSTATE DATABASE 'prod_pri';
EOF

シナリオ4：Standby でのバックアップオフロード

# Standby で RMAN 実行
rman target sys/pw@prod_sby <<EOF
BACKUP INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
EOF

# Primary 負荷ゼロで Backup 取得可能

RMAN 関連は Oracle RMAN バックアップ完全ガイドの記事も参照してください。

シナリオ5：Snapshot Standby でテスト

# 開発用に Snapshot 化
dgmgrl <<EOF
CONVERT DATABASE 'prod_sby' TO SNAPSHOT STANDBY;
EOF

# アプリからテスト DML 実行

# 元に戻す
dgmgrl <<EOF
CONVERT DATABASE 'prod_sby' TO PHYSICAL STANDBY;
EOF

# Redo キャッチアップ後、Standby として復帰

シナリオ6：Rails Active Data Guard 分離

# config/database.yml
production:
  primary:
    adapter: oracle_enhanced
    database: prod_write
    username: app_user
    password: <%= ENV['DB_PW'] %>
  primary_replica:
    adapter: oracle_enhanced
    database: prod_readonly
    username: app_user
    password: <%= ENV['DB_PW'] %>
    replica: true

# application_record.rb
class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class
  connects_to database: { 
    writing: :primary, 
    reading: :primary_replica 
  }
end

# 使用例
class OrdersController < ApplicationController
  def index
    ActiveRecord::Base.connected_to(role: :reading) do
      @orders = Order.recent  # Standby から読み取り
    end
  end
  
  def create
    Order.create!(...)  # Primary へ書き込み
  end
end

シナリオ7：Java Spring での分離

@Configuration
public class DataSourceConfig {
    @Bean
    @Primary
    public DataSource writeDataSource() {
        return DataSourceBuilder.create()
            .url("jdbc:oracle:thin:@prod_write")
            .build();
    }
    
    @Bean
    public DataSource readDataSource() {
        return DataSourceBuilder.create()
            .url("jdbc:oracle:thin:@prod_readonly")
            .build();
    }
}

@Transactional(readOnly = true)
public List<Order> findOrders() {
    // read data source 使用
}

@Transactional
public void createOrder(Order o) {
    // write data source 使用
}

シナリオ8：Python での接続分離

import oracledb
import os

class DBConnections:
    @staticmethod
    def write_conn():
        return oracledb.connect(
            user='app',
            password=os.getenv('DB_PW'),
            dsn='prod_write'
        )
    
    @staticmethod
    def read_conn():
        return oracledb.connect(
            user='app',
            password=os.getenv('DB_PW'),
            dsn='prod_readonly'
        )

シナリオ9：Docker/K8s での監視

apiVersion: v1
kind: ConfigMap
metadata:
  name: dg-monitor
data:
  check.sh: |
    #!/bin/bash
    LAG=$(sqlplus -s app/$DB_PW@prod_sby <<EOF | grep -oP '\d+'
    SET HEAD OFF FEEDBACK OFF
    SELECT value FROM v\$dataguard_stats WHERE name = 'apply lag';
    EXIT
    EOF
    )
    if [ "$LAG" -gt "60" ]; then
      echo "ALERT: Apply lag $LAG seconds"
      exit 1
    fi

Docker 関連は docker daemon 接続エラーの記事、Docker no space left on device の記事も参照してください。

シナリオ10：Autonomous DG（OCI）

# OCI CLI で Autonomous Data Guard 有効化
oci db autonomous-database update \
  --autonomous-database-id $ADB_OCID \
  --db-workload OLTP \
  --is-data-guard-enabled true

# Failover 実行
oci db autonomous-database failover \
  --autonomous-database-id $STANDBY_OCID

トラブルシューティング

Apply Lag が拡大

-- Standby で確認
SELECT process, status, sequence#, block#
FROM v$managed_standby WHERE process LIKE 'MRP%';

-- ネットワーク帯域 or Standby I/O 性能問題
-- Real-Time Apply 有効化
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
  USING CURRENT LOGFILE DISCONNECT;

GAP が発生

-- Standby で
SELECT * FROM v$archive_gap;

-- 手動で Archive log コピー + 適用
-- または FAL_SERVER で自動取得

Broker エラー

ORA-16629 など:

DGMGRL> VALIDATE DATABASE 'prod_sby';
-- 詳細確認

-- Broker ログ確認
SELECT * FROM v$dataguard_status ORDER BY timestamp DESC;

FSFO 動作しない

DGMGRL> SHOW FAST_START FAILOVER;

-- Observer 到達確認
-- Threshold 適切設定
-- 前提条件（Real-Time Apply、SRL）

Snapshot Standby 変換遅い

Redo 適用未完了、変換前に Recovery 完了確認。

PostgreSQL からの移行

PG は Physical Replication + Logical Replication、Oracle Data Guard は統合ツール、Broker が優秀。

よくある質問（FAQ）

Q1. Physical と Logical の選び方

Physical 推奨、Logical は特殊要件のみ。

Q2. Protection Mode の選び方

MaxAvailability 推奨、金融は Protection、遠距離は Performance。

Q3. Broker 使うべきか

必ず使う、管理が圧倒的に楽。

Q4. FSFO の Observer 配置

Primary/Standby 以外、第三サイト推奨。

Q5. Active Data Guard のライセンス

追加ライセンス、レポート DB 分離で ROI 高い。

Q6. Far Sync の使い所

遠距離 Zero Data Loss 必要時。

Q7. Rolling Upgrade

DBMS_ROLLING で 12c+、無停止アップグレード。

Q8. Snapshot Standby の使い所

テスト環境、本番データで開発検証。

Q9. Rails 対応

Multi-DB 対応、connects_to で分離。

Q10. Java 対応

複数 DataSource、@Transactional(readOnly)。

Q11. Autonomous DG

OCI マネージド、自動化で運用負荷ゼロ。

Q12. 予防策

• 定期 Switchover テスト
• 監視統合
• Alert.log 監視
• FSFO Observer 冗長化

参考リンク

Oracle 公式

• Oracle Data Guard Concepts and Administration
• Oracle Data Guard Broker
• DGMGRL Command Reference
• Active Data Guard

まとめ

Oracle Data Guard の要点を再整理します。

Data Guard の本質

Primary DB の Redo を Standby DB へ転送・適用
- DR: 災害時の業務継続
- HA: 高可用性
- Read Offload: Active Data Guard
- Rolling Upgrade: 無停止アップグレード

3 種類の Standby

3 種類の Protection Mode

推奨実務構成

Protection Mode: MaxAvailability
Redo Transport:  SYNC AFFIRM
Redo Apply:      Real-Time Apply
Broker:          Enabled
FSFO:            Enabled
Active DG:       Enabled（ライセンス有）
Observer:        別ホスト（第三サイト）

DGMGRL 主要コマンド

SHOW CONFIGURATION;
SHOW DATABASE VERBOSE 'prod_sby';
VALIDATE DATABASE 'prod_sby';

EDIT DATABASE ... SET PROPERTY LogXptMode='SYNC';
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

SWITCHOVER TO 'prod_sby';
FAILOVER TO 'prod_sby';
REINSTATE DATABASE 'prod_pri';

CONVERT DATABASE 'prod_sby' TO SNAPSHOT STANDBY;
CONVERT DATABASE 'prod_sby' TO PHYSICAL STANDBY;

ENABLE FAST_START FAILOVER;
DISABLE FAST_START FAILOVER;

実務チェックリスト

□ Primary FORCE LOGGING + ARCHIVELOG
□ Standby Redo Log 追加（REDO 数+1）
□ tnsnames.ora 双方向
□ RMAN DUPLICATE FOR STANDBY
□ Broker 有効化 + Configuration 作成
□ Protection Mode 適切選択
□ Real-Time Apply 有効
□ FSFO + Observer 配置
□ Active Data Guard 検討
□ 定期 Switchover テスト
□ 監視統合（Rails/Java/Python）
□ Alert.log + v$dataguard_status
□ Autonomous DG 検討（OCI）

これらの知識は、Oracle DBA の本番運用・DR 計画・HA 設計・災害対策・Rails/Java/Python アプリ運用・Cloud/Autonomous DB 運用・大規模エンタープライズ・金融・電力・SOX/PCI/HIPAA コンプライアンスなど、あらゆる場面で活用できます。本記事をブックマークしておけば、Oracle Data Guard のプロフェッショナルとして本番運用を安心して任せられるようになります。

本記事は2026年6月時点の情報をもとに、Oracle Database 19c〜23ai での動作確認・公式ドキュメントに基づき作成しています。Oracle のバージョンにより挙動が異なる場合があるため、最新の情報は Oracle 公式ドキュメント（docs.oracle.com）もあわせてご確認ください。