ORA-00600本身不直接导致RAC实例crash，真正触发终止的是其引发的连锁反应（如ORA-07445、LMS崩溃或SMON/KJZ异常退出）；定位须从crash时间点向前追溯5分钟错误链，优先确认是否为CRS主动evict，并结合alert.log中Errors in file路径、ADRCI提取incident、以及[kj/kcb/ks]调用栈与obj#/rdba定位根因。
ORA-00600 错误本身不直接导致 RAC 实例 crash，但它是内核级异常的信号；真正触发实例终止的，通常是它引发的连锁反应——比如 ORA-07445（核心转储）、LMS 进程崩溃、或 SMON/KJZ 等关键后台进程异常退出。定位必须从 crash 时间点向前追溯，而不是只盯住第一条 ORA-00600。
先确认 crash 是否真由 ORA-00600 引发
很多 RAC 实例“看似 crash”，实则是被 CRS 主动 evict：检查 crsctl stat res -t 和 crsctl check cluster -all 输出。若某节点显示 OFFLINE 或状态反复切换，再查 $GRID_HOME/log/`hostname`/crsd/crsd.log 里是否有 evm evicting node 或 node eviction due to network heartbeat failure。这种情况下，ORA-00600 往往是结果而非原因，优先排查网络、OCR 磁盘、CTSS 同步（crsctl check ctss 显示 observer mode 就要立刻处理）。
从 alert.log 找出 crash 前 5 分钟的错误链
Oracle RAC 的 alert 日志不记录 crash 本身，但会留下关键线索：
- 搜索
Errors in file行，提取路径如/u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_lms0_12345.trc—— 注意进程名是lms0、crs0、smon而非ora_，这类后台进程崩溃才会真正拖垮实例 - 找连续报错：例如先有
ORA-00600 [kjbrcvt]（RAC 缓存融合接收失败），紧接着ORA-07445: exception encountered: core dump [kjbrmrcv()+1234] [SIGSEGV]，最后是PMON (ospid: 12345) is terminating the instance - 注意时间戳对齐：RAC 多节点日志时间可能不同步，用
date -u +%s.%N在各节点取三次平均值，比对误差是否超 500ms
用 ADRCI 快速提取 incident 对应的 trace 文件
人工翻几十 MB 的 .trc 文件效率极低，用 ADRCI 直接定位最相关上下文：
- 启动后执行：
SET HOMEPATH diag/rdbms/<db_name>/<inst_name> - 查最近 3 小时所有严重事件：
SHOW INCIDENT -MODE DETAIL -SINCE "3h" - 挑出
INCIDENT_ID最大且状态为COLLECTED的条目，然后：IPS PACKAGE INCIDENT <INCIDENT_ID>生成 zip 包供 Support 分析 - 若需快速看调用栈，用：
SHOW TRACEFILE -TRACEFILE "<full_path_to_trc>" -LIMIT 200，重点扫Call Stack Trace开头的几行，找以kj（RAC）、kcb（缓存）、ks（内核服务）开头的函数
重点盯住三个参数组合：[function] + [obj#] + [rdba]
单看 [kdsgrp1] 或 [qosdExpStatRead: expcnt mismatch] 只能知道模块，无法定位具体对象。必须结合 trace 文件里的其他线索：
-
obj#:后的数字（如obj#: 36）对应obj$表，查：SELECT owner, object_name FROM dba_objects WHERE object_id = 36; -
rdba:值（如rdba: 0x2f000002）拆成 file# 和 block#：SELECT dbms_utility.data_block_address_file(0x2f000002) fno, dbms_utility.data_block_address_block(0x2f000002) bno FROM dual; -
Current SQL Statement若为空，看SESSION ID:和MODULE NAME:（如sqlservr.exe暗示 SQL Server 链接服务器在刷数据）
真正棘手的是那些跨节点的逻辑损坏——比如一个 block 在 node1 缓存中被标记为“已修改”，但在 node2 的 GCS 资源队列里没收到更新消息，此时 [kjbrcvt] 和 [kjbrmrcv] 会高频出现，且 obj# 往往指向 undo$ 或 seg$ 这类核心字典表。这种问题不会在单节点复现，必须用 AWR 报告比对两节点的 gc cr block received 和 gc current block lost 差值。
