OracleでREDOログを冗長化する方法とその設計思想・実務運用のベストプラクティス

REDOログはOracleデータベースの生命線とも言えるファイル群です。
このREDOログが1ファイルでも破損すると、クラッシュリカバリが不可能になり、データベースが起動できない致命的事態に陥ります。

本記事では、単なる構成手順にとどまらず、なぜ冗長化が必要なのか、どこに配置すべきか、どんな障害に備えるべきかといった運用設計レベルまで踏み込んで、OracleのREDOログ冗長化を徹底解説します。

💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？

Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？

✅ REDOログ冗長化とは何か？なぜ必要か？
1. ✅ テキスト図：冗長構成のイメージ
🔥 冗長化がなぜ必要か？3つの観点で解説
🔍 現在のREDOログ構成を確認する方法
1. 出力例：
🛠 REDOログを冗長化する構成手順
🧠 プロ運用者向けTips：ファイル名とパスのルール
🛡 トラブル対応：片方のメンバーが壊れたら？
🗑 冗長メンバーの削除（入れ替えなどで不要になった場合）
⚠️ よくある誤解・注意点まとめ
🏁 実務でのおすすめ構成例
✅ まとめ

✅ REDOログ冗長化とは何か？なぜ必要か？

Oracleでは、1つのロググループ（GROUP）に対し、複数のログメンバー（MEMBER）を構成することで、ミラーリングによる冗長性を確保できます。

✅ テキスト図：冗長構成のイメージ

┌──────────────┐
│   GROUP 1    │
│ ┌──────────┐ │
│ │ redo01a.log │ ← /u01/oradata
│ │ redo01b.log │ ← /u02/redo
│ └──────────┘ │
└──────────────┘

この構成により、片方のログファイルが破損してももう一方でトランザクション記録を維持できます。

🔥 冗長化がなぜ必要か？3つの観点で解説

観点	説明
可用性	REDOログ破損時でもDBが停止せず、業務継続可能。システムの安定稼働を保証。
リカバリ耐性	クラッシュ後の自動リカバリ（インスタンスリカバリ）が成功する確率が上がる。
ストレージ障害対策	ディスク障害やパス不良に備え、別ディスクに配置することで保護が強化される。

🔍 現在のREDOログ構成を確認する方法

SELECT GROUP#, MEMBER FROM V$LOGFILE ORDER BY GROUP#;

出力例：

GROUP#  MEMBER
------- ---------------------------------------------
1       /u01/app/oracle/oradata/ORCL/redo01.log
2       /u01/app/oracle/oradata/ORCL/redo02.log
3       /u01/app/oracle/oradata/ORCL/redo03.log

このように、1グループ1ファイルしかない場合は、冗長化されていません。

🛠 REDOログを冗長化する構成手順

Step 1：冗長ファイル用ディレクトリを別マウントポイントに準備

例：

既存 → /u01/app/oracle/oradata/ORCL/redo01.log
ミラー → /u02/oracle/redo/redo01_mirror.log

✅ 別ディスク、別マウントポイントが基本です。同じディスクだと同時障害リスクがあるため意味がありません。

Step 2：ALTER DATABASEでメンバー追加

ALTER DATABASE ADD LOGFILE MEMBER '/u02/oracle/redo/redo01_mirror.log' TO GROUP 1;
ALTER DATABASE ADD LOGFILE MEMBER '/u02/oracle/redo/redo02_mirror.log' TO GROUP 2;
ALTER DATABASE ADD LOGFILE MEMBER '/u02/oracle/redo/redo03_mirror.log' TO GROUP 3;

Step 3：構成が反映されたか確認

SELECT GROUP#, MEMBER FROM V$LOGFILE ORDER BY GROUP#;

GROUP#  MEMBER
------- ---------------------------------------------
1       /u01/app/oracle/oradata/ORCL/redo01.log
1       /u02/oracle/redo/redo01_mirror.log
...

🧠 プロ運用者向けTips：ファイル名とパスのルール

冗長構成のファイル名は「グループ番号」や「_mirror」を入れると後から分かりやすい
LVMなどでパーティションを分けている場合、/redo専用パーティションを割り当てるのも有効

💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？

🛡 トラブル対応：片方のメンバーが壊れたら？

Oracleは正常なメンバーが1つでもあれば処理を継続し、アラートログに以下のようなエラーを出力します。

ORA-00313: open failed for members of log group 1

✅ 障害に気づかないとロググループ全体が壊れるリスクもあるため、定期的なV$LOGFILEチェックや監視が重要です。

🗑 冗長メンバーの削除（入れ替えなどで不要になった場合）

ALTER DATABASE DROP LOGFILE MEMBER '/u02/oracle/redo/redo01_mirror.log';

🔸ただし、そのグループに少なくとも1つの正常なメンバーが残っている必要があります。

⚠️ よくある誤解・注意点まとめ

誤解 or ミス	実際の挙動・注意点
「ミラーだから同じディスクでOK」	→ NG。障害時に同時に壊れたら意味がない
「DROP MEMBERしてもすぐ反映される」	→ 実は物理ファイルは手動で削除が必要
「冗長化はアーカイブログに関係ない」	→ 関係ある。ロググループ破損時はアーカイブ不能になることも

🏁 実務でのおすすめ構成例

環境	グループ数	メンバー数/グループ	配置戦略
単一構成	3	2	`/u01/oradata` + `/u02/redo`
RAC構成	ノード数×2	2	各ノードにローカル＋共有ディスク配置
高可用性構成	4	3（冗長性強化）	`/u01`, `/u02`, `/u03`に分散

✅ まとめ

項目	内容
冗長化方法	`ALTER DATABASE ADD LOGFILE MEMBER`でメンバー追加
推奨配置	別ディスク、別マウントポイントに配置するのが鉄則
可用性の効果	ログ破損時の障害回避、クラッシュリカバリの成功率向上
削除時の注意点	GROUPに1つ以上残す、DROP後にOSレベルでファイル削除も必要
定期確認項目	`V$LOGFILE`のメンバー数、`ALERT.LOG`のREDO関連エラーの有無