挂起时ash不可用——因mmnl进程常被卡住，v$active_session_history数据中断或滞后，报告仅为挂起前1–2分钟“残影”；此时应立即转向hanganalyze和systemstate。

挂起时连不上数据库，ash还能用吗

不能直接用——ash依赖后台进程mmnl持续采样，一旦系统级挂起（如latch争用、全局资源死锁），mmnl可能已卡住或无法写入sga缓冲区，v$active_session_history数据会突然中断或严重滞后。此时看到的ash报告，往往是挂起前1–2分钟的“残影”，不是实时状态。

• 现象：执行@?/rdbms/admin/ashrpt.sql卡住、报ORA-00604: error occurred at recursive SQL level 1，或生成报告里全是空等待/空行
• 判断依据：查v$session中MMNL进程状态，若为WAITING但等待事件是latch: shared pool或enq: SQ - contention，基本可确认ASH已失能
• 替代动作：立刻转向HANGANALYZE和systemstate，别等ASH刷新

什么时候必须用systemstate而不是只看ASH

ASH适合定位SQL级阻塞（比如某条语句长期db file sequential read），但对RAC节点间全局锁、library cache pin死锁、IPC消息积压这类系统级hang，它看不到根源线程栈和内存持有关系——只有systemstate能暴露每个进程在做什么、持有什么、等什么。

• 典型场景：gv$lock显示大量TX或DF锁但无明显holder；gv$session里一堆ON CPU却无SQL执行；RAC中某节点gc cr block busy飙升但ASH里没对应SQL
• 关键区别：ASH是“抽样快照”，systemstate是“全内存快照”——前者告诉你“谁在等”，后者告诉你“谁在拿、谁在堵、谁在转圈”
• RAC下务必用oradebug setmypid; oradebug unlimit; oradebug dump systemstate 267，Level 267才包含所有实例的跨节点资源映射，Level 266只对单实例有效

HANGANALYZE Level 266 vs 267怎么选

Level 266输出的是当前实例内进程间的等待图（wait-for graph），能快速看出谁等谁；Level 267则强制触发全RAC节点的systemstate dump，并在最后附上整合后的hang分析——但代价是更长的阻塞时间、更大的trace文件。

• 单实例环境：优先oradebug dump hanganalyze 266，30秒内出结果，够定位大多数library cache / row cache锁问题
• RAC环境：必须用267，否则看不到跨节点的global enqueue（如BL, CF）争用链；但要注意，执行瞬间所有节点都会短暂卡顿
• 容易踩的坑：在已挂起的会话里执行oradebug命令，自己也会被hang住——得找一个“还活着”的会话（比如刚连上的sqlplus / as sysdba），且该会话不能处于ACTIVE状态

ASH和systemstate怎么配合看才不漏关键线索

先用ASH确认挂起发生的时间窗口和主要等待类型（比如集中在latch: cache buffers chains），再用systemstate在那个时间点前后1分钟dump，最后用文本工具搜索trace里重复出现的latch地址、SQL_ID或object_id——这才是闭环。

• 实操技巧：把systemstate trace用grep -A5 -B5 "latch.*address"过滤，再对照ASH里同时间段的SQL_ID，常能发现某条高频硬解析SQL反复申请同一latch
• 性能影响：systemstate 267在大型RAC上可能生成GB级trace，建议提前设oradebug setlimit dumpfile_size 2097152000（2GB）防撑爆磁盘
• 最容易被忽略的一点：systemstate dump后，别急着关会话——先用oradebug dump errorstack 3抓几个疑似阻塞进程的调用栈，否则dump里只有内存布局，没有执行路径