Oracle Database の最高峰の可用性を実現するのが Oracle Data Guard です。本記事では、災害対策（DR）の要となる Data Guard の概要を図解を交えて詳しく解説し、導入によるメリットや注意点について実務目線でまとめます。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
結論：Oracle Data Guard でできること
Oracle Data Guard を導入することで、以下の 4 点が実現可能です。
- 災害対策 (DR): 本番サイトが被災しても、遠隔地の待機系へ切り替えて業務を継続。
- データ保護: REDO データのリアルタイム転送により、データ損失を最小化（ゼロにすることも可能）。
- 負荷分散: Active Data Guard を使用し、スタンバイ側で参照処理やバックアップを実行。
- ダウンタイム短縮: 移行やパッチ適用時にスタンバイを活用し、切替時間を最小化。
背景と基礎：Data Guard の詳細アーキテクチャ
Oracle Data Guard は、プライマリ・データベースで発生した変更（REDO）をスタンバイへ転送・適用することで同期を維持します。これを支えるのが 3 つの主要サービスです。
1. REDO 転送サービス (Redo Transport Services)
プライマリ側で発生した REDO データをスタンバイへ転送する役割を担います。
- LNS (Log Network Server) プロセス: プライマリのログ・バッファまたはオンライン REDO ログからデータを読み取り、ネットワーク経由でスタンバイへ送信します。
- 転送モード:
- SYNC (同期): スタンバイ側での書き込み完了を待ってからコミット。データ損失ゼロを優先。
- ASYNC (非同期): 書き込み完了を待たずにコミット。パフォーマンスを優先。
2. REDO 適用サービス (Apply Services)
スタンバイ側で受信した REDO データをデータベースに反映します。
- RFS (Remote File Server) プロセス: プライマリから届いた REDO を受け取り、スタンバイ REDO ログ (SRL) に書き込みます。
- MRP (Managed Recovery Process): 物理スタンバイにおいて、SRL の内容をデータファイルへ適用するリカバリ処理を実行します。
- リアルタイム適用: ログ・スイッチを待たず、SRL に書き込まれると同時に MRP が適用を開始する仕組みです。
3. ロール管理サービス (Role Management Services)
プライマリとスタンバイの役割交代（スイッチオーバー/フェイルオーバー）を制御します。
【詳細図解】Data Guard アーキテクチャ構成
[ プライマリ DB ] [ スタンバイ DB ]
+-------------------+ +-------------------+
| ユーザー・プロセス | | Managed Recovery |
| ↓ | | Process (MRP) |
| [ログ・バッファ] | | ↑ |
| ↓ | Network | [スタンバイ REDO] |
| [LGWR] → [LNS] ---(REDO転送)---> [RFS] ----┘ |
| ↓ | | ↓ |
| [オンライン REDO] | | [データファイル] |
+-------------------+ +-------------------+
運用を効率化する「Data Guard Broker」
Data Guard の運用には、多くのパラメータ設定や複雑な SQL 操作が伴います。これらを統合管理し、自動化するのが Data Guard Broker です。
Broker 導入のメリット
- スイッチオーバーの簡略化: 手動では多段階の SQL 処理が必要な切替を、
SWITCHOVER TO <スタンバイ>の 1 コマンドで安全に完結させます。 - Fast-Start Failover (FSFO): 障害検知から数秒で自動切替を行うために必須のコンポーネントです。
- 一元管理 (DGMGRL): プライマリとスタンバイの状態を一つの論理構成として監視・管理できます。
【図解】Data Guard Broker の管理構造
[ 管理者 / DGMGRL ]
|
(1) 設定変更・監視・切替指示
v
+-----------------------+ +-----------------------+
| プライマリ・ノード | (3) 通信 | スタンバイ・ノード |
| +-----------------+ |<------------>| +-----------------+ |
| | DMON プロセス | | | | DMON プロセス | |
| +-------+---------+ | | +-------+---------+ |
| | | | | |
| (2) インスタンス制御 | | (2) インスタンス制御 |
| v | | v |
| [ データベース ] | | [ データベース ] |
+-----------------------+ +-----------------------+
(1) 管理者が DGMGRL を通じて監視や切替の指示を出す。
(2) 各ノードの DMON プロセスが、ローカル DB の設定変更や起動停止を制御。
(3) 両サイトの DMON が相互に通信し、構成情報の同期や死活監視を行う。
一次情報に基づく補足 Oracle 公式ドキュメントでは、構成の複雑化によるオペレーションミスを防ぐため、Broker の使用がベストプラクティスとして強く推奨（Highly Recommended）されています。
Data Guard と Oracle GoldenGate (GG) の比較
災害対策やデータ連携の文脈で比較される Oracle GoldenGate (GG) との違いを整理します。
比較表：DG vs GG
| 比較項目 | Oracle Data Guard (DG) | Oracle GoldenGate (GG) |
|---|---|---|
| 複製の単位 | データベース全体 (物理レベル) | テーブル / スキーマ単位 (論理レベル) |
| 同期の方向 | 単方向 (1対N) | 単方向 / 双方向 (Active-Active) |
| 主な用途 | 災害対策 (DR) / 高可用性 (HA) | データ移行 / 集計 / リアルタイム連携 |
| ライセンス | Enterprise Edition に包含 | 別途購入が必要 |
データガード メリットとデメリット
Data Guard 導入におけるメリットを整理します。
メリット (Advantages)
- 高いデータ保護レベル: サイト障害やデータ破損に強い。
- 負荷分散: Active Data Guard でスタンバイを読み取り専用として活用可能。
- ダウンタイム削減: ローリング・アップグレード等に活用できる。
デメリット (Disadvantages)
- コスト: 同スペックのスタンバイ環境と、EE ライセンスが必要。
- ネットワーク依存: ネットワーク帯域や遅延が同期性能に直結する。
FAQ
Q: Standard Edition (SE2) でも Data Guard は使えますか？ A: いいえ。Data Guard は Enterprise Edition (EE) 限定の機能です。
Q: Broker を使わずに構築してもいいですか？ A: 技術的には可能（サポート対象）です。 しかし、手動運用は手順が複雑で人的ミスの原因になりやすく、自動フェイルオーバーも利用できないため、Oracle は Broker の利用を強く推奨しています。
Q: GoldenGate があれば Data Guard は不要ですか？ A: 用途が異なります。完全な DB レベルの身代わり（DR 対策）が必要な場合は、Data Guard が最も堅牢で運用がシンプルです。
まとめ
- Data Guard は REDO 転送を利用した Oracle の標準的な DR ソリューション。
- Broker は、可用性を高めるための「強く推奨される」管理フレームワーク。
- GoldenGate とは、物理的な複製（DG）か、論理的なデータ連携（GG）かで使い分ける。
[参考]
DG PDB構成(26ai)でのDGMGRLの使用例
本記事は Oracle Database 19c / 23ai / 26ai を対象に解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント