Oracle Data Guard

🛡️ Oracle Data Guardとは？

Oracle Data Guardは、企業の重要なデータに対して 高可用性（High Availability）、データ保護（Data Protection）、災害復旧（Disaster Recovery） を実現するための機能です。

📦 構成と基本概念

構成：
- 1つの本番データベース（Primary）
- 1つ以上のスタンバイデータベース（Standby）
- それらは Oracle Net で接続され、地理的に離れていてもOK。
目的：
- 本番DBに障害（計画・非計画問わず）が発生した場合に、スタンバイDBを昇格（スイッチオーバー/フェイルオーバー）して業務継続を実現。

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

種類	特徴	同期方法
物理スタンバイ	本番DBと完全に同一のブロック構造。	Redo Apply（ログの物理適用）
論理スタンバイ	データ内容は同じだが、構造は異なる場合も。	SQL Apply（RedoログをSQL文に変換して実行）
スナップショットスタンバイ	書き込み可能な一時スタンバイDB。	Redoは蓄積されるが適用されず、後で物理スタンバイに戻して適用

💡 スナップショットスタンバイは、アプリのテストやトラブルシュート時に便利です。

🔁 同期・適用に関する主なサービス

Redo Transport Service：
- 本番DBからスタンバイDBへ REDOログ情報 を転送する役割。
Apply Service（適用サービス）：
- Redo Apply： 物理スタンバイ用。ログをそのまま適用。
- SQL Apply： 論理スタンバイ用。REDOログをSQLに変換して適用。

✅ 利用シーン

データセンター障害時の復旧
アプリケーションのアップグレード前テスト
パフォーマンステストや障害シミュレーション
データ損失や破損のリスク軽減

🔁 通常のプライマリDBの挙動（前提）

クライアントがトランザクションを実行すると、ログバッファにREDOが貯まり、LGWR（Log Writer）プロセスがオンラインREDOログファイルに書き込み。
ログスイッチが発生すると、ARCn（アーカイバ）プロセスが起動し、アーカイブログを生成。

📡 スタンバイ構成時の追加プロセスと挙動

1. ログ送信：`LNS`（Log Writer Network Server）

プライマリDBからスタンバイDBへREDOログを送るプロセス。
2つの動作モードがある：

🔒 SYNC（同期モード）

LGWRはLNSにREDOを渡し、LNSはスタンバイ側のRFS（Remote File Server）へ即時転送。
RFSがスタンバイREDOログへの書き込みを完了しない限り、プライマリのトランザクションはコミットされない。
✅ 高いデータ保護が得られるが、❌ パフォーマンスに影響がある。

🚀 ASYNC（非同期モード）

プライマリ側のトランザクションは、スタンバイへのログ転送を待たずに即座にコミット可能。
✅ 高速だが、❌ ネットワーク障害時にデータロスのリスクがある。

📥 スタンバイ側の処理フロー

RFS（Remote File Server）：
- プライマリDBから受け取ったREDOを、スタンバイのスタンバイREDOログファイルに書き込み。
ネットワーク障害時：
- REDOがアーカイブログ経由で転送される。
- このとき、FAL（Fetch Archive Log）プロセスが介入し、ログギャップを解消する。
MRP（Managed Recovery Process）またはLSP（Logical Standby Process）：
- スタンバイREDOログからデータを読み込み、データベースに適用。
スタンバイでもARCnプロセスが動作し、アーカイブログを生成する。

✅ Oracle Data Guard 構成計画の概要（全体の5ステップのうちの1つ）

このレッスンでは、プライマリデータベースの準備について解説しています。

🧾 使用するサーバの構成例

サーバ名	役割	IPアドレスなど
Primary	プライマリDB	例：192.168.x.x
Standby	スタンバイDB	例：別の仮想マシン

🛠 プライマリDBの事前準備手順

① アーカイブログモードの有効化

ARCHIVELOG モードが有効か確認（V$DATABASE.LOG_MODE）。
無効な場合は、マニュアルの手順で有効化。

② フラッシュバックデータベースの有効化（推奨）

有効化することでフェイルオーバー後のリカバリが容易になる。

③ FORCE LOGGING モードの有効化

プライマリDBのトランザクションログを強制的に記録することで、一貫性を保つ。

⚙️ 初期化パラメータの設定

💾 ローカルへのREDOアーカイブ

LOG_ARCHIVE_DEST_1 に DBリカバリファイルの保存先を指定。
VALID_FOR=ALL_LOGFILES,ALL_ROLES でプライマリ・スタンバイの両方に対応。

🌐 スタンバイDBへのREDO転送

LOG_ARCHIVE_DEST_2 に SERVICE=スタンバイDB名 を指定。
転送モードは SYNC または ASYNC。
AFFIRM（書き込み後にACK）または NOAFFIRM（受信だけでACK）で信頼性を選べる。

📡 スタンバイロール関連のパラメータ設定

FAL_SERVER：フェイルオーバー先のサービス名
STANDBY_FILE_MANAGEMENT=AUTO：プライマリのファイル追加削除をスタンバイへ自動反映
DB_FILE_NAME_CONVERT や LOG_FILE_NAME_CONVERT で物理構成の差異に対応

🧱 REDOログ構成の確認とスタンバイREDOログの追加

プライマリに構成されているREDOログの数と構成を確認（V$LOG, V$LOGFILE）。
スタンバイREDOログがないことを確認（V$STANDBY_LOG）。
スタンバイに必要なREDOログ数は「プライマリより1つ多く」推奨 → 例：3→4個

📦 各種バックアップの取得と準備

初期化パラメータファイル（PFILE）のバックアップ
RMANによる以下のバックアップ作成：
- データベース全体
- アーカイブログ
- コントロールファイル（スタンバイ用）
バックアップディレクトリにパスワードファイルもコピー
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE に設定確認

🎯 Oracle DBインストール＆プライマリと同パッチレベルへ

🧱 事前準備

スタンバイ用の 仮想マシンの作成、Linuxインストール、Oracleソフトのダウンロード は、
プライマリと同じ手順で行う（この部分は動画では割愛）。
詳細手順は「Oracle Databaseインストールレッスン」を再確認。

🛠 主な設定手順

① Oracleホームディレクトリの作成とソフトの展開

/u01/app/oracle/product/19.0.0/dbhome_1 のようなディレクトリを作成。
Oracleユーザーに切り替えてソフトウェアアーカイブを解凍。

② プライマリと同じパッチ（例：1912）を適用する必要がある

古いOPatchユーティリティをバックアップして新しいものに置き換える。
OPatchをOracleホームディレクトリ直下に直接展開する必要がある。
正しくインストールされたことを確認。

③ 環境変数設定ファイルの作成

ORACLE_HOME, ORACLE_SID, PATH などをセットするスクリプトを作成。
Linuxの source コマンドで読み込む。

④ Oracle Databaseソフトウェアのインストール（DB作成はしない）

サイレントインストール用のレスポンスファイルを用意。
oracle.install.option=INSTALL_DB_SWONLY として、DB作成をスキップ。
その他の設定（UNIXグループ名、インベントリ、Oracleベース等）も指定。

⑤ インストール前のチェック（Prerequisite Check）

Oracle Linux 8では一部チェックが正常動作しないことがある。
インストールを継続するには、環境変数 CV_ASSUME_DISTID=OEL7.6 を設定し回避。

⑥ サイレントインストールの実行

runInstaller にレスポンスファイルを渡して実行。
終了後、rootユーザーでスクリプトを実行するように指示される → 実行。

⑦ パッチの適用

解凍済みのパッチ（1912）を OPatch apply コマンドで適用。
成功メッセージを確認し、プライマリと同じパッチバージョンになったことを確認。

🎯 プライマリとスタンバイサーバ間で相互に接続

🔧 主な作業手順

① プライマリ側のリスナー設定 (`listener.ora`)

リスナー設定ファイルに スタンバイ用のリスナーブロックを追加。
Data Guard通信専用のサービスが作成される。
設定変更後は リスナーを再起動。
再起動後、サービス一覧に Data Guard 用のサービスが含まれていることを確認。

② スタンバイ側のリスナー設定

プライマリの listener.ora の内容をコピーし、
- HOST
- GLOBAL_DBNAME
- SID_NAME
  をスタンバイ用に変更。
リスナー再起動。

③ プライマリ側のTNS設定 (`tnsnames.ora`)

プライマリの tnsnames.ora にスタンバイ接続用の記述を追加。
- プライマリの接続記述をコピーして、
- HOST をスタンバイのIPアドレスに、
- SERVICE_NAME をスタンバイDB名に変更。

④ スタンバイ側のTNS設定

プライマリの tnsnames.ora をコピーして、HOST をスタンバイ側のIPに変更。

🧪 接続確認

tnspingコマンドで、スタンバイ→プライマリ／プライマリ→スタンバイ両方向の接続確認を実施。
ここでは リスナーへのネットワーク接続のみの確認であり、データベース接続自体は確認されない。

そのため、スタンバイDBをまだ作成していなくても接続確認可能。

🎯 バックアップからスタンバイデータベースを構築

🔁 作業手順の概要

① バックアップファイルのコピー

プライマリDBで作成した以下のファイルを スタンバイサーバにコピーする。
- 制御ファイル（Control File）
- アーカイブログ
- パラメータファイル（PFILE）
- パスワードファイル
scp -r コマンドでバックアップディレクトリを再帰的にコピー。
コピー後、ファイルの所有者を oracle ユーザーに変更。

② パスワードファイルとパラメータファイルの配置

パスワードファイルを Oracleホームの dbs ディレクトリに配置。
パラメータファイル（PFILE）をコピーし、スタンバイ用に編集。

🛠️ パラメータファイル（PFILE）の編集内容

インスタンス名をスタンバイ用に変更。
audit_file_dest や control_files のパスをスタンバイDB用に変更。
db_file_name_convert / log_file_name_convert：
- プライマリ→スタンバイのファイルパス変換。
db_unique_name：
- スタンバイDB独自の識別名を設定。
log_archive_config、log_archive_dest_1、log_archive_dest_2 などの ログ送信設定を調整。

③ スタンバイDBの起動とRMANによる複製

スタンバイDBを nomount モードで起動。
RMAN にてプライマリDB（ターゲット）とスタンバイDB（オーメンタリー）へ接続。
以下のコマンドで バックアップからスタンバイDBを複製：
```
pgsql
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE;
```

④ サーバーパラメータファイル（SPFILE）の作成

作成したPFILEからSPFILEを作成。
インスタンスを再起動し、SPFILEを使用するようにする。

⑤ リカバリの実行と完了確認

スタンバイDBのアラートログに「メディアリカバリが必要」と表示。
Archived Redo Logsを適用して、整合性のある状態に復旧。
リカバリ成功のメッセージを確認。

🎯 Oracle Data Guard Broker（DGB）を使った管理

🧰 Data Guard Brokerとは？

Oracle Data Guard Brokerは、Data Guardの構成管理・監視を自動化・簡素化するための中央管理ツールです。

DGMGRL（Data Guard Command Line Interface） を使用してコマンドラインから操作できます。

🛠️ 構成ステップ概要

① Data Guard Brokerの有効化

プライマリDBとスタンバイDBの両方で以下を実施：
- dg_broker_start パラメータを TRUE に設定
- standby_file_management を AUTO に設定（ファイルの自動管理）

② DGMGRLによる設定

1. プライマリDBの登録

sql
DGMGRL> CREATE CONFIGURATION ... AS PRIMARY DATABASE IS ...;

2. スタンバイDBの追加

sql
DGMGRL> ADD DATABASE ... AS CONNECT IDENTIFIER IS ...;

初回追加時にエラー発生（log_archive_dest_2 の手動設定が問題）
対応策：log_archive_dest_2 を初期化（リセット）して、Brokerに任せる

3. 設定の有効化

sql
DGMGRL> ENABLE CONFIGURATION;

🔍 ステータス確認コマンド

sql
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SHOW DATABASE <DB名>;
DGMGRL> SHOW DATABASE VERBOSE <DB名>;

プライマリとスタンバイDBの状態、ログ送信や適用の状態、ラグの有無を確認可能。
「Real-time Query（スタンバイ上での読み取り）」も確認できる（※要別ライセンス）

🔄 メンテナンス時の操作例

スタンバイDBで作業が必要な場合：

ログ適用の一時停止

sql
DGMGRL> EDIT DATABASE <スタンバイDB名> SET STATE='APPLY-OFF';

ログ送信の一時停止

sql
DGMGRL> EDIT DATABASE <スタンバイDB名> SET STATE='TRANSPORT-OFF';

作業後に再有効化

sql
DGMGRL> EDIT DATABASE <スタンバイDB名> SET STATE='TRANSPORT-ON';
DGMGRL> EDIT DATABASE <スタンバイDB名> SET STATE='APPLY-ON';

💡 その他のポイント

スタンバイ側に Flashback Database を有効化（フェイルオーバーテスト等に備える）
HELP コマンドでDGMGRLの使い方を確認可能

🔄 スイッチオーバーとは？

スイッチオーバー（Switchover） とは、プライマリDBとスタンバイDBの役割を手動で入れ替える操作。
計画的メンテナンス時などに使用され、データロスが発生しないのが特徴。
データベースをリセットせずにロールを切り替えることが可能。

✅ スイッチオーバーの前提条件

操作は計画的に実施する必要があり、両方のDBがオンラインで正常稼働している必要がある。
操作前に VALIDATE コマンドで確認：
- スタンバイDBがスイッチオーバー/フェイルオーバーの両方に対応可能かを確認
- フェイルオーバーは破壊的操作なので、通常はスイッチオーバーを選択

🧪 スイッチオーバーの手順と確認

スイッチオーバーコマンドを実行
- プライマリとスタンバイがロールを交換
- 成功メッセージ「Switchover succeeded」が表示される
設定確認
- SHOW CONFIGURATION で現在のDBの役割を確認
- データベースビューをクエリして実際のロール変更を確認
アプリケーション確認
- 新しいプライマリDBでPDB（Pluggable Database）に接続し、データ確認
- アプリやスキーマへのアクセスが正常かを確認

🔁 定期的なスイッチオーバーの重要性

DBAの災害復旧手順訓練として有効
実施しておくことで、本番障害時の迅速対応力を高める

🔙 スイッチオーバーを戻す

最後に元の構成へ再度スイッチオーバーして元の状態に復元

☠️ フェイルオーバーとは？

フェイルオーバーは、災害や障害時にプライマリデータベースが利用不能になった際に実施されます。
通常の計画的な切替（スイッチオーバー）とは異なり、緊急対応として行われます。
フェイルオーバーでは、データ損失が発生する可能性があります（保護モードによる）。

🔁 スイッチオーバーとの違い

項目	スイッチオーバー	フェイルオーバー
実施タイミング	計画的（メンテナンス等）	緊急時（障害、災害等）
プライマリ	正常稼働	利用不可
データ損失	なし（保証あり）	可能性あり
再構成	原則不要	スタンバイDBの再構成または復元が必要

✅ フェイルオーバー手順（Data Guard Broker による）

スタンバイDBの有効性確認
→ 有効でなければフェイルオーバーできない
残りのアーカイブログ適用
→ 可能な限り、残っているログを適用
スタンバイDBをプライマリに昇格
ブローカー構成ファイルの更新
旧プライマリDBは無効化
→ ここで 再構成（Reinstate）作業が必要

🔁 スタンバイの復元（Reinstate）

以前のレッスンで Flashback Database を有効化しておいたため、以下で簡単に復旧可能：

sql

REINSTATE DATABASE 'ORCLDB';

Flashback が無効な場合は、一からスタンバイDBを再作成が必要だった。

✅ 動作確認

新しいプライマリDBにテーブルを作成し、"Hello" を挿入
スタンバイDB側にも自動で同じデータが反映されていることを確認

前の記事（Oracle Databaseのモニタリング）

次の記事（Oracleデータ移行）