Oracle RAC障害調査の極意：DB/ASM/CRSログ確認手順

Oracle RAC環境で障害が発生した際、迅速な原因特定には各層の適切なログ確認が不可欠です。本記事では、初中級者向けにOS、DB、ASM、CRSの具体的なログパスと、実務に直結する正確な調査手法を解説します。

Oracle RAC(Real Application Clusters) とは？仕組みとメリットを初心者向けに解説

「データベースが止まらない」仕組みとして Oracle RAC に興味をお持ちですか？RAC は複数サーバーで単一DBを稼働させ、可用性と拡張性を高める技術です。この記事では、RAC の基本的な仕組み、メリット、そして自分が接続している環境…

障害調査のやることリスト（結論・最短手順）
背景と基礎：Oracle RAC環境のログ階層
手順・実装：各アラートログのパス構成図
実行例：アラートログの実践的な抽出
代表的なORAエラーのトラブルシューティング
運用・監視・セキュリティ上の注意
Oracle RACのログ確認に関するFAQ
まとめ

障害調査のやることリスト（結論・最短手順）

ノード停止やインスタンスダウン時は、下位レイヤー（インフラ層）から上位レイヤー（データベース層）へ遡ってログを調査します。

OSログ確認: /var/log/messages でハードウェア障害やOOM-Killerを特定
CRSログ確認: grid ユーザーで alert.log と ocssd.trc のEviction（強制排除）を追跡
ASMアラートログ確認: grid ユーザーでディスクI/Oエラーを特定
DBアラートログ確認: oracle ユーザーでORAエラー等の内部エラーを調査
一括保全: 原因が複合的な場合は tfactl diagcollect で全ノードの情報を採取

背景と基礎：Oracle RAC環境のログ階層

Oracle Database 11g以降、ログの出力先は「ADR（自動診断リポジトリ）」に統合されています。12c以降はクラスタウェア（GI）のログもADR管理となり、すべて $ORACLE_BASE/diag 配下に出力されます。

【初心者向け一口メモ】

RAC環境では役割分散のため、クラスタ制御とストレージ（GI/ASM）を grid ユーザー、データベースを oracle ユーザーでインストールするのが標準です。そのため、ベースディレクトリ（$ORACLE_BASE）もOSユーザーごとに分かれています。

手順・実装：各アラートログのパス構成図

実際の環境（ノード名：v19rac1）を例に、具体的なディレクトリ構造を示します。

/u01/app/

├─ grid/ （※GI・ASM用ベース）

│ └─ diag/

│ ├─ crs/v19rac1/crs/trace/ 【①CRSログ：alert.log, ocssd.trc 等】

│ └─ asm/+asm/+ASM1/trace/ 【②ASMログ：alert_+ASM1.log 等】

│

└─ oracle/ （※DB用ベース）

└─ diag/

└─ rdbms/orcl/orcl1/trace/ 【③DBログ：alert_orcl1.log 等】

実行例：アラートログの実践的な抽出

OSコマンドおよびSQLを使用した具体的なログ確認手法です。直接のファイル参照とADRCIコマンドを使い分けます。

1. ASMアラートログの直接確認

grid ユーザーで権限と実ファイルを確認します。

# 実行ユーザー: grid
# 前提: 環境変数 ORACLE_BASE=/u01/app/grid が設定されていること

cd /u01/app/grid/diag/asm/+asm/+ASM1/trace
ls -l | grep alert
# 結果例: -rw-r-----. 1 grid oinstall  285745 Jul  5 11:56 alert_+ASM1.log

# 直近のエラーを確認（参照系操作のためシステム影響なし）
tail -n 50 alert_+ASM1.log

※ファイルの所有者が grid のため、oracle ユーザーでは閲覧できません。

Oracle RAC 構成における ASM 設計の要諦

Oracle RAC 構成において、ストレージの効率的な管理はシステムの安定性に直結します。本記事では、Oracle RAC のコンポーネントを最適に配置するために、DATA と RECO のように ASM ディスク・グループを分離すべき理…

2. CRSログディレクトリの確認

CRS層にはアラートログ以外にも多数のプロセスログが存在します。

# 実行ユーザー: grid
cd /u01/app/grid/diag/crs/v19rac1/crs/trace
ls alert.log ocssd.trc crsd.trc

※ ocssd.trc はノード間ハートビート、crsd.trc はリソース起動停止を記録する重要ファイルです。

3. ADRCIを利用した時系列抽出（推奨）

ディレクトリ階層を意識せず、指定日時のログを抽出します。

# 実行ユーザー: grid
adrci
# ADRCIプロンプト内
adrci> set home diag/crs/v19rac1/crs
# 特定日時のCRSアラートログを出力
adrci> show alert -time '2026-07-05 10:00:00' '2026-07-05 10:15:00'

4. SQLによるDBトレースパスの確認

現在接続しているDBインスタンスから、ログの出力パスを動的に特定します。

-- 実行ユーザー: oracle (SYSDBA等)
-- 前提: 対象プラガブル・データベースまたはCDB$ROOTに接続済
SELECT name, value FROM v$diag_info WHERE name = 'Diag Trace';
-- 実行結果例: /u01/app/oracle/diag/rdbms/orcl/orcl1/trace

※v$diag_infoビューを参照することで、環境変数に依存せず確実なパスを取得できます。

代表的なORAエラーのトラブルシューティング

障害事象	起点となるログ	対処順・確認内容
ORA-29740 (ノードEviction)	DB / CRSアラートログ	1. CRSの `ocssd.trc` でPing欠落を調査 2. OSログでネットワーク断の有無を確認
ORA-15080 (ディスクI/O失敗)	ASMアラートログ	1. ASMアラートログでOffline検知を確認 2. OS側でマルチパス/HBAのエラーを調査
リソース起動失敗	CRSアラートログ	1. `crsd_oraagent_*.trc` で起動失敗の原因を特定 2. 権限や依存リソースの設定ミスを確認

運用・監視・セキュリティ上の注意

TFA(AHF)による一括収集のメリット: 重大な障害が発生しOracleサポートへSRを起票する際は、手動収集ではなく tfactl diagcollect -since 4h でOS/CRS/ASM/DBのログを一括収集してください。これにより漏れを防げます。
ファイル直接削除の罠（リスク）: ディスク容量不足解消のために、OSの rm コマンドで *.trc や .trm ファイルを直接削除すると、ADRのメタデータが破損します。
正しい削除手順（戻し方）: ログを削除する場合は、必ず adrci コマンドから purge -age 10080（分指定: 約7日分）を実行し、安全にクリーンアップしてください。