无diagnostic pack license时，仍可合法使用v$session、v$sql、v$system_event等免费视图定位性能问题，并通过定时采样v$sql等手动模拟awr快照对比，结合adrci和alert日志进行故障分析。
没有 Diagnostic Pack License，就无法合法生成 AWR/ADDM/ASH 报告，也不能访问 DBA_HIST_*、V$ACTIVE_SESSION_HISTORY 等关键视图——但这不等于完全失去诊断能力。核心思路是：用免费可用的动态性能视图 + 手动采样 + 时间锚定，逼近 AWR 的分析效果。
哪些视图还能用（且能替代 AWR 核心功能）
Oracle 企业版自带的免费视图中，以下几个可支撑基础性能定位：
-
V$SESSION和V$SESSION_WAIT：实时查看谁在等什么，配合SQL_ID可快速抓现行 SQL -
V$SQL：查缓存中的 SQL 统计，重点关注ELAPSED_TIME、BUFFER_GETS、DISK_READS，排序后找“高消耗但没走索引”的语句 -
V$SYSTEM_EVENT：替代 AWR 的 Top 5 Timed Events，看全局等待事件总耗时，比如db file sequential read占比突增，说明单块读变慢 -
V$FILESTAT+DBA_DATA_FILES：结合算出各数据文件的物理读/写速率和平均 IO 延迟，定位慢磁盘 -
V$INSTANCE和V$SYSMETRIC：查当前 DB Time / Elapsed Time 比值，>1 表示并发压力大；V$SYSMETRIC中的Database CPU Time Ratio能粗略判断 CPU 是否瓶颈
如何手动模拟 AWR 快照对比
AWR 的价值在于“时段对比”，没快照就自己定时抓两组数据：
- 用
SELECT SYSDATE FROM DUAL记下起始时间，然后执行一次全量采样（如把V$SQL中EXECUTIONS > 100的语句按ELAPSED_TIME/EXECUTIONS排序取前 20） - 等 5–10 分钟（问题复现窗口内），再抓一次同样逻辑的数据
- 用 SQL 工具（如 SQL Developer）导出两次结果为 CSV，用 Excel 对比同一
SQL_ID的ELAPSED_TIME、DISK_READS增幅——增幅超 3 倍的，基本就是问题源头 - 注意过滤掉
SQL_TEXT含/*+ MONITOR */或 PL/SQL 匿名块的语句，它们容易干扰判断
为什么 V$TOPLEVELCALL 在无 License 场景下特别有用
很多慢操作表面看 SQL 很简单（比如一个 INSERT INTO t VALUES(...)），但实际卡在递归调用上。这时 V$TOPLEVELCALL 能暴露真实瓶颈：
- 它不要求 Diagnostic Pack，只要企业版即可访问
- 查
TOP_LEVEL_CALL#对应的SQL_ID，再关联V$SQL，就能看到该用户语句触发了多少次递归SELECT（如数据字典查询）、多少次空间分配（ktfbhget类调用） - 典型现象：
V$SQL里这条 INSERT 的DISK_READS是 0，但V$TOPLEVELCALL显示它引发了 5000 次db file sequential read——说明问题在段头块或数据字典读取，不是表本身 - 注意：该视图只保留最近若干次调用，需在问题发生时立即查，不能事后回溯
ADRCI 和 alert 日志是唯一可信赖的“事后证据”
即使没 Diagnostic Pack，ADRCI 和 alert.log 仍完全可用，且对硬故障（如 ORA-600、IO 错误）不可替代：
-
ADRCI不依赖 License，但 RAC 环境下必须逐节点执行show home，漏掉任一节点都可能错过关键堆栈 -
show alert -p "message_text like '%ORA-%'"比翻日志快得多，尤其适合排查刚发生的报错 -
ips pack虽不能跨节点，但单节点打包后，ips verify可确认转储完整性——这是提交给 Oracle Support 的最低要求 - 容易被忽略的一点：
alert.log中的 “Time drift detection” 或 “Checkpoint not complete” 提示，往往比 SQL 慢更早暴露底层问题（如存储响应延迟）
