ASH报告生成前提是数据库必须处于OPEN状态且SQL*Plus可连接；若数据库Hang住则无法执行ashrpt.sql，此时可尝试MMNL信号dump或oradebug采集ASH内存快照，或从AWR中回溯近似ASH数据。
ASH报告生成前提：数据库必须能连上
不能。Oracle ashrpt.sql 脚本依赖数据库实例处于 OPEN 状态且能接受 SQL*Plus 连接，如果数据库已 Hang 住（比如所有会话卡死、后台进程僵死、SGA 被锁死），sqlplus / as sysdba 就连不上，脚本根本无法执行——这不是参数或路径问题，是底层连接失败。
Hang 时唯一可用的“类 ASH”数据来源是内存转储
当数据库无法登录但仍部分响应（例如能触发 oradebug 或收到信号），可尝试强制采集当前内存中的 ASH 缓冲快照：
- 用操作系统级信号触发 MMNL 进程 dump：
kill -USR2 <MMNL_PID>（需先用ps -ef | grep mmnl找到进程） - 或在能连上的极少数场景下（如仅前台会话 Hang，后台仍活），用
oradebug setmypid; oradebug dump ashdump 1——但该命令不保证成功，且输出是 raw trace 文件，不是 HTML 报告 - dump 出来的 trace 文件里含原始 ASH buffer 内容，需人工解析
v$active_session_history结构字段，无法直接替代ashrpt.sql的聚合视图
真正可行的替代方案：从 AWR 中回溯近似 ASH 数据
如果数据库 Hang 前几小时还正常，且 AWR 快照已成功生成（默认每小时一次），可用 awrrpt.sql 生成最近时段的 AWR 报告，再重点看其中的 “Top SQL with Top Events” 和 “Active Session History (ASH) based” 小节（19c+ 支持）——它会把持久化到 WRH$_ACTIVE_SESSION_HISTORY 表里的 ASH 抽样数据做聚合展示，虽粒度粗（非秒级）、覆盖短（受 ASH 写入频率限制），但至少有数据可查。
- 执行
@?/rdbms/admin/awrrpt.sql，report_type输入html -
num_days建议输1，避免跨太多快照导致分析失焦 - 选两个紧邻的快照（如
begin_snap=12345,end_snap=12346），duration 实际约 60 分钟，足够覆盖多数瞬态问题 - 注意：AWR 中的 ASH 数据是采样后写入的，丢失率约 90%，关键等待事件可能被过滤掉
Hang 后恢复第一时间该做的事
数据库重启后，别急着跑 ashrpt.sql，先确认 ASH buffer 是否还有残留数据：
- 立刻登录：
sqlplus / as sysdba - 查最近采样时间：
SELECT MAX(sample_time) FROM v$active_session_history;—— 如果结果是 Hang 前几分钟，说明缓冲区没全丢，还能抢救 - 此时立即运行
@?/rdbms/admin/ashrpt.sql，begin_time填 Hang 发生前 5 分钟，duration填 30（分钟），别拖——ASH buffer 是循环覆盖的，晚一分钟就可能被新采样冲掉 - 生成的 HTML 文件一定在你启动
sqlplus的当前目录，不是$ORACLE_HOME下，别翻错地方
ASH 报告不是数据库的“录像回放”，而是内存里的一段易失快照；Hang 住时它早就不在了。能做的只有事后抢时间、靠 AWR 补漏、用 trace 猜线索——没有银弹，只有优先级和时机。
