Oracle RAC（Real Application Clusters）環境において、Oracle RAC の構成を理解する上で最も重要なのは「共有するもの」と「インスタンス固有のもの」を明確に区別することです。特に RAC のコンポーネントである UNDO 表領域や REDO ログの扱いは、可用性と運用管理に直結します。
本記事では、19c 環境をベースに、ノードごとの管理が必要なコンポーネントと、共有すべき表領域の特徴、および運用上の注意事項をプロの視点で解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
結論：RAC コンポーネントの「共有」と「個別」リスト
Oracle RAC では、すべてのインスタンスが単一のデータベース（物理ファイル群）にアクセスしますが、書き込みの衝突を避けるために一部の領域がノード単位で分離されています。
- インスタンスごとに必要なもの（個別管理）:
- UNDO 表領域: 各インスタンスに専用の領域を割り当てる。
- REDO ログ・スレッド: 各インスタンス専用の REDO ロググループ。
- 全ノードで共通のもの（共有管理）:
- データ用表領域: SYSTEM, SYSAUX, およびユーザーデータ（DATA）。
- 制御ファイル: すべてのノードで同一のファイルを参照。
- 一時表領域（TEMP）: 共有が一般的（ノード別作成も可能だが稀）。
背景と基礎：なぜ UNDO と REDO は「個別」なのか？
用語の定義
- REDO ログ・スレッド: インスタンスが生成する変更履歴。RAC では「スレッド」という単位でノードごとに管理されます。
- UNDO 表領域: トランザクションのロールバックや読取り一貫性のために使用される領域です。
仕組みのポイント
複数のインスタンスが同じ領域に同時に書き込むと、排他制御（ラッチやロック）によるオーバーヘッドが激増します。これを防ぐため、書き込み頻度が高い UNDO と REDO は、あらかじめ各ノードの「専用席」として切り出されています。これを Oracle RAC 構成 の基本原則と呼びます。
実装・確認手順：RAC 固有の設定を確認する
前提条件
- OS: Oracle Linux 7/8 以上
- DB: Oracle Database 19c (EE)
- 権限:
SYSDBA権限を持つユーザー
1. UNDO 表領域の割り当て確認
各インスタンスがどの UNDO 表領域を使用しているかを確認します。前述の GV$PARAMETER では VALUE カラムを参照します。
-- 各インスタンスの UNDO 表領域設定を確認する
SELECT INST_ID, NAME, VALUE
FROM GV$PARAMETER
WHERE NAME = 'undo_tablespace'
ORDER BY INST_ID;
補足：INST_ID 1 は UNDOTBS1、INST_ID 2 は UNDOTBS2 のように個別に割り当たっている必要があります。
SQL> SELECT INST_ID, NAME, VALUE
2 FROM GV$PARAMETER
3 WHERE NAME = 'undo_tablespace'
4 ORDER BY INST_ID;
INST_ID NAME VALUE
---------- ------------------------------ --------------------
1 undo_tablespace UNDOTBS1
2 undo_tablespace UNDOTBS2
2. REDO ログ・スレッドの有効化状態
スレッドが各インスタンスに紐付いているか確認します。
-- スレッドごとのロググループ数とステータスを確認
SELECT THREAD#, GROUP#, BYTES/1024/1024 AS MB_SIZE, STATUS
FROM V$LOG
ORDER BY THREAD#;
補足：THREAD# 1（ノード1用）と THREAD# 2（ノード2用）がそれぞれ OPEN/CURRENT になっていることを確認します。
SQL> SELECT THREAD#, GROUP#, BYTES/1024/1024 AS MB_SIZE, STATUS
2 FROM V$LOG
3 ORDER BY THREAD#;
THREAD# GROUP# MB_SIZE STATUS
---------- ---------- ---------- ---------------------------
1 1 200 INACTIVE
1 2 200 CURRENT
2 3 200 CURRENT
2 4 200 INACTIVE
トラブルシューティング：よくある ORA-エラーと対処
RAC コンポーネントの設定不備により発生しやすいエラーをまとめました。
| エラーコード | 原因 | 確認・対処方法 |
| ORA-01555 | スナップショットが古すぎる（UNDO 不足） | 特定ノードの UNDO サイズを拡張するか UNDO_RETENTION を調整。 |
| ORA-01617 | スレッドの参照不可（マウント失敗） | インスタンス起動時、指定した THREAD パラメータが他で使われていないか確認。 |
| ORA-00312 | オンライン REDO ログの I/O エラー | 共有ストレージ（ASM等）のパスが全ノードから疎通可能か確認。 |
運用・監視・セキュリティ上の注意
注意事項：バックアップとリカバリ
RAC のコンポーネント配置において、最も注意すべきは「個別」の領域も「全ノードから物理的に見える」必要がある点です。
- インスタンス・リカバリのリスク: ノード1がダウンした際、生存しているノード2がノード1の REDO スレッドを読んでリカバリを代行します。そのため、ノード1の REDO ログがノード2から見えない（ローカルディスクにある等）と、DB全体が停止します。
- RMAN バックアップ: アーカイブ REDO ログも各ノードで生成されます。全ノードのログを 1 箇所に集約するか、全ノードのログ領域を共有マウントしてバックアップする必要があります。
FAQ：よくある質問
Q: 新しく 3 番目のノードを追加する際、何を用意すべきですか？
A: 新しい UNDO 表領域（例：UNDOTBS3）の作成と、新しい REDO スレッド（THREAD 3）の作成・有効化が必要です。
Q: DATA 表領域はノードごとに分ける必要はないのですか？
A: はい。データファイルは共通です。Cache Fusion 技術により、ノード間の整合性は自動で保たれます。
Q: 1 つのノードだけで非常に大きな UNDO を消費するバッチを動かしても大丈夫ですか？
A: そのノードに割り当てられた UNDO 表領域のサイズに依存します。ノード間で UNDO 領域を動的に融通することはできないため、重い処理を行うノードの UNDO は厚めに設計してください。
まとめ
- Oracle RAC 構成では、書き込み競合を避けるため REDO と UNDO をノードごとに分離する。
- データ用表領域や制御ファイルは全ノードで完全に「共有」管理される。
- すべてのコンポーネント（個別領域含む）は、全ノードからアクセス可能な共有ストレージ上に配置することが鉄則。
- ノード追加や障害復旧（インスタンス・リカバリ）の際は、他ノードのスレッド参照権限が成否を分ける。
本記事は Oracle Database 19c を対象に解説します（他バージョンは画面や既定値が異なる場合があります）。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント