不能。数据库完全卡死时sql*plus无法连接，real-time addm不可用；仅当实例“假死但未崩溃”、监听器通畅、后台进程存活且能建立轻量级连接时才可用。
数据库已挂起，还能连上SQL*Plus吗？
不能。Real-time ADDM 依赖 V$ACTIVE_SESSION_HISTORY 和实时内存结构，一旦数据库实例完全卡死（如大量会话阻塞、LGWR挂住、checkpoint not complete），sqlplus / as sysdba 往往会卡在连接阶段或报 ORA-01012: not logged on、ORA-12537: TNS:connection closed。此时 Real-time ADDM 已不可用——它不是“救火工具”，而是“事中诊断器”，前提是实例仍在响应。
什么情况下 Real-time ADDM 才真正可用？
它只在数据库处于“假死但未崩溃”状态时有效：监听器仍通、部分后台进程存活、能建立轻量级连接。典型场景包括：
- 大量会话堆积在
gc buffer busy acquire或enq: TX - row lock contention，但 LGWR/DBWn 仍在运行 - AWR 快照未中断，
V$SYS_TIME_MODEL中DB time持续上涨，但 SQL*Plus 可登录（哪怕要等 10–20 秒） - 应用层报超时（如 JDBC
Connection timeout），但ps -ef | grep ora_显示实例进程未退出
满足以上任一条件，才可立即执行：
sqlplus / as sysdba @?/rdbms/admin/addmrpti.sql——注意是
addmrpti.sql（i 表示 interactive），不是历史快照版的 addmrpt.sql。执行 Real-time ADDM 前必须确认的三件事
跳过检查大概率拿到空报告或报错 ORA-13634: invalid AWR snapshot range：
-
STATISTICS_LEVEL必须为TYPICAL或ALL（查SHOW PARAMETER statistics_level） - 当前实例未重启过：Real-time ADDM 不支持跨实例生命周期分析；若刚
startup force过，V$ACTIVE_SESSION_HISTORY就是空的 - 确保
DBA_HIST_REPORTS视图可查（验证语句：SELECT COUNT(*) FROM dba_hist_reports WHERE report_name LIKE 'realtime%'；若无结果，说明底层 XML 生成模块未就绪）
报告里最该盯住的两个指标段
Real-time ADDM 报告输出长，但只需聚焦两处即可快速定位根因：
-
Top DB Time Contributors：看哪类等待占 DB Time 超过 30%。若出现
log file sync+log file parallel write同时飙升，基本锁定存储 I/O 延迟或归档路径满；若只有gc cr block busy单点突出，大概率是 RAC 节点间心跳或私网异常 -
SQL with Top DB Time：注意不是“执行次数最多”的 SQL，而是“单次执行耗 DB Time 最高”的 SQL。这类 SQL 往往没走索引、用了全表扫描+大量排序，且正在占用 TEMP 表空间——此时立刻查
SELECT sql_id, temp_space_allocated FROM v$session s JOIN v$sort_usage u ON s.saddr = u.session_addr
Real-time ADDM 本身不解决任何问题，它只告诉你“此刻最烫的山芋在哪”。真正危险的是：有人看到报告说“CPU 使用率高”，就去调 CPU_COUNT，却忽略背后是某个未绑定变量的 SQL 正在硬解析风暴——这恰恰是报告里“SQL with Top DB Time”那一节反复强调却常被跳过的细节。
