v$active_session_history不可见重启前数据，因其为内存视图，实例终止即清空；AWR仅存聚合摘要，原始等待链等关键信息已丢失。
直接查 v$active_session_history 不行 —— 它默认只保留 1 小时（且依赖 awr 快照周期），节点重启后内存中数据全丢，必须提前导出或从 awr 归档中捞。
为什么重启前的 ASH 数据通常不可见
节点异常重启时，v$active_session_history 是内存视图，内容随实例终止而清空。即使你立刻连上（比如通过另一节点的 srvctl start instance 拉起），也看不到崩溃前的会话堆栈。AWR 快照本身不存完整 ASH 行，只存聚合统计（如 dba_hist_active_sess_history 中的采样摘要），原始等待事件链、绑定变量、SQL 执行计划片段等关键诊断信息已丢失。
常见误操作包括：
- 重启后才想起查
select * from v$active_session_history where sample_time > sysdate - 1/24→ 返回空 - 依赖
dba_hist_active_sess_history查具体 SQL 的执行耗时分布 → 只能看“某 SQL 出现了 37 次”，但不知道是哪次卡在enq: TX - row lock contention还是gc cr block busy
真正可用的断电前 ASH 数据来源只有两个
必须在节点仍存活、但已出现明显卡顿（如 crsctl check crs 响应慢、ps -ef | grep ocssd 显示 CPU 占用突增）时介入：
-
手动触发即时 ASH dump：运行
oradebug setmypid; oradebug dump ashdump 1，生成 trace 文件于$ORACLE_HOME/rdbms/log/下，含最近 60–90 秒的完整 ASH 记录（含 session_id、sql_id、event、p1/p2/p3、blocking_session） -
从 AWR 归档中提取近似窗口：若未及时 dump，可查
dba_hist_snapshot找重启时间点前最后一个完整快照（如重启发生在 10:58，则取 10:45 或 10:30 的快照 ID），再用awr_report_text或awrddrpt.sql生成该时段的 Top SQL / Top Event 报告 —— 虽非秒级，但能定位持续性瓶颈（如某 SQL 平均逻辑读超 500k）
导出失败时的兜底方案：从 CSSD 日志反推时间线
当数据库进程已终止、连不上实例，又没做 ASH dump，唯一能交叉验证“重启前是否真有性能抖动”的是 ocssd.log。它不记录 SQL，但记录节点心跳延迟：
- 搜索
misscount关键字：若出现Network heartbeat failed后紧接disk heartbeat failed，说明网络和存储 I/O 同时恶化，大概率是底层问题（如私网网卡软中断堆积、ASM diskgroup IO 等待超 500ms） - 检查时间戳密度：正常时
ocssd.log每秒写 1–2 行；若某段连续 3 秒无日志，或出现大量WARNING: clsc_connect: (0x...): connect failed with error 110（ETIMEDOUT），基本可判定该时段节点已失联或严重 hang 住 - 对比
oclsomon.log：该文件由监控进程生成，若其中出现OCSSD process appears hung，且时间点与数据库 alert.log 中第一条ORA-29740（eviction）吻合，就能锁定 hang 起始时刻
实际排查中最容易被跳过的是：没确认 oradebug dump ashdump 是否真的写入磁盘 —— 有些环境因 trace 目录权限不足或 max_dump_file_size 设为 0，dump 无声失败。务必在执行后立即 ls -lt $ORACLE_HOME/rdbms/log/*ash* 验证文件存在且大小 >1KB。
