AWR报告不直接显示自定义PL/SQL函数调用开销，需通过SQL ordered by CPU Time中高CPU低I/O的SQL，结合DISPLAY_AWR执行计划查FUNC EVALUATION或PL/SQL EXECUTE，再用DBA_HIST_ACTIVE_SESS_HISTORY定位具体调用上下文。
awr 报告本身不直接暴露自定义 pl/sql 函数的调用开销，但可通过间接指标定位——关键看 sql ordered by cpu time 和 sql ordered by elapsed time 中那些执行计划含 function 或 pl/sql execute 的 sql，再结合 dba_hist_sqlstat 和 dba_hist_active_sess_history 追踪函数实际耗时。
查 SQL 是否隐式调用了自定义函数
自定义函数若被嵌入 SQL（如 WHERE my_func(col) = 1 或 SELECT my_func(col) FROM t），它不会单独出现在 AWR 的“PL/SQL”统计里，而是被计入父 SQL 的 CPU/Elapsed 时间。所以第一步不是找函数名，而是找「高 CPU 却无明显 I/O 或等待」的 SQL：
- 在 AWR 报告中打开
SQL ordered by CPU Time，筛选CPU Time (s)高但Physical Reads和Wait Time (s)极低的 SQL —— 这类 SQL 很可能在反复执行 PL/SQL 函数逻辑 - 用该 SQL 的
SQL_ID查执行计划：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id'))，重点看Operation列是否含FUNC EVALUATION、PL/SQL EXECUTE或CALL - 若计划中出现
VIEW且 Object_Name 是系统生成名（如VW_SQ_1），需进一步查DBA_HIST_SQLTEXT确认原始语句是否含函数调用
确认函数是否被内联或重复计算
Oracle 11g 默认对纯函数（DETERMINISTIC）做结果缓存，但多数自定义函数未声明该属性，导致每次调用都重新执行。AWR 不记录函数级统计，但能暴露副作用：
- 检查同一 SQL 的
Executions和Buffer Gets比值：若 executions 高但 buffer gets 低，说明大量时间花在 CPU 计算而非数据访问，函数逻辑可能过于复杂 - 对比不同快照中该 SQL 的
Rows Processed和CPU per Exec (s)：若行数不变但 CPU per Exec 持续上升，大概率是函数内部逻辑随数据增长呈非线性恶化（如循环查表、递归调用） - 注意
Version Count：若该 SQL 的 version count > 5，且函数参数含字面量（如my_func('2026-06')），说明每次调用都生成新游标——函数未绑定变量，加剧硬解析和共享池压力
用 ASH 数据补全函数调用上下文
AWR 是聚合快照，丢失会话粒度细节；DBA_HIST_ACTIVE_SESS_HISTORY（ASH）能定位具体哪次调用卡住：
- 运行：
SELECT sql_id, session_id, sql_exec_id, event, p1text, p1 FROM dba_hist_active_sess_history WHERE sql_id = 'xxx' AND sample_time > SYSDATE - 1/24 AND event LIKE '%PL/SQL%' - 若返回
event = 'PL/SQL lock timer'或event = 'db file sequential read'且p1text = 'file#'，说明函数内部触发了 I/O（比如动态 SQL 查表） - 若
event = 'ON CPU'占比超 90%，且sql_exec_id集中在少数几个值，基本可断定是函数 CPU 密集型瓶颈
别忽略函数所在包的初始化开销
PL/SQL 包首次调用时会触发包体初始化（如全局变量赋值、游标 OPEN），这部分时间计入第一次调用的 SQL 耗时，但后续调用不体现——这会导致 AWR 中同 SQL_ID 的单次耗时波动极大：
- 检查 AWR 中该 SQL 的
Min Elapsed Time (s)和Max Elapsed Time (s)差值：若相差 10 倍以上，优先怀疑包初始化或会话级缓存未生效 - 用
SELECT owner, object_name, object_type FROM dba_objects WHERE object_name = 'YOUR_PKG' AND status != 'VALID'确认包是否失效重编译过——失效后首次调用会触发隐式编译，拖慢响应 - 11g 中若包含大量
PRAGMA SERIALLY_REUSABLE，其全局状态在每次调用后被清空，反复初始化也会抬高 CPU
真正难定位的是那些被优化器“隐藏”掉的函数调用：比如函数作为索引表达式（CREATE INDEX idx ON t (UPPER(name))）或物化视图刷新逻辑的一部分。这类场景必须跳出 AWR，直接查 DBA_IND_EXPRESSIONS 或 DBA_MVIEWS 关联的定义语句。
