ブログ | 2026年8月11日

Oracle Data Guardの設定方法（手順解説ガイド）

Oracle Data Guardの環境構築は複雑になりがちで、特にスタンバイデータベース、REDOログ転送、リカバリ設定周りの作業が難しいです。本ガイドでは作業手順を分かりやすく段階別に整理し、トラブルや混乱を抑え、安定した高可用性環境を構築できるよう解説します。

By: Emma

Oracle Data Guardとは何か

Oracle Data GuardはOracle標準搭載の高可用性（HA）・災害復旧ソリューションです。データベースに対するすべての変更記録であるREDOデータを継続的に転送・適用することで、1台または複数のスタンバイデータベースをプライマリ（本番）データベースと同期させます。

ハードウェア障害、人為的ミス、サイト全体の災害などでプライマリデータベースが停止した場合、Data Guardはスタンバイデータベースを昇格させて業務を引き継ぎ、停止時間とデータ損失を最小限に抑えます。

スタンバイデータベースの種類

Data Guardは3種類のスタンバイをサポートしています。適切な種類の選択は復旧目標とスタンバイの活用用途に基づきます。

スタンバイ種別	動作原理	適した用途
物理スタンバイ	REDOデータをブロック単位で直接適用し、プライマリと完全に同一のバイト単位コピーを作成	災害復旧・HAフェイルオーバー
論理スタンバイ	REDOデータをSQL文に変換して適用。スタンバイを読み取り専用で起動可能、スキーマ構成をプライマリと異なる設定にできる	レポート作成・オンラインマイグレーション
スナップショットスタンバイ	物理スタンバイを一時的に書き込み可能なコピーに変換。REDOデータは受信するが、元の状態に戻すまで適用しない	実本番データを利用した開発・検証

Oracle Data Guard構成の前提条件

各種コマンドを実行する前に環境を適切に準備する必要があります。これらの事前準備の不備はData Guard構成失敗の最も多い原因の一つです。

システム要件

プライマリサーバーとスタンバイサーバーの環境は可能な限り統一する必要があります。OSバージョンやパッチレベルの差異はREDO適用時に予期せぬエラーを引き起こします。

OS：両サーバーで同一OSバージョン・カーネルパラメータを使用
Oracleソフトウェア：両サーバーに同一のOracle DatabaseバージョンおよびPSU（パッチセットアップデート）をインストール
一意の命名規則：両データベースは同一のDB_NAMEを共有し、異なるDB_UNIQUE_NAMEを設定（例：prod_pri、prod_stdby）
ストレージ：スタンバイサーバーにプライマリのデータファイル、アーカイブログ、一時ファイルを保存する十分なディスク容量を確保

データベース事前設定

構成作業を開始する前に、プライマリデータベースで以下の初期化パラメータが正しく設定されているか確認します。

DB_NAME — プライマリ・スタンバイで同一の値を設定
DB_UNIQUE_NAME — Data Guard構成内で各データベースに固有の識別子を付与
LOG_ARCHIVE_CONFIG — ノード間のREDOログ送受信機能を有効化

ヒント： Oracleリスナーポート（既定1521番）の通信を許可するようネットワーク設定を行ってください。ファイアウォールでポートが遮断されるとREDOログの転送が完全に停止します。

Oracle Data Guard構成手順（ステップバイステップ）

Data Guardの構築には定められた手順が存在します。まずプライマリデータベースを設定し、REDOデータを生成しスタンバイへ送信できる状態に準備します。

手順1：プライマリデータベースの準備

プライマリデータベースをARCHIVELOGモードで起動し、REDOデータを保存してスタンバイへ転送できるようにします。またFORCE LOGGINGを有効化し、ダイレクトロードなどの操作がREDOログに記録されずスタンバイとの同期が崩れる事態を防ぎます。

プライマリデータベース – SQL*Plus

-- ARCHIVELOGモードへ切り替え
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE FORCE LOGGING;
ALTER DATABASE OPEN;

-- 設定確認
SELECT log_mode, force_logging FROM v$database;

手順2：スタンバイREDOログの作成

スタンバイREDOログ（SRL）はプライマリから受信したREDOデータを格納します。リアルタイム適用機能に必須で、アーカイブログの完全な転送を待たず、ログ受信と同時にスタンバイへ変更を反映可能にします。

推奨設定：オンラインREDOロググループの数より1つ多いSRLグループを同一サイズで作成。オンラインログが3グループの場合はSRLを4グループ作成します。

プライマリデータベース – SQL*Plus

ALTER DATABASE ADD STANDBY LOGFILE
GROUP 4 ('/u01/app/oracle/oradata/srl04.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE
GROUP 5 ('/u01/app/oracle/oradata/srl05.log') SIZE 200M;

ALTER DATABASE ADD STANDBY LOGFILE
GROUP 6 ('/u01/app/oracle/oradata/srl06.log') SIZE 200M;

補足： SRLはプライマリ側で作成します。これにより、将来プライマリがスタンバイ役割に切り替わった際もREDO受信に対応できるよう事前準備が完了します。

手順3：Oracle Net通信設定

プライマリとスタンバイのデータベースはOracle Net Services経由で通信します。tnsnames.oraとlistener.oraの2ファイルを設定する必要があります。

tnsnames.oraの更新

両サーバーに2つのデータベースの接続定義を追記します。これにより相互にネットワーク上で相手先を解決できるようになります。

プライマリ・スタンバイサーバー共通 – tnsnames.ora

PRIMARY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = pri_server_ip)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = primary_db_service)
    )
  )

STANDBY =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = stdby_server_ip)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = standby_db_service)
    )
  )

リスナー設定

スタンバイ側のlistener.oraに静的リスナー定義を記述する必要があります。スタンバイ作成初期はNOMOUNTまたはMOUNT状態で起動するため、動的登録が機能しません。静的定義がないとリスナーがサービスを認識できず、プライマリから接続できなくなります。

スタンバイサーバー – listener.ora

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = standby_db_service)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)
      (SID_NAME = standby_sid)
    )
  )

通信疎通確認

両ファイルの更新後、リスナーをリロード（lsnrctl reload）し、プライマリサーバーから疎通テストを実行します。

プライマリサーバー – シェル

tnsping standby

ヒント： tnspingが失敗する場合はファイアウォールルールを確認し、tnsnames.ora内のホスト名・ポート番号に誤記がないか点検してください。

手順4：プライマリデータベースのバックアップ作成

スタンバイを初期化するにはプライマリデータベースの整合性の取れた複製データが必要です。標準ツールであるRMAN（リカバリマネージャー）を使用し、データファイルとスタンバイ同期に必要なアーカイブログをまとめて取得します。

プライマリデータベース – RMAN

RMAN TARGET /
BACKUP DATABASE PLUS ARCHIVELOG;

step 4 create a backup of the primary database

ヒント： バックアップ完了後、バックアップセット、パスワードファイル、PFILE/SPFILEをプライマリからスタンバイサーバーの同一パスへコピーします。

手順5：スタンバイデータベースの作成

スタンバイサーバーにバックアップファイルを配置したらデータベースをリストアします。プライマリからコピーしたパラメータファイルを使用しスタンバイインスタンスをNOMOUNTモードで起動後、RMANでリストアを実行しスタンバイとしてマウントします。

スタンバイデータベース – SQL*Plus

STARTUP NOMOUNT;

スタンバイデータベース – RMAN

RMAN TARGET /

-- まず制御ファイルをリストア
RESTORE CONTROLFILE FROM '/path/to/backup/controlfile_auto';

-- データファイルをリストア
RESTORE DATABASE;

-- スタンバイとしてマウント
ALTER DATABASE MOUNT STANDBY DATABASE;

STANDBY DATABASEとしてマウントすることで、このインスタンスが自身のトランザクションを生成せず、REDOログを受信・適用する役割であることをOracleに通知します。

手順6：ログ転送サービスの設定

スタンバイのマウント完了後、プライマリ側にREDOデータの送信先を定義します。プライマリデータベースのログ転送サービスパラメータで設定を行います。

核心パラメータはLOG_ARCHIVE_DEST_2で、スタンバイの送信先と転送方式を定義します。

プライマリデータベース – SQL*Plus

-- Data Guard構成にプライマリ・スタンバイを登録
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db_unique_name,standby_db_unique_name)';

-- リモートアーカイブ先を定義
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=
'SERVICE=standby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db_unique_name';

-- 送信先を有効化
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

ASYNC（非同期）転送を使用することで、ネットワーク遅延時にプライマリデータベースのパフォーマンスへの影響を回避します。VALID_FOR属性はこの送信先をプライマリ役割時のみに限定し、データベースがスタンバイに切り替わった際に適用されないよう制御します。

手順7：スタンバイデータベースのREDO適用を起動

最後の手順としてスタンバイ側でREDO適用を起動します。バックグラウンドプロセスが起動し、プライマリから継続的にREDOデータを受信しスタンバイのデータファイルに反映します。

スタンバイデータベース – SQL*Plus

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

USING CURRENT LOGFILE DISCONNECT;

USING CURRENT LOGFILEはリアルタイム適用を有効化し、アーカイブログの完全転送を待たず、スタンバイREDOログに到着した変更を即時反映します。DISCONNECTはプロセスをバックグラウンドで実行し、SQL*Plusセッションを解放します。

補足： REDO適用が稼働しているか確認するにはスタンバイ側でv$managed_standbyを照会し、APPLYING_LOGステータスが表示されているか確認します。

自動化保護によるOracle高可用性の簡素化

Oracle Data GuardはOracleのHA基盤を提供しますが、複製状況の監視、フェイルオーバースクリプトの運用、スタンバイ同期維持など、継続的な手動管理が必要です。

インフラ全体に対してより広範かつ自動化された高可用性を求める企業には、i2Availabilityが補完的な保護レイヤーを提供します。

i2Availabilityの主な機能

自動HA保証：複数ハートビート監視、ノード・ディスク仲裁機構により誤切り替えとスプリットブレインを防止。サービス自動起動/停止用カスタムスクリプトに対応し、仮想IP切り替えにより秒単位の高速フェイルオーバーを実現。
無遅延レプリケーション：バイト単位レプリケーションで全書き込み処理をリアルタイム捕捉し、RPOをほぼゼロに抑えます。スタンバイデータはリストア不要で即時利用可能、逆方向同期により業務の高速ロールバックに対応。
エンタープライズ向けデータセキュリティ：AES/SM4暗号化によりデータ転送を保護。管理システムに強固なパスワードポリシーと総当たり攻撃防止機構を搭載。
最適化されたデータ転送帯域制御、転送再開、多段階圧縮に対応しネットワーク負荷を削減。非重要ファイルをフィルタリングし転送効率を向上。
統合運用管理Webコンソールからレプリケーション状況・進捗をグラフィカル監視。一括デプロイ、テンプレート型ルール作成、ネットワーク・設定異常検知用自動診断ツールを搭載。
クロスプラットフォーム対応物理・仮想・クラウド環境（P2P、P2V、V2V、V2P）のHA構成に対応。Oracle、MySQL、SQL Server、VMware、Hyper-Vなど主要仮想化プラットフォームをカバー。

金融、医療、官公庁など厳しい運用環境でOracleを運用する組織にとって、i2Availabilityはデータベース層を超え、アプリケーションスタック全体をカバーするHA戦略を拡張します。

60日間無料トライアル

Oracle Data Guard構成時の一般的なトラブル

Data Guardの大半のエラーはネットワーク設定または初期化パラメータの細かい見落としが原因です。代表的な不具合と解決策を記載します。

ログ転送エラー

アラートログにORA-12154またはORA-12514が出力される場合はtnsnames.oraの誤記、リスナー停止、1521ポート遮断のいずれかが原因です。tnsping standbyで疎通を確認し、両サーバーのリモートログインパスワードファイル（orapwd）が一致しているか確認してください。