挂起时ASH失效，应立即用oradebug hanganalyze 3和systemstate 258诊断；-prelim是唯一应急连接方式，且仅限执行oradebug命令。
挂起时ASH根本不能用，别试了
oracle 12c 挂起时，v$active_session_history 基本失效——因为后台进程 mmnl 通常已被 latch 或 ipc 争用卡死，无法写入 sga 中的 ash buffer。你执行 @?/rdbms/admin/ashrpt.sql 卡住、报 ora-00604、或生成报告里全是空行/空等待，就是典型失能信号。
查一下 v$session 里 MMNL 的状态：SELECT state, event FROM v$session WHERE program LIKE '%MMNL%'; 如果是 WAITING 且 event 是 latch: shared pool 或 enq: SQ - contention，就别等 ASH 刷新了，立刻切到 hanganalyze + systemstate。
oradebug hanganalyze 3 是唯一靠谱起点
hanganalyze 3 输出的是等待关系拓扑图，直接标出谁在等谁、等什么资源，比如 PROCESS 1234: waiting for 'gc current block 2-way'。它不依赖完整会话建立，只要能连上（哪怕只有一条“还活着”的 sqlplus / as sysdba），就能跑。
- 必须确保该会话不是
ACTIVE状态（否则自己也会被 hang 住） - RAC 环境下务必用
oradebug -g all hanganalyze 3，单实例用oradebug hanganalyze 3 - 两次
hanganalyze至少间隔 60 秒，太快结果失真 - 别用 level 4 及以上：trace 文件暴涨、I/O 压力大，且 Oracle 官方明确建议“仅在 Oracle Support 指导下使用”
systemstate dump 必须选对 level，258 是 12c 生产默认安全值
Level 10 太简略，看不到函数调用栈深度；level 266/267 在老版本 RAC（≤11.2.0.2）有 Bug，可能触发二次 hang；而 12c（12.1+）虽已修复，但生产环境仍推荐 systemstate 258：
- 比 level 10 多收集
short stack，能看出线程卡在哪一层函数调用 - 比 level 266 少 dump lock element data，避免 trace 文件过大、写入卡死
- 不含 global cache detail（那是 level 256+ 才有），规避高并发 GC latch 争用导致的 dump 卡死
- RAC 下仍需搭配
oradebug -g all dump systemstate 258，否则跨节点等待链断开
连不上数据库？-prelim 是唯一入口，但只能干一件事
普通 sqlplus / as sysdba 会尝试初始化 SGA 和 session，在挂起时必然失败。sqlplus -prelim '/ as sysdba' 绕过这些，直连 Oracle 内核，是唯一应急通道。
但注意：-prelim 成功后，你只能执行 oradebug 命令，不能查表、不能运行 PL/SQL、不能做任何 DML/DQL。
- 连
-prelim都失败？说明 instance 已完全 hang 死，需 OS 层用dbx或gdbattach 进程，调用ksudss(10)强制 dump - 执行顺序必须是：
oradebug setmypid; oradebug unlimit; oradebug dump systemstate 258，漏掉unlimit可能因 trace 文件大小限制截断关键信息
真正难的不是命令怎么敲，而是判断哪个会话“还活着”、哪次 dump 覆盖了挂起发生的时间点——trace 文件里重复出现的 ksfqs、kjbr、kcbb 等内核函数名，往往比等待事件更能暴露根因。
