RACインスタンスがダウン ― どのログを解析するのか

📚 連載：RAC障害のログ解析
1. RACインスタンスがダウン ― どのログを解析するのか（instance down 編・本記事）
2. RACのノードエビクション ― インターコネクトダウン（ネットワークハートビート断）はどのログを解析するのか（ネットワーク型 evict 編）
3. RACのノードエビクション ― 投票ディスク到達不可（ディスクハートビート断）はどのログを解析するのか（ディスク型 evict 編）

2ノードRAC の監視で、「インスタンス1がダウン」のアラートが発報しました。

このとき最初に切り分けたいのは、ノードがクラスタから切り離されたのか（node evict）、インスタンスだけが落ちたのか（instance down）です。
両者は原因も対処も、報告する内容もまったく異なります。
では、どのログのどの行を見れば区別できるのか。

この記事では、実機の2ノードRAC（19c）でインスタンス1を実際に停止させ、どのログのどこを見るべきかを一覧に整理します。
あわせて、「クラスタ層のログ（ocssd.trc）に出力があった＝node evict」「fence の文字が出た＝node evict」という2つの誤読しやすい点を実機ログで確認します。

1. シナリオ

2ノードRAC（node1 / node2）で、次の状況が起きています。

• 監視から「DBインスタンス1（node1側）がダウン」のアラートが発報した
• node1 に SSH はつながる（OSは稼働中）
• アプリケーションは node2 側で継続稼働している

ポイントは「node1 の OS が起動している」ことです。
ただし、OS が起動していても、node1 のクラスタウェア（Grid Infrastructure）が動き続けているとは限りません。
同じ「OS 起動・SSH 可」でも、クラスタウェアが動いたままインスタンスだけが落ちたのか、クラスタウェアごと切り離されたのかで、状況はまったく異なります。

つまり、「インスタンス1ダウン」の実体は次の2つに分かれます。

node evict でもインスタンスは止まるため、第一報はどちらも「インスタンスがダウン」に見えます。
次章では、この2つをログで見分けるための前提を整理します。

2. 前提の仕組み ― RACは「クラスタ層」と「DB層」の二階建て

RAC のログを読むには、まずどのプロセスがどの層に属し、何を管理しているかを押さえる必要があります。

上段が「上物」（DB層）・下段が「土台」（クラスタ層）。土台のクラスタ層（CSS→CRS）が先に立ち上がり、その上で DB インスタンスが動きます。

※ 各プロセス名の略語（CSS・CRS・LMON など）が何の頭文字なのかは、続編の node evict 編で分解して解説しています。

ポイントは、「ノードの生死」と「インスタンスの生死」は別の層で管理されていることです。

• node evict ＝ クラスタ層のイベント。CSS がノードをクラスタから切り離す
• instance down ＝ DB層のイベント。LMON が検知し、生存インスタンスでリソースを再構成する

この「再構成」が reconfiguration です。
reconfiguration は instance down 専用の処理ではなく、インスタンスの離脱・参加（起動）など、メンバー構成が変わるたびに走ります。
RAC はロックやキャッシュの管理情報（GRD：グローバルリソースディレクトリ）を全インスタンスの SGA に分担して保持しており、構成が変わればこの分担を組み直す必要があるためです。
今回のように1つが死んだ場合は、死んだインスタンスが受け持っていた管理情報を、生存インスタンスが引き取る再編成になります。
これを実行するのが DB 層の LMON です。

※ここでいう「リソース」は、crsctl stat res -t に出る ora.*（クラスタが管理するサービス）とは別物です。GRD が扱うのは、データブロックやロックといった DB 内部の管理単位です。同じ「リソース」という言葉でも、クラスタ層と DB 層で指すものが異なります。

つまり理屈の上では、instance down の記録は「DB層のログ（生存ノードのアラートログと LMON トレース）」に集中して現れるはずです。
本当にそうなるか、実機で確かめます。

3. 実機検証 ― コマンドとログを順に照合する

検証環境は Oracle Database 19c（19.28）の2ノードRAC。
DB名 rc19u、インスタンスは node1 側が rc19u1、node2 側が rc19u2 です。

node1 側で srvctl からインスタンス1を abort 停止し、直後に各ログを確認しました。

[grid@node1 ~]$ date; srvctl stop instance -d rc19u -i rc19u1 -o abort
2026年  7月  4日 土曜日 07:37:13 JST

以降、停止時刻 07:37:13 を基準に「どのログに・何秒後に・何が出たか」を見ていきます。

Step 1. まず全体のリソース状況を確認する（crsctl stat res -t）

最初に、クラスタが管理するリソースの状態を一覧で確認します。
crsctl stat res -t は Grid Infrastructure 配下の全リソース（DB・VIP・リスナーなど）のステータスをテーブル形式で出力できるため、初動はここからです。
出力が長くなるため、ここでは grep で DB リソース（ora.rc19u.db）だけに絞って表示します。

[grid@node1 ~]$ crsctl stat res -t | grep -A4 "ora.rc19u.db"
ora.rc19u.db
      1        OFFLINE OFFLINE                               Instance Shutdown,STABLE
      2        ONLINE  ONLINE       node2                    Open,HOME=/u01/app/o
                                                             racle/product/19.0.0

インスタンス1が OFFLINE（Instance Shutdown）、インスタンス2は ONLINE（Open）です。

※ ここでは grep で見出し行を省いていますが、各インスタンス行は左から Target（どうしたいか＝クラスタが目指す状態）・State（今どうなっているか＝実際の状態）・Server・State details の順です。ここで inst1 は Target=OFFLINE／State=OFFLINE。srvctl で意図的に停止したため、「止めたい（Target=OFFLINE）から止まっている（State=OFFLINE）」という一致した状態です。（対して次回の node evict では、止めていないのに落とされるため Target=ONLINE／State=OFFLINE の不一致になります。「止めた」か「落とされた」かが Target 列に表れます。）

実際の切り分けでは、crsctl stat res -t の全体出力で node1 上の他のリソース（VIP・リスナー・ASM など）が ONLINE のままかもあわせて確認します。
ノードごと落ちていれば、node1 上のリソースはまとめて OFFLINE などの異常状態になるため、「DB リソースだけが OFFLINE」なら instance down の可能性が高い、という最初の当たりが付きます。

Step 2. 落とした側（node1）の DBアラートログ ― 停止の実行元まで記録されている

次に、停止した側である node1 の DBアラートログを確認します。
停止の記録がどう残っているか（自然に落ちたのか、外部から止められたのか）を見るのが目的です。

[oracle@node1 ~]$ tail /u01/app/oracle/diag/rdbms/rc19u/rc19u1/trace/alert_rc19u1.log
2026-07-04T07:37:13.861266+09:00
Shutting down ORACLE instance (abort) (OS id: 18421)
Shutdown is initiated by oraagent.bin@node1 (TNS V1-V3).
USER (ospid: 18421): terminating the instance
Instance terminated by USER, pid = 18421
Instance shutdown complete (OS id: 18421)

Shutting down ORACLE instance (abort) と、インスタンスを強制停止した記録が残ります。

注目は次の行です。
Shutdown is initiated by oraagent.bin@node1 ― 停止の実行元まで記録されています。
srvctl で停止すると、実際にインスタンスを落とすのは Grid Infrastructure のエージェント（oraagent.bin）です。
障害調査で停止の実行元を追うとき、この行は運用操作（srvctl/クラスタ経由）と手動操作（sqlplus）を区別する手がかりになります。

Step 3. 生存ノード（node2）の DBアラートログ ― reconfiguration はここに出る（最重要）

次に、生存ノード（node2）の DBアラートログを確認します。
2章の整理どおりなら、instance down の記録が最も集中するはずのログです。
実機では、停止からわずか2秒後に一連の記録が出ていました。

[oracle@node2 ~]$ grep -B2 -A9 "Reconfiguration started" /u01/app/oracle/diag/rdbms/rc19u/rc19u2/trace/alert_rc19u2.log
2026-07-04T07:37:15.144886+09:00
Increasing priority of 1 RS
Reconfiguration started (old inc 4, new inc 6)
List of instances (total 1) :
 2
Dead instances (total 1) :
 1
My inst 2
publish big name space -  dead or down/up instance detected, invalidate domain 0
 Global Resource Directory frozen
* dead instance detected - domain 0 invalid = TRUE
* dead instance detected - domain 2 invalid = TRUE, need cdb-level instance recovery

注目する行の読み方は次のとおりです。

• Reconfiguration started … 再構成の開始
• List of instances (total 1) : 2 … 生存はインスタンス2のみ
• Dead instances (total 1) : 1 … 死んだのはインスタンス1
• Global Resource Directory frozen … GRD を凍結して再編成に入った

なお、Reconfiguration started (old inc 4, new inc 6) のインカネーション番号（inc、メンバー構成の世代番号）は、+1 ではなく +2 に進んでいます。
「reconfiguration のたびに +1」と説明されることが多いですが、実機では +1 とは限りません。
inc の差分から再構成の回数を数える読み方はできない、という点は押さえておきます。

同じアラートログの続きを見ていきます。
ここから、SMON によるインスタンスリカバリが始まります（関連行のみ抜粋）。

 Post SMON to start 1st pass IR
...
Instance recovery: looking for dead threads
Beginning instance recovery of 1 threads
Reconfiguration complete (total time 0.1 secs)
...
Completed instance recovery at
 Thread 1: RBA 105.4297.16, nab 4297, scn 0x000000000116ead4
SMON[INST-TXN-RECO]:about to recover undo segment 1 status:3 inst:1

このブロックで注目したいのは、行の順序です。
Beginning instance recovery of 1 threads が出た後に、Reconfiguration complete (total time 0.1 secs) が出ています。
つまり、インスタンスリカバリは reconfiguration の完了を待たずに始まっています。
再構成とリカバリは直列ではなく、重ねて進みます。

Step 4. 生存ノード（node2）の LMON トレース ― 再構成の実行記録

アラートログに出た reconfiguration を、実行元である LMON のトレースで裏取りします。

[oracle@node2 ~]$ grep -inE "Reconfiguration|rcfg time" /u01/app/oracle/diag/rdbms/rc19u/rc19u2/trace/rc19u2_lmon_8876.trc | tail -4
1365:* DOMAIN MAPPINGS after Reconfiguration :
1374:Reconfiguration complete (total time 0.1 secs)
1384:* kji_rbuddy_graph: (cinc 6, valid 0, rinst 2) [ t1'/i1 -> * * -> t2/i2(r) -> (t1/i1)  ]
1388: Total dlm rcfg time (inc 6): 0.095 secs (1053429, 1053524)

Total dlm rcfg time (inc 6): 0.095 secs ― 再構成が 0.095秒で完了した、という記録です。
dlm（Distributed Lock Manager）とは、2章で説明した GRD（ロック・キャッシュの管理情報）を扱う仕組みを指します。
つまりこの行は「死んだインスタンスが受け持っていた管理情報を引き取る再編成に 0.095 秒かかった」と読めます。
トレースには、担当の割り当てをどう付け直したか（DOMAIN MAPPINGS after Reconfiguration）まで、再構成の中身が残ります。

アラートログが「何が起きたか」の見出しなら、LMON トレースは「どう処理したか」の詳細記録です。
再構成が長引く・ハングするといった深い調査では、ここを読むことになります。

Step 5. 生存ノード（node2）の CRSアラートログ ― 誤読しやすい点その1：「fence」の文字

クラスタ層のログは、ノードごとに存在します（/u01/app/grid/diag/crs/<ホスト名>/crs/trace/ 配下）。
ここでは生存ノード（node2）の CRSアラートログを確認します。
この間に出ていたのはたった1行です。しかし、その1行が誤読を招きます。

[grid@node2 ~]$ tail /u01/app/grid/diag/crs/node2/crs/trace/alert.log
2026-07-04 07:37:20.792 [OCSSD(3325)]CRS-1735: Fence request issued for an entity node 1 with a timeout of 180000.

Fence request … node 1 ― この字面だけ見ると「node1 がフェンシングされた＝evict では？」と読みたくなります。

※ fence とは、誤動作の疑いがあるノードやプロセスを隔離し、共有ディスクへの書き込みを遮断してデータを守るクラスタの保護機構です。

しかし、この読み方が誤読です。
この CRS-1735 は、ノードを切り離す fence ではありません。
同時刻の ocssd.trc には GM層の clssgmpcFenceReq to node 1 が記録されており、fence の対象は「node1 上の死んだインスタンスに関連するプロセス」、つまりノードではなくメンバー（プロセス）レベルの fence です。
インスタンスリカバリ中に、死んだはずのプロセスが共有ディスクへ書き込んでデータを壊すことを防ぐI/O遮断です。

node1 自体はこの後もクラスタの管理下に残ります（次の Step で証明します）。
「fence＝evict」の早合点は禁物です。 instance down でも CRS-1735 は普通に出ます。

Step 6. 生存ノード（node2）の ocssd.trc ― 誤読しやすい点その2：「出たか」ではなく「どの層に出たか」（最重要）

最後がこの記事の最重要ポイントです。

検証前は「instance down なら ocssd.trc には何も出ないはず」という仮説を立てていました。
実機の答えは異なりました。ocssd.trc にも出力は出ます。ただし層が違う。

ocssd の出力は、関数名のプレフィックスで2つの層に分かれます。

停止時刻の直後（07:37:13〜07:37:14）の ocssd.trc を確認します。

[grid@node2 ~]$ grep "2026-07-04 07:37" /u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc | grep -iE "evict|removed|member|clssnmDoSyncUpdate|reconfig"
（関連行のみ抜粋）
2026-07-04 07:37:13.965 : CSSD: [INFO] clssgmCommonChangeMember: deadmbr found grock(IGRC19USYS$BACKGROUND), memberID 52:2:1:2, nodenum 1
2026-07-04 07:37:13.975 : CSSD: [INFO] clssgmCommonChangeMember: deadmbr found grock(GR+DB_RC19U), memberID 75:2:1:2, nodenum 1
2026-07-04 07:37:13.977 : CSSD: [INFO] clssgmRemoveMember: deadmbr found grock(IGRC19USYS$USERS), memberID 53:2:1:2, nodenum 1
2026-07-04 07:37:13.978 : CSSD: [INFO] clssgmRemoveMember: grock IGRC19USYS$BACKGROUND (0x7ffb5410ef00), member (0x7ffb3c0ca920), memberID 52:2:1 node number 1, state 0x1, member count 1
2026-07-04 07:37:13.982 : CSSD: [INFO] clssgmRemoveMember: grock GR+DB_RC19U, deathcnt 0
...

検索条件には、NM層に関わる語（evict・clssnmDoSyncUpdate）も含めてあります。
それでも、ヒットするのはすべて clssgm*（GM層）です。

ログには grock GR+DB_RC19U のように出ます。これは GR+DB_RC19U や IGRC19USYS$… といったDB rc19u 関連の「グループ」で、そこにインスタンス1のプロセスが登録されています。メンバー（プロセス）が消えると、GM層がそのグループから取り除きます（clssgmRemoveMember）。

やっていることは、死んだインスタンス1が所属していたグループ（GR+DB_RC19U や IGRC19U… ＝DB rc19u 関連）から、死んだメンバー（＝インスタンス1のプロセス）を取り除く処理です（deadmbr found → clssgmRemoveMember）。
インスタンスのプロセスが消えたのだから、グループのメンバー整理が走るのは当然です。

一方、NM層（clssnm*）は無反応です。
NM層のネットワークハートビート（ノード間の状態メッセージ）は、平常時から次の形で数秒おきに記録されています。

[grid@node2 ~]$ tail /u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc | grep clssnm
2026-07-04 07:32:49.201 : CSSD: [INFO] clssnmSendingThread: sending status msg to nodes: 1,2
2026-07-04 07:32:49.201 : CSSD: [INFO] clssnmSendingThread: sent 5 status msgs to nodes: 1,2

この sending status msg to nodes: 1,2（宛先に node1 を含む）は、停止後も変わらないまま続いていました。
node1 はクラスタの管理下に残り続けています。
evict 特有のメンバーシップ変更（clssnm* の同期・除名処理）は、停止の前後を通して1行も出ませんでした。

つまり、こう整理できます。

• 「ocssd.trc に何か出た＝evict」は誤り
• 正しくは 「NM層（clssnm*）に出たか」で判定する
• GM層（clssgm*）のグループ整理は、instance down でも普通に出る

4. instance down はどこを確認するか（一覧表）

今回の実機結果を、確認した順（本文の Step 番号）で一覧にまとめます。

5. よくある Q&A

Q1. instance down と node evict は、結局どこで見分けるのですか？
ocssd.trc の NM層（clssnm*）にメンバーシップ変更が出ているかどうかです。
出ていなければ instance down（DB層のイベント）、出ていれば node evict（クラスタ層のイベント）。
GM層（clssgm*）の出力や CRS-1735 は、どちらでも出るため判定材料になりません。

Q2. CRS-1735（Fence request）が出たら evict ですか？
いいえ。instance down でも出ます。
今回の CRS-1735 ... for an entity node 1 は、死んだインスタンスのプロセスによる共有ディスクへの書き込みを遮断する、メンバー（プロセス）レベルの fence です。
ノードの切り離し（evict）とは別物で、node1 はクラスタの管理下に残ったままでした。

Q3. reconfiguration とは何をしているのですか？
RAC はロック・キャッシュの管理情報（GRD）を全インスタンスで分担しています。
インスタンスが1つ死ぬと、そのインスタンスが受け持っていた管理情報を生存インスタンスへ引き継ぐ再編成が必要になります。
これが reconfiguration で、生存ノードの LMON が実行します。今回は0.1秒で完了しました。
なお、reconfiguration は離脱だけでなく参加でも走ります。実機でも、停止したインスタンス1を起動し直した際に Reconfiguration started (old inc 6, new inc 8) が記録されていました。

Q4. 死んだインスタンスの復旧処理は誰がやるのですか？
生存ノードの SMON です。
死んだインスタンスの REDO を読んで前進回復（インスタンスリカバリ）し、未確定トランザクションを UNDO で戻します。
落ちた node1 のインスタンスを再起動して行うのではなく、生存側が即座に代行します（シングル構成のクラッシュリカバリが次回起動時に行われるのとの違いです）。
実機ログでは、リカバリは reconfiguration の完了を待たずに始まっていました。

Q5. インカネーション番号（inc）は +1 ずつ増えるのでは？
前提として、inc はメンバー構成の世代番号です。
構成が変わるたびに進み、古い世代の構成を前提にした処理（死んだインスタンスが残したメッセージやロック要求）を無効と判断するために使われます。
実機では old inc 4, new inc 6 と +2 でした。
+1 とは限らないため、inc の差分から障害回数を推測する読み方はできません。
「番号が変わった＝メンバーシップが変わった」という事実だけを読み取ります。
なお、この inc は RMAN で扱う DB インカネーション（OPEN RESETLOGS で進む世代・V$DATABASE_INCARNATION）とは別物です。

6. まとめ

「インスタンス1ダウン」の第一報で見るべき場所は、次の順です。

「インスタンス1がダウン」のアラート
        │
        ▼  ① 全体のリソース状況を確認
  crsctl stat res -t
    ora.<db>.db だけ OFFLINE？ node1 側リソースは ONLINE のままか？
        │
        ▼  ② 生存ノードの DBアラートログ（最重要）
  Reconfiguration started/complete
  Dead instances (total 1)
  SMON のインスタンスリカバリ
    → 出ていれば「インスタンス構成の変化」をDB層が検知・処理済み（どちらの実体かは③で確定）
        │
        ▼  ③ ocssd.trc を「層」で読む（evict との切り分け）
  clssnm*（NM層）にメンバーシップ変更なし → instance down で確定
  clssnm* にメンバーシップ変更の記録あり → node evict（クラスタ層の調査へ）
        │
        ▼  補足
  CRS-1735（fence）は instance down でも出る。evict の証拠にならない
  落ちた側アラートログの「Shutdown is initiated by ...」で実行元を確認

押さえておくポイントは2つです。

1. instance down の記録が集中するのは「生存ノードの DBアラートログ」。Reconfiguration と Dead instances が、今回はダウンの2秒後に記録されていました。
2. ocssd.trc は「出たか」でなく「どの層（clssnm / clssgm）に出たか」で読む。fence の文字で誤読しない。

次回は、この対になる node evict（ハートビート喪失によるノードの切り離し）を同じ環境で再現し、今回は無反応だった NM層（clssnm*）に何が出るかを確認します。
instance down との差分がそろうことで、切り分けの基準が完成します。