RACのノードエビクション ― 投票ディスク到達不可（ディスクハートビート断）はどのログを解析するのか

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

前回（ネットワーク型 evict 編）は、インターコネクト断による node evict を再現しました。
生存ノードの CRSアラートログに CRS-1612 → 1611 → 1610（50% → 75% → 90%）のカウントダウンが刻まれ、30秒（misscount）で切り離しが確定する流れを、実機で確認しました。

そのとき「node evict にはもう1つのきっかけがある」として次回に回したのが、投票ディスクに到達できなくなるディスクハートビート断です。
今回はこのディスク型を、同じ2ノードRAC で再現します。

結論を先に1つだけ。
同じ node evict でも、今回はカウントダウンが出るノードが前回と逆でした。
前回は「生存側」のログに切り離しの一部始終が出ましたが、今回は「切り離される側」のログに出ます。
どちらのノードの CRSアラートログにカウントダウンが出ているか。これがネットワーク型とディスク型を見分けるポイントになります。

1. シナリオ

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

• 監視から「DBインスタンス2（node2側）がダウン」のアラートが発報した
• 第一報の見え方は、instance down 編・ネットワーク型 evict 編と同じである
• ただし今回の実体は、node2 から共有ストレージ（投票ディスクを含む LUN）への I/O が失われたことによる node evict である

第一報だけでは instance down か、node evict か、evict だとしてもネットワーク型かディスク型か、区別できません。
だからこそ、ログのどこを見て切り分けるかが問題になります。

今回は node2 で、投票ディスクを含む共有ディスク（/dev/sdb）を OS からオフラインにして、この障害を再現しました。
物理的なケーブル断・ストレージ側の障害・マルチパス全滅などで「そのノードだけ共有ディスクに届かなくなった」状況に相当します。

※ /dev/sdb は本検証環境のデバイス名です。実環境では ASM ディスクやマルチパスデバイス等で名前は異なります。

2. 前提の仕組み ― 2本のハートビートと、2つのタイマー

前回、CSS（ocssd）のネットワークハートビートは「インターコネクトを流れる生存確認」だと説明しました。
実は CSS の生存確認は、ネットワークだけではありません。

CSS は各ノードで、投票ディスク（voting disk）への定期的な I/O も行っています。
投票ディスクとは、どのノードがクラスタに属しているか（メンバーシップ）の情報を記録する共有ディスクです。
各ノードは自分の生存情報を投票ディスクへ書き込み、他ノードの生存情報を読み取る。
これがディスクハートビートです。

つまり各ノードは、常に2本のハートビートを打っています。

misscount・disktimeout は、いずれも Grid Infrastructure（CSS）側のパラメータです（DB の初期化パラメータではありません）。
デフォルト値は crsctl で確認できます。

[grid@node1 ~]$ crsctl get css misscount
CRS-4678: Successful get misscount 30 for Cluster Synchronization Services.
[grid@node1 ~]$ crsctl get css disktimeout
CRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services.

注目したいのは、タイマーの長さが大きく異なることです。
ネットワーク断は30秒で切り離しに至りますが、ディスク到達不可は200秒（3分20秒）待ってからです。

この差は、失ったときの危険度の違いから説明がつきます。
インターコネクトは、前回見たとおり、キャッシュフュージョン（インスタンス間のデータブロック転送）とノード間の調整を運ぶ経路です。
これが途絶えたノードとは、データブロックのやり取りも調整もできません。放置すればデータベースの整合性に直結するため、30秒で早く決着させます。
一方、投票ディスクに届かなくなっても、ネットワークハートビートが続いていればノード間の連携は保たれています。
加えて、ストレージへの I/O は、経路の切替（マルチパスのフェイルオーバなど）に数十秒かかることが構成上ありえます。
急いで切り離すと、一時的な遅延を「到達不可」と誤検知して健全なノードを止めかねません。だから長い猶予がデフォルトになっています。
この差は、あとで実機のタイムラインにそのまま表れます。

なぜ投票ディスクを失うと、クラスタに残れないのか

投票ディスクの役割は、生存情報の記録だけではありません。
ノード間の通信が失われたときに「どのノードをクラスタに残すか」を決めるためにも使われます。
前回のネットワーク型で、生存側が切り離しの実行として kill block を書き込んだ先も、この投票ディスクでした。

生存情報の記録と「どのノードを残すか」の決定がここに集まっているため、投票ディスクへ到達できないノードは、他ノードの状態を確認することも、この決定に加わることもできません。
その状態のまま共有データへの書き込みを続ければ、データベースの整合性を壊しかねません。
だから、投票ディスクへ到達できなくなったノードは、クラスタに残れない設計になっています（複数本の冗長構成では、過半数へ到達できなくなった場合）。
ディスクハートビート断が node evict に直結するのは、このためです。

投票ディスクはどこにあるか ― 配置が影響範囲を決める

もう1つ、今回の検証結果を読むうえで欠かせない前提が、投票ディスクの配置です。

[grid@node1 ~]$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   5f60f841b80e4fa8bfca8d7b9e419f0b (/dev/sdb) [DATA]
Located 1 voting disk(s).

本環境の投票ディスクは、DATA ディスクグループの中にあります（/dev/sdb 1本構成）。
そして本環境では、この DATA ディスクグループにデータファイル・制御ファイル・spfile などの DBファイル一式も置いています（構築時の配置です）。

[grid@node1 ~]$ srvctl config database -d rc19u
（関連行のみ抜粋）
spfile: +DATA/RC19U/PARAMETERFILE/spfile.278.1232278615
ディスク・グループ: RECO,DATA

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
+DATA/RC19U/DATAFILE/system.263.1232276775
+DATA/RC19U/DATAFILE/sysaux.264.1232276811
+DATA/RC19U/DATAFILE/undotbs1.265.1232276837
...（13本すべて +DATA）

投票ディスクは ASM ディスクグループ内に置くのが 11gR2 以降の標準的な構成で、専用のディスクグループを分ける構成と、データと同居させる構成があります。

この配置が意味するのは、「この LUN を失う＝投票ディスクとデータファイルを同時に失う」ということです。
つまり本検証で再現する障害は、クラスタ層（ディスクハートビート）と DB層（データファイルへの I/O）の両方に同時に効きます。
どちらの層が、どの順番で、どのログに記録を残すのか。ここが今回の観測ポイントです。

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

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

node2 で共有ディスク /dev/sdb を OS からオフラインにし、node2 が切り離される様子を観測しました。

まず、書き換え前の正常な状態を確認しておきます（関連行のみ抜粋）。

[grid@node1 ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
...
ora.rc19u.db
      1        ONLINE  ONLINE       node1                    Open,STABLE
      2        ONLINE  ONLINE       node2                    Open,STABLE
...
ora.node2.vip
      1        ONLINE  ONLINE       node2                    STABLE

※ 本記事の crsctl stat res -t の抜粋では、State details に表示される HOME=...（Oracleホームのパス）の表記を省略しています。

インスタンス2は node2 で Open、node2 の VIP も node2 で稼働しています。
この状態から障害を再現します。

[root@node2 ~]# date
2026年  7月 18日 土曜日 07:50:49 JST
[root@node2 ~]# echo offline > /sys/block/sdb/device/state
[root@node2 ~]# cat /sys/block/sdb/device/state
offline
[root@node2 ~]# date
2026年  7月 18日 土曜日 07:51:56 JST
[root@node2 ~]# dd if=/dev/sdb of=/dev/null bs=512 count=1 iflag=direct
dd: '/dev/sdb' を開けませんでした: そのようなデバイスやアドレスはありません

dd の直接読み取りが「デバイスが存在しない」で失敗し、node2 から /dev/sdb への I/O が失われたことを確認できました。

※ /sys/block/<デバイス>/device/state は、カーネルが公開している SCSI デバイスの状態属性です。
offline を書き込むと、以降そのデバイスへの I/O は即座にエラーで返るようになり、running を書き戻せば元に戻ります（復旧は Step 7）。
デバイス自体やストレージ側には変更を加えないため、障害の再現手段として使っています。

ここからは、時刻を軸に各ログを見ていきます。
書き換えの実施時刻は、前後の date のとおり 07:50:49〜07:51:56 の間です。
起点は、この間に CSS が最初の I/O エラーを検知した 07:51:38 です（Step 2 の最初の記録として出てきます）。
以降、「どのログに・何秒後に・何が出たか」をこの起点からの経過で追います。

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

最初に、生存ノード（node1）からクラスタ全体のリソース状態を確認します（切り離し確定後の出力・関連行のみ抜粋）。

[grid@node1 ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
...
ora.rc19u.db
      1        ONLINE  ONLINE       node1                    Open,STABLE
      2        ONLINE  OFFLINE                               Instance Shutdown,ST
                                                             ABLE
...
ora.node2.vip
      1        ONLINE  INTERMEDIATE node1                    FAILED OVER,STABLE

インスタンス2が Target=ONLINE／State=OFFLINE（動かしたいのに落ちている）、そして node2 の VIP が node1 へフェイルオーバ。
前回のネットワーク型 evict と同じ見た目です。

つまり crsctl stat res -t で分かるのは「instance down ではなく node evict らしい」ところまで。
ネットワーク型かディスク型かは、ここでは区別できません。
切り分けを進めるには、CRSアラートログを確認します。

Step 2. 切り離される側（node2）の CRSアラートログ ― カウントダウンはここに出る（最重要）

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

前回のネットワーク型では、カウントダウン（CRS-1612 → 1611 → 1610）は生存側 node1 の CRSアラートログに出ました。
今回、生存側の CRSアラートログにカウントダウンは1行も出ません（Step 4 で確認します）。
出るのは、投票ディスクに到達できなくなった node2 側です。

[grid@node2 ~]$ grep -E "^2026-07-18 07:5[1-5]" /u01/app/grid/diag/crs/node2/crs/trace/alert.log
（関連行のみ抜粋）
2026-07-18 07:51:38.680 [OCSSD(3382)]CRS-1649: 投票ファイルでI/Oエラーが発生しました: /dev/sdb。詳細は(:CSSNM00059:)(/u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc)を参照してください。
2026-07-18 07:53:17.696 [OCSSD(3382)]CRS-1615: 間隔上限の50%以降に完了したI/Oがありません。この状態が続く場合、投票ファイル/dev/sdbは99990ミリ秒間機能しないとみなされます。
2026-07-18 07:54:07.704 [OCSSD(3382)]CRS-1614: 間隔上限の75%以降に完了したI/Oがありません。この状態が続く場合、投票ファイル/dev/sdbは49980ミリ秒間機能しないとみなされます。
2026-07-18 07:54:37.709 [OCSSD(3382)]CRS-1613: 間隔上限の90%以降に完了したI/Oがありません。この状態が続く場合、投票ファイル/dev/sdbは19970ミリ秒間機能しないとみなされます。
2026-07-18 07:54:57.712 [OCSSD(3382)]CRS-1604: CSSD投票ファイルがオフラインです: /dev/sdb。詳細は(:CSSNM00058:)(/u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc)を参照してください。
2026-07-18 07:54:57.713 [OCSSD(3382)]CRS-1606: 使用可能な投票ファイル数0は必要な投票ファイル数の下限を下回っています。CSSD中断の結果、1によりデータの整合性が保たれます。詳細は(:CSSNM00018:)(/u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc)を参照してください

メッセージに書かれていない部分だけ補足します。

• CRS-1649（07:51:38）… 最初の I/O エラー検知。ここがカウントの開始点です
• CRS-1615 → 1614 → 1613 … disktimeout（200秒）の 50%・75%・90% に達した時点で出るカウントダウンです。文中の 99990 → 49980 → 19970 ミリ秒は、投票ファイルが機能不全と判定されるまでの残り時間（残り約100秒 → 50秒 → 20秒）
• CRS-1604（07:54:57）… 検知から 199秒後＝I/O が完了しないまま disktimeout（200秒）に達したタイミングです
• CRS-1606 … 日本語メッセージの語順がやや読みにくいですが、意味は「使用可能な投票ファイル数（0）が、必要な最小数（1）を下回った」。CSS はここで自らの停止を決定します

このカウントダウンを、前回のネットワーク型のものと並べると対応関係が見えてきます。
どちらの型も、メッセージが出るのはタイマーの 50%・75%・90% に達した時点の計3回です。

同じ 50/75/90% の3段が、番号帯とタイマーを変えて、逆側のノードに現れている、という対応です。

出るノードが逆になる理由は、その異常をどちらのノードが検知できるかにあります。
ネットワークハートビートは相手ノードへ送り届けるものなので、途絶を検知するのは受け取れなくなった相手側（生存側）です。だから生存側が misscount のタイマーを回し、生存側のログにカウントダウンが残ります。
一方、ディスクハートビートは自分自身が投票ディスクへ書き込むものなので、書けなくなったことを検知できるのは書いている本人です。だから本人が disktimeout のタイマーを回し、本人＝切り離される側のログにカウントダウンが残ります。
しかも今回、node2 のネットワークハートビートは途絶えていません。生存側には異常を検知するきっかけ自体がないのです（Step 4 で確認します）。

そして CRS-1606 の直後、CSS は自ら停止します。

[grid@node2 ~]$ grep -E "CRS-1656|CRS-8503" /u01/app/grid/diag/crs/node2/crs/trace/alert.log
（関連行のみ抜粋）
2026-07-18 07:54:57.716 [OCSSD(3382)]CRS-1656: 致命的なエラーのためCSSデーモンを停止中です。詳細は(:CSSSC00012:)(/u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc)を参照してください
2026-07-18 07:55:01.919 [OCSSD(3382)]CRS-8503: Oracle ClusterwareプロセスOCSSD (オペレーティング・システム・プロセスID 3382)で致命的な信号または例外コード6が発生しました。

CRS-1656 に続いて CRS-8503。例外コード6は SIGABRT（プロセスの即時終了シグナル）で、CSS が自らを強制終了したことを示します。
前回、切り離される側の自己停止は CRS-1609（他ノードと通信できないため停止）でした。
今回は CRS-1606（投票ファイルが最小数を下回ったため停止）です。
同じ「自己停止」でも、理由コードが失ったものを示しています。

Step 3. 切り離される側（node2）の ocssd.trc ― 投票ファイルを開けない記録

ocssd.trc にも、投票ディスクへ到達できない記録が残っています（関連行のみ抜粋）。

[grid@node2 ~]$ grep -nE "clssnmvDiskOpen|SKGFD|clssnmvGetDiskHandle" /u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc
（関連行のみ抜粋）
323028:2026-07-18 07:55:00.708 :    CSSD:588756736: [     INFO] clssnmvDiskOpen: Opening /dev/sdb
323029:2026-07-18 07:55:00.708 :   SKGFD:588756736: ERROR: -9(Error 27041, OS Error (Linux-x86_64 Error: 6: No such device or address
323032:2026-07-18 07:55:00.708 :    CSSD:588756736: [    ERROR] clssnmvGetDiskHandle: Unable to open disk /dev/sdb
323033:2026-07-18 07:55:00.708 :    CSSD:588756736: [    ERROR] clssnmvDiskOpen:failed to open /dev/sdb

clssnmv（NM層のディスク系関数）が /dev/sdb を開こうとして、OS エラー 6（No such device or address）で失敗し続けています。
障害を再現した直後の dd で見たエラー「そのようなデバイスやアドレスはありません」も、実は同じ OS エラー 6 の日本語メッセージです。
あのとき dd が受け取ったのと同じエラーを、CSS 自身も受け取っていたことが分かります。

Step 4. 生存側（node1）は何も関与していない ― 前回との決定的な差

次に、生存ノード（node1）側を見ます。
前回のネットワーク型では、カウントダウンも、切り離しの確定も、kill block の書き込みも、すべて生存側の動作でした。

今回、障害の時間帯（07:51〜07:55）に node1 の CRSアラートログへ出た記録は、次の6行がすべてです。

[grid@node1 ~]$ grep -E "^2026-07-18 07:5[1-5]" /u01/app/grid/diag/crs/node1/crs/trace/alert.log
2026-07-18 07:51:45.488 [CRSD(5443)]CRS-2878: リソース'ora.rc19u.db'の再起動に失敗しました
2026-07-18 07:51:45.499 [CRSD(5443)]CRS-2769: リソースora.rc19u.dbをフェイルオーバーできません。
2026-07-18 07:55:01.707 [OCSSD(3304)]CRS-1625: ノードnode2、番号2が停止されました
2026-07-18 07:55:01.836 [OCSSD(3304)]CRS-1601: CSSDの再構成が完了しました。アクティブ・ノードはnode1 です。
2026-07-18 07:55:01.865 [CRSD(5443)]CRS-5504: ノード'node2'について、ノード・ダウン・イベントが報告されました。
2026-07-18 07:55:06.064 [CRSD(5443)]CRS-2773: サーバー'node2'はプール'Generic'から削除されました。

6行の内訳は、次の2グループです。

カウントダウンはありません。
CRS-1612 系も CRS-1615 系も、1行も出ていません。
node2 の CSS が停止した 07:55:01 に、離脱の報告（CRS-1625）がいきなり出るだけです。

ocssd.trc 側でも確認します。
前回、切り離しの実行として出ていた関数（clssnmrEvictNode・clssnmvDiskEvict＝kill block 書き込み）を、障害時間帯（07:51〜07:55）に絞って検索すると――

[grid@node1 ~]$ grep "2026-07-18 07:5" /u01/app/grid/diag/crs/node1/crs/trace/ocssd.trc | grep -E "EvictNode|DiskEvict|kill block"
（ヒットなし）

1行もヒットしません。つまり今回は、kill block は書かれていません。

理由は仕組みから説明がつきます。

kill block は「生存側が投票ディスクに書き、切り離される側が読んで止まる」仕組みでした。
しかし今回の node2 は、その投票ディスク自体を読めません。読めない相手に書いても届きません。
だからディスク型では生存側からの切り離しが成立せず、Step 2 で見た「本人が disktimeout を数えて自ら停止する」形だけが残ります。

前回と今回で、切り離しの主体が入れ替わったことになります。
この対比は、後述の「ネットワーク型とディスク型の比較」で観測点ごとに整理します。

Step 5. DB層 ― 停止は二段階で起きていた

ここまでクラスタ層（CSS）の 200 秒を追ってきましたが、実は DBインスタンス2は、CSS の自己停止よりずっと早く停止していました。
node2 の DBアラートログを見ます（関連行のみ抜粋）。

[oracle@node2 ~]$ sed -n '/^2026-07-18T07:51:3/,/^2026-07-18T07:51:43/p' /u01/app/oracle/diag/rdbms/rc19u/rc19u2/trace/alert_rc19u2.log
（関連行のみ抜粋）
2026-07-18T07:51:39.283101+09:00
Errors in file /u01/app/oracle/diag/rdbms/rc19u/rc19u2/trace/rc19u2_ckpt_30414.trc:
ORA-00221: 制御ファイルへの書込みでエラーが発生しました
ORA-00206: 制御ファイルの書込み(ブロック4、#ブロック1)でエラーが発生しました
ORA-00202: 制御ファイル: '+DATA/RC19U/CONTROLFILE/current.267.1232276879'
ORA-15081: ディスクに対するI/O操作の発行に失敗しました
ORA-15081: ディスクに対するI/O操作の発行に失敗しました
...
CKPT (ospid: 30414): terminating the instance due to ORA error 221
...
2026-07-18T07:51:42.556318+09:00
Instance terminated by CKPT, pid = 30414

時刻は 07:51:39〜07:51:42。
CSS の I/O エラー検知（07:51:38）とほぼ同時、CSS の自己停止（07:54:57）より3分以上早いタイミングです。

原因は「投票ディスクはどこにあるか」で確認した配置です。
本環境は投票ディスクとデータファイルが同じ DATA ディスクグループに同居しているため、/dev/sdb を失った瞬間、制御ファイル（+DATA 上）への書き込みも失敗しました。
CKPT（チェックポイントプロセス）は制御ファイルに書けないと動作を続けられないため、ORA-221 を理由にインスタンスを停止しています。

さらに、node2 の CRSアラートログには、もう1つ記録が残っていました。
インスタンス停止の3秒後、クラスタがインスタンスの自動再起動を試みて、失敗しています。

[grid@node2 ~]$ grep -A2 "CRS-5017" /u01/app/grid/diag/crs/node2/crs/trace/alert.log
（関連行のみ抜粋）
2026-07-18 07:51:45.443 [ORAAGENT(63452)]CRS-5017: リソース・アクション"ora.rc19u.db start"に次のエラーが発生しました:
2026-07-18 07:51:45.443+ORA-01078: failure in processing system parameters
LRM-00109: （文字化けのため省略）'/u01/app/oracle/product/19.0.0/dbhome_1/dbs/initrc19u2.ora'（文字化けのため省略）

※ LRM-00109 の日本語メッセージ部分は、本環境ではログ上で文字化けして記録されていたため省略しています。LRM-00109 は「パラメータファイルを開けなかった」ことを示すエラーです。

Step 1 で確認したとおり、インスタンス2は Target=ONLINE のままです。そのため、クラスタは停止を検知するとすぐ再起動を試みます。
しかし、本環境の spfile は失われた DATA ディスクグループの中にあります（「投票ディスクはどこにあるか」で確認したとおりです）。
ログには、デフォルトの場所のパラメータファイル（initrc19u2.ora）も開けず、起動に失敗した記録が残りました（ORA-01078／LRM-00109）。
ディスクグループを丸ごと失うと、「再起動すればよい」も通用しなくなることが分かります。

つまり今回の障害では、node2 の停止は二段階で起きています。

07:51:38  /dev/sdb への I/O 喪失
   │
   ├─ DB層    ： 制御ファイルに書けない → CKPT がインスタンスを停止（07:51:42）　※数秒
   │
   └─ クラスタ層： 投票ディスクに書けない → disktimeout（200秒）を超えたところで
                  CSS が自己停止（07:54:57〜07:55:01）　※3分19秒

同じディスク喪失でも、層によってタイマーが異なるためです。
DB層は書き込みエラーの発生とともに停止し、クラスタ層は 200秒（disktimeout）を超えてから停止します。

ここで、連載3記事の「落ちた側の DBアラートログ」を並べると、切り分けに使える差が見えてきます。

Instance terminated by の後ろの主体が、3記事すべてで異なります。
USER なら意図的な停止、PMON（＋ORA-29740）なら evict による除去、CKPT（＋制御ファイルの I/O エラー）ならストレージ障害。
この1行が、インスタンスがどう停止したかを示す出発点になります。

なお、生存側（node1）の DBアラートログは今回も Reconfiguration started → インスタンスリカバリの流れで、instance down・ネットワーク型 evict と構造は同じでした（07:51:43 完了・所要 0.2 秒）。
3回連続で確認したとおり、生存側の DB 再構成ログは切り分けに使えません。

Step 6. 切り離された node2 はどうなっているか ― STATE_DETAILS が状況を示す

前回と同じく、切り離しは Reboot-less です（OS は再起動していません）。
ohasd は動き続け、停止した CSS を再起動しようとします。
その様子を crsctl stat res -t -init（土台プロセス群のビュー）で見ます（関連行のみ抜粋）。

[grid@node2 ~]$ crsctl stat res -t -init
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
ora.cssd
      1        ONLINE  OFFLINE      node2                    VOTING FILES FAILURE
                                                             ,STARTING
ora.crsd
      1        ONLINE  OFFLINE                               STABLE
ora.gipcd
      1        ONLINE  ONLINE       node2                    STABLE
ora.gpnpd
      1        ONLINE  ONLINE       node2                    STABLE

ora.cssd の State details は VOTING FILES FAILURE,STARTING。
前回のネットワーク型では、同じ場所が INTERCONNECT FAILURE,STARTING でした。

何を失って復帰できずにいるのかを、STATE_DETAILS の文言から読み取れます。
切り分けの最後の答え合わせとして使える1行です。

再起動された CSS の動きも見ておきます。
再起動が実際に起きたことは、プロセスID からも分かります。
CRSアラートログの行頭にある [OCSSD(3382)] の括弧内の数字は OS のプロセスIDで、CRS-8503 のメッセージ本文にも「オペレーティング・システム・プロセスID 3382」と明記されていました。
Step 2 の引用では 3382、このあとの引用では 66508。IDが変わっている＝停止後に別プロセスとして起動し直されたということです。

[grid@node2 ~]$ grep -n "CSSNM00070" /u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc | head -3
324140:2026-07-18 07:55:04.772 :    CSSD:926906112: [     INFO] (:CSSNM00070:)clssnmCompleteInitVFDiscovery: Voting file not found. Retrying discovery in 15 seconds
324213:2026-07-18 07:55:19.784 :    CSSD:926906112: [     INFO] (:CSSNM00070:)clssnmCompleteInitVFDiscovery: Voting file not found. Retrying discovery in 15 seconds
324273:2026-07-18 07:55:34.795 :    CSSD:926906112: [     INFO] (:CSSNM00070:)clssnmCompleteInitVFDiscovery: Voting file not found. Retrying discovery in 15 seconds

再起動した CSS は、15秒間隔で投票ファイルの探索を繰り返します。
実機では、この探索が見つからないまま10分（600秒）続いたところで CSS はいったん停止し、ohasd の管理下でまた起動し直されました。

[grid@node2 ~]$ grep -E "CRS-1656|CRS-8503" /u01/app/grid/diag/crs/node2/crs/trace/alert.log | tail -2
2026-07-18 08:05:04.547 [OCSSD(66508)]CRS-1656: 致命的なエラーのためCSSデーモンを停止中です。詳細は(:CSSSC00012:)(/u01/app/grid/diag/crs/node2/crs/trace/ocssd.trc)を参照してください
2026-07-18 08:05:04.554 [OCSSD(66508)]CRS-8503: Oracle ClusterwareプロセスOCSSD (オペレーティング・システム・プロセスID 66508)で致命的な信号または例外コード6が発生しました。

再起動後の CSS（プロセスID 66508）が 07:55:04 に探索を開始し、08:05:04 に停止＝ちょうど600秒です。

この600秒には設定上の裏付けがあります。本環境の ora.cssd リソースは、起動タイムアウト（START_TIMEOUT）が600秒です。

[grid@node1 ~]$ crsctl stat res ora.cssd -init -f | grep START_TIMEOUT
START_TIMEOUT=600

STARTING のまま600秒に達したため、起動が打ち切られた、と読めます。
つまり node2 は、次のサイクルに入っています。

CSS 起動（ohasd の管理下）
   │
   ▼
投票ファイルを探索（15秒間隔・CSSNM00070）
   │  600秒（40周）探しても見つからない
   ▼
CSS 停止（CRS-1656 → CRS-8503）
   │
   └─ ohasd が CSS を再起動 →（先頭に戻る・ディスクが戻るまで繰り返し）

Step 7. 復旧 ― ディスクが戻れば、あとは全自動

復旧の第一手は、失われたディスクを戻すことです。
本検証では OS のデバイス状態を戻します（実障害では、ストレージ・経路の復旧に相当します）。

[root@node2 ~]# echo running > /sys/block/sdb/device/state
[root@node2 ~]# dd if=/dev/sdb of=/dev/null bs=512 count=1 iflag=direct
1+0 レコード入力
1+0 レコード出力
512 bytes copied, 0.00101207 s, 506 kB/s

/dev/sdb が読めるようになりました。
このあと、手動の操作は一切していません。

Step 6 の 15秒間隔の探索が次の周回で投票ファイルを発見し、CSS が初期化を完了してクラスタへ再参加。
CRS・ASM が順に起動し、インスタンス2も自動起動しました。
デバイス復旧（08:14:24）から約3分後には、全リソースが両ノードで ONLINE に戻っています。

[grid@node1 ~]$ crsctl stat res -t
--------------------------------------------------------------------------------
Name           Target  State        Server                   State details
--------------------------------------------------------------------------------
...
ora.rc19u.db
      1        ONLINE  ONLINE       node1                    Open,STABLE
      2        ONLINE  ONLINE       node2                    Open,STABLE
...
ora.node2.vip
      1        ONLINE  ONLINE       node2                    STABLE

インスタンス2が自動で戻ったのは、前回と同じ理由です。
Step 1 で見たとおり Target=ONLINE のままだったので、クラスタは node2 が復帰したと同時に起動を試み、Open まで戻しました。

前回のネットワーク型では、復旧時に nmcli device reapply という OS 側のひと手間が必要でした（経路が消えていたため）。
今回のディスク型は、ディスクを戻しただけで、すべて自動で起動してきました。
15秒間隔で探索し続ける再起動サイクル（Step 6）が、そのまま自動復旧の仕組みとして働きました。

4. ネットワーク型とディスク型の比較 ― どこで見分けるか

前回と今回を、観測点ごとに並べます。

端的にいうと、こうです。

ネットワーク型は「生存側が切り離す」障害。ディスク型は「切り離される側が自ら停止する」障害。
だからカウントダウンも切り離しの記録も、ネットワーク型は生存側に、ディスク型は切り離される側に残る。

5. よくある Q&A

Q1. なぜディスク型のタイマー（disktimeout=200秒）はネットワーク型（misscount=30秒）より長いのですか？
ストレージへの I/O は、経路の切替（マルチパスのフェイルオーバ等）で一時的に応答が遅れることがあるためです。
短くしすぎると、一時的な遅延を「到達不可」と誤検知して健全なノードを止めてしまいます。
なお、これらの値は変更できますが、Oracle は原則デフォルト値の使用を推奨しています。

Q2. 200秒の間、DB は動き続けるのですか？
配置によります。
本環境のように投票ディスクがデータファイルと同じディスクグループに同居していると、DB は I/O エラーで数秒のうちに停止します（Step 5）。
投票ディスク専用のディスクグループを分けた構成で、そちらだけが到達不可になった場合は挙動が変わりますが、本記事ではその構成は検証していません。

Q3. kill block はなぜ書かれないのですか？
kill block は「切り離される側が投票ディスクから読む」ことで機能します。
今回はその投票ディスク自体に切り離される側が到達できないため、書いても読まれません。
そのためディスク型では、投票ディスクを失った状態が disktimeout を超えると、ノードが自ら停止する設計になっています（CRS-1606）。

Q4. 生存側のログしか見られない場合、ディスク型と判断できますか？
生存側だけでは「カウントダウンなしで、いきなり CRS-1625（ノード停止の報告）が出る」ことまでしか分かりません。
ネットワーク型なら生存側にカウントダウンが出るので、「生存側にカウントダウンがないのにノードが抜けた」場合は、ディスク型を含む「切り離される側の自己停止」をまず疑います。
確定するには、切り離された側の CRSアラート（CRS-1615 系・CRS-1606）か、-init の VOTING FILES FAILURE を確認します。

Q5. 投票ディスクが1本だけなのは普通ですか？
本検証環境は最小構成（外部冗長〈EXTERNAL REDUNDANCY〉・1本）です。
実環境では、通常冗長（NORMAL REDUNDANCY）のディスクグループに置いて投票ディスクを3本にする等、過半数を失わない限り動き続ける冗長構成にするのが一般的です。
1本構成では、その1本への到達不可がそのままノード停止に直結します（今回の再現がまさにそれです）。

6. まとめ

まず見る順番（診断フロー）

「インスタンス2がダウン」の第一報からディスク型 evict にたどり着くには、次の順で見ます。

「インスタンスがダウン」のアラート
        │
        ▼  ① 全体のリソース状況を確認
  crsctl stat res -t
    Target=ONLINE で落ちている＋VIP フェイルオーバ → node evict
        │
        ▼  ② 生存ノードの CRSアラートログ
  カウントダウン（CRS-1612系）はあるか？
    ある   → ネットワーク型（前回）
    ない   → いきなり CRS-1625（離脱報告）だけ → 落ちたノードの自己停止を疑う
        │
        ▼  ③ 落ちたノードの CRSアラートログ（最重要）
  CRS-1615/1614/1613（50/75/90%・disktimeout 200秒）→ CRS-1606 → ディスク型で確定
        │
        ▼  ④ 答え合わせ
  crsctl stat res -t -init の ora.cssd
    VOTING FILES FAILURE → ディスク型／INTERCONNECT FAILURE → ネットワーク型
  落ちた側 DB アラートの Instance terminated by（CKPT なら制御ファイルの I/O エラー）

実際の時系列 ― 両ノードで何が起きたか

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

1. カウントダウンが出るノードで型が分かる。
   生存側に出ればネットワーク型（CRS-1612 系・30秒）、切り離される側に出ればディスク型（CRS-1615 系・200秒）。
2. 停止は二段階。投票ディスクがデータと同居する構成では、DB は数秒で停止し（CKPT・I/O エラー）、クラスタ層は disktimeout（200秒）を超えてから自己停止する。層でタイマーが異なる。
3. ディスク型に kill block はない。読めない相手に書いても届かないため、切り離される側の自己停止（CRS-1606）だけで切り離しが成立する。

これで、連載の切り分け基準がひととおり揃いました。
instance down か node evict かは NM層の反応の有無で、evict の型はカウントダウンの出るノードで見分ける。
第一報が同じ「インスタンスがダウン」でも、ログの出る場所を順に確認すれば原因までたどり着けます。