挂起时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而不是只看ASHASH适合定位SQL级阻塞比如某条语句长期db file sequential read但对RAC节点间全局锁、library cache pin死锁、IPC消息积压这类系统级hang它看不到根源线程栈和内存持有关系——只有systemstate能暴露每个进程在做什么、持有什么、等什么。典型场景gv$lock显示大量TX或DF锁但无明显holdergv$session里一堆ON CPU却无SQL执行RAC中某节点gc cr block busy飙升但ASH里没对应SQL关键区别ASH是“抽样快照”systemstate是“全内存快照”——前者告诉你“谁在等”后者告诉你“谁在拿、谁在堵、谁在转圈”RAC下务必用oradebug setmypid; oradebug unlimit; oradebug dump systemstate 267Level 267才包含所有实例的跨节点资源映射Level 266只对单实例有效HANGANALYZE Level 266 vs 267怎么选Level 266输出的是当前实例内进程间的等待图wait-for graph能快速看出谁等谁Level 267则强制触发全RAC节点的systemstate dump并在最后附上整合后的hang分析——但代价是更长的阻塞时间、更大的trace文件。 AI Code Reviewer AI自动审核代码