Oracle Data Guard の日常運用と障害シナリオ (19c / 23ai)
Oracleレベル: 上級所要時間: 5 分 (確認) – 4 時間 (再構築)構築済みの Data Guard (physical standby) 構成の日常運用と障害リカバリの runbook です。構築には Data Guard 構築ガイドを使用します。何をすべきか確信がない場合は「ステータスとラグの確認」から始めてください。読み取り専用の診断で適切なシナリオに誘導されます (計画的 switchover、failover、旧 primary の reinstate、アーカイブ・ギャップ、RECOVER … FROM SERVICE によるロールフォワード、スタンバイの再構築、snapshot standby、apply/read-only、保護モード/FSFO/observer、データファイルと REDO ログの作業、スタンバイからの RMAN バックアップ)。各シナリオは 診断 → セーフティネット → 実施 → 検証 → 事後作業 の構成で、broker あり (DGMGRL) と broker なし (SQL) の手順を、シングル・インスタンス / Oracle Restart / RAC の違いとあわせて示します。
構成: Primary (シングル・インスタンス / Oracle Restart / RAC) + physical standby (シングル・インスタンス / Oracle Restart / RAC) + 任意で observer
シナリオ
- ステータスとラグの確認 (すべて正常か) — 読み取り専用: 構成、transport/apply lag、アーカイブ・ギャップ、プロセスとアラート・ログを確認し、何も変更しません。何をすべきか確信がない場合はここから始めてください。最後のステップで出力に応じた適切なシナリオがわかります。
- 計画的 switchover (ロールを入れ替える) — primary とスタンバイは正常で、ロールを計画的に入れ替えたい場合です (メンテナンス、DR 訓練、ロールを元に戻す)。データ損失はなく、アプリケーションは数分間停止します。primary にアクセスできる限り、ロール変更には常にこちらを選んでください。
- primary 喪失: スタンバイへ failover — primary にアクセスできず、復旧の見込みもない場合です (サーバー、ストレージ、サイトの喪失)。スタンバイが primary になります。元に戻せません。MaxPerformance では直前数秒のデータが失われる可能性があり、旧 primary は後で reinstate か再構築が必要です。primary にまだアクセスできる場合は switchover を選んでください。
- failover 後に旧 primary をスタンバイとして戻す (reinstate) — failover が行われ、旧 primary サーバーが復旧した場合です。Flashback Database が有効であれば、再構築せずに新 primary のスタンバイにします。新 primary はオープンのままです。flashback が無効、またはフラッシュバックの期間が足りない場合は、診断ステップで再構築に誘導されます。
- アーカイブ・ギャップ (gap): スタンバイが欠落したアーカイブ・ログを待っている — v$archive_gap が行を返す、またはアラート・ログに FAL/gap メッセージがあり、apply がある順序番号で止まっています。データベースはオープンのままです。欠落したアーカイブ・ログがどこにもない場合は、フォームの選択でロールフォワードの手順に切り替えます。
- スタンバイが大きく遅れている、またはアーカイブ・ログがない: ロールフォワード (RECOVER FROM SERVICE) — ギャップ分のアーカイブ・ログがどこにもない、NOLOGGING 操作でスタンバイが破損した、またはスタンバイが何日も遅れている場合です。スタンバイを再構築せずに primary から増分で同期します (18c 以降)。
- スタンバイを一から再構築する — reinstate (flashback なし) もロールフォワードもできない、またはスタンバイのファイル/制御ファイルが失われた場合です。スタンバイを削除して DUPLICATE で作り直します。primary はオープンのままですが、再構築が終わるまで保護されません (他のスタンバイがない場合)。
- snapshot standby への変換 / 戻す (テスト用の書込み可能なコピー) — スタンバイを一時的に読取り/書込みでオープンしてテストし、その後変更を破棄して physical standby に戻したい場合です。primary に影響はなく REDO の受信も続きますが、snapshot standby の間このスタンバイは failover に使えません。
- Redo Apply の停止 / 開始、apply インスタンスの変更、read-only オープン — メンテナンスのために MRP を停止または再開したい、RAC スタンバイで apply を別インスタンスに移したい、またはスタンバイをレポート用にオープンしたい場合です (Active Data Guard のライセンスに注意)。
- 保護モード、Fast-Start Failover と observer — MaxPerformance / MaxAvailability / MaxProtection を切り替えたい、FSFO を有効化/無効化したい、または observer を管理したい場合です。
- データファイル、REDO ログ、スタンバイ REDO ログの追加 / UNNAMED ファイル — primary にデータファイルまたは REDO ログを追加する、スタンバイに UNNAMED ファイルができた (ORA-01111/ORA-01274)、またはスタンバイ REDO ログが不足している場合です。
- スタンバイから RMAN バックアップを取得する — バックアップの負荷を primary から外すために RMAN バックアップをスタンバイで実行し、アーカイブ・ログ削除ポリシーをそれに合わせて設定したい場合です。
開始前の確認
- 全サーバーで oracle ユーザーのプロファイルに ORACLE_HOME=…、ORACLE_SID (…RAC ではノードごとに …1、…2 …………) と PATH が設定され、sqlplus、rman…、dgmgrl… が動作する。構成は Data Guard 構築ガイド またはそれと同等の方法で構築済み (TNS 別名 …、…、静的な _DGMGRL リスナー登録、同一のパスワード・ファイル)。
- ロールが入力値と一致していることを確認済み: 現在 … が primary、… が physical standby。そうでない場合 (例: 以前に switchover を行った) は入力の名前を入れ替えてください。
- SYS パスワードがわかっている (ロール変更、リモート・インスタンスの再起動、RMAN FROM SERVICE にはパスワード認証の接続が必要)。パスワードに @、/、"、空白は含まれていない。
- ライセンス: Data Guard は Enterprise Edition に含まれます。apply を継続したままオープン してスタンバイを使うこと、スタンバイでのブロック変更トラッキング、Far Sync には Active Data Guard ライセンスが必要です。snapshot standby と、apply を停止した状態での read-only オープンにはライセンスは不要です。
- 変更は承認済みのメンテナンス・ウィンドウ内で行い、アプリケーションと監視のチームに通知済み… (接続は数分間切断される)…。
- failover の判断は権限のある担当者が行い、旧 primary が 再びオープンされない こと (split-brain) が保証されている (サーバー停止、ネットワークから切り離し済み、またはインスタンスを MOUNT のまま保持)。
ガイドのフェーズ
- ステータス: 構成、ラグ、プロセス (読み取り専用) — broker 構成とロール変更の準備状況を表示する · primary 側を SQL で確認する · スタンバイ側を SQL で確認する · アラート・ログで Data Guard のエラーを検索する · 結果を判断して適切なシナリオを選ぶ
- 1. 診断: switchover の準備はできているか — 準備状況を確認する (VALIDATE) · 準備状況を確認する (SWITCHOVER … VERIFY) · スタンバイのラグを確認する
- 2. セーフティネット — 現在の構成を保存する (primary) · 現在の構成を保存する (スタンバイ)
- 3. 実施: switchover — switchover: … を primary にする (broker) · switchover を開始する (primary → スタンバイ) · 新 primary をオープンする (…) · Clusterware のロールを更新する (新 primary) · 他のインスタンスをオープンする (新 primary ノード …: …) · 旧 primary をスタンバイとして MOUNT する (…) …
- 4. 検証 — 新しいロールと構成を確認する · 新しいスタンバイで apply とラグを確認する
- 5. 事後作業 — アプリケーション、ジョブ、監視の確認
- 1. 診断: failover は本当に必要か — primary への接続を最後にもう一度試す (スタンバイから) · スタンバイの状態と想定されるデータ損失を評価する · broker から見た状態を表示する (スタンバイから)
- 2. セーフティネットと残りの REDO — スタンバイの現在の設定を保存する · 旧 primary を MOUNT して残りの REDO を送る (FLUSH REDO) · 欠落したアーカイブ・ログを手動でコピーする (broker なし、可能な場合)
- 3. 実施: failover — failover: … を primary にする (broker) · Redo Apply を停止して failover を実行する (SQL) · 新 primary をオープンする (SQL) · Clusterware のロールを更新する (新 primary) · 他のインスタンスをオープンする (新 primary ノード …: …)
- 4. 検証 — 新 primary を確認する
- 5. 事後作業 — 新 primary のフル・バックアップを取得する · 旧 primary が戻ってきたら: オープンしない
- アプリケーション・サービス (ロールベース) — … 側でサービスを定義して起動する (Clusterware) · … 側でサービスを定義する (Clusterware) · サービスとロール・トリガーを定義する (Grid なし) · クライアントの接続記述子を 2 つのアドレスで設定する
- 1. 診断: reinstate は可能か — 新 primary とロール変更の SCN を確認する · broker のステータスを表示する (新 primary) · 旧 primary を MOUNT してフラッシュバック期間を確認する
- 2. セーフティネット — 旧 primary の制御ファイルとパラメータを保存する
- 3. 実施: reinstate — 旧 primary を reinstate する (broker) · 他のインスタンスを起動する (旧 primary、RAC) · フラッシュバックして physical standby に変換する (SQL) · 新 primary で … 宛先を有効にする (SQL) · Redo Apply を開始し、ロール変更のレコードを通過させる (SQL)
- 4. 検証 — 構成を確認する · 旧 primary (新しいスタンバイ) で apply を確認する
- 5. 事後作業 — 元のロールに戻し (任意)、根本原因に対処する
- 1. 診断: ギャップはどこか、アーカイブ・ログはあるか — スタンバイでギャップとプロセスを表示する · FAL の接続とアラート・ログを確認する (スタンバイ) · 欠落したアーカイブ・ログはまだ primary にあるか · 欠落したアーカイブ・ログは RMAN バックアップにあるか
- 2. セーフティネット — スタンバイの FRA に空きがあることを確認する
- 3. 実施: 欠落したアーカイブ・ログを取得して登録する — アーカイブ・ログがバックアップにしかない場合: primary にリストアする · 欠落したアーカイブ・ログをファイルシステムにコピーしてスタンバイに送る (primary) · スタンバイでアーカイブ・ログを登録する · Redo Apply を再起動する (スタンバイ)
- 4. 検証 — ギャップが解消するのを監視する (スタンバイ)
- 5. 事後作業 — 一時コピーを削除する · 根本原因に対処する
- 1. 診断: スタンバイはどれだけ遅れているか — スタンバイの SCN と状態を表示する · primary で NOLOGGING 操作と COMPATIBLE の値を確認する
- 2. セーフティネット — スタンバイの制御ファイルと spfile をバックアップする
- 3. 実施: スタンバイをロールフォワードする — Redo Apply を停止する (スタンバイ) · スタンバイを MOUNT にする… (インスタンス 1 のみ)… · primary からスタンバイをロールフォワードする (RECOVER STANDBY DATABASE FROM SERVICE) · 他のスタンバイ・インスタンスを起動する · スタンバイ REDO ログとフラッシュバックの状態を確認する · Redo Apply を開始する (スタンバイ)
- 4. 検証 — ラグが解消したことを確認する
- 5. 事後作業 — 根本原因に対処する
- 1. 診断: 再構築は本当に必要か — 構成と primary の状態を表示する
- 2. セーフティネット — スタンバイの構成ファイルを保存する
- 3. 実施: 削除して再構築する — スタンバイを broker 構成から外す · primary でスタンバイ宛先を保留にする (DEFER) · 旧スタンバイ・データベースを削除する · 残っている broker、init、パスワード・ファイルを片付ける · 古い init ファイルを退避する (スタンバイ・ノード …: …) · 構築ガイドでスタンバイを作り直す …