awr设为typical可能引发性能抖动，因其触发v$sql_bind_capture全量扫描和gv$sql_plan_statistics_all采样，在高并发绑定变量场景下加剧x$kqlfbc争用，导致mmon卡顿、快照延迟及sql响应变慢。
awr快照收集本身不会主动拖慢数据库，但默认的typical级别在特定负载下会放大已有瓶颈
为什么把收集级别设为TYPICAL反而可能引发性能抖动
很多人以为把AWR从BASIC切到TYPICAL是“加功能”，其实它是“加采集点”。TYPICAL不是简单开关，它决定哪些内部视图会被轮询、哪些绑定变量元数据会被捕获、哪些SQL执行路径会被记录。关键在于：v$sql_bind_capture和x$kqlfbc这类内存基表在高并发SQL提交+大量绑定变量场景下，访问开销会指数级上升——而TYPICAL正是开启这些采集的触发器。
常见现象包括：
- MMON从属进程（如
m000）在执行insert into wrh$_sql_bind_metadata时卡住，日志报ORA-12751: cpu time or run time policy violation - 快照生成时间从几十秒拉长到数分钟，期间持续占用CPU资源
- 业务SQL响应变慢，尤其在每小时整点前后出现规律性延迟
TYPICAL vs BASIC：到底差在哪几条关键SQL
TYPICAL比BASIC多采集的核心项集中在绑定变量、SQL执行计划变更、游标共享统计三类。影响最大的是以下两个动作：
- 每小时快照周期内，对
v$sql_bind_capture做全量扫描（而非增量），该视图底层依赖x$kqlfbc，而后者在SQL硬解析频繁时极易成为争用热点 - 对
gv$sql_plan_statistics_all采样，若库中存在大量短生命周期SQL或未绑定变量的动态SQL，会导致大量无效plan_hash_value计算和存储
你不需要禁用TYPICAL，但必须确认：dba_hist_wr_control中TOPNSQL值是否被设得过大（比如>100），这会让AWR强行抓取更多低频SQL的绑定信息，进一步加重x$kqlfbc压力。
不改TYPICAL也能缓解的实操动作
如果你无法临时降级为BASIC（比如监控平台强依赖TYPICAL指标），优先做这几件事：
- 检查并限制自动任务窗口：用
dbms_scheduler.disable('BSLN_MAINTAIN_STATS_JOB')暂停非核心统计任务，避免与AWR快照时间重叠 - 清理
v$sql_bind_capture积压：该视图内容不持久，但若长期无人消费（如未配置ADDM或未跑AWR报告），其内存缓存可能膨胀；可重启数据库或执行alter system flush shared_pool（需评估影响） - 调小
SNAP_INTERVAL：默认60分钟太粗，改成30分钟后，单次采集量减半，但总数据量不变——关键是分散了瞬时压力 - 确认
SYSAUX表空间无碎片：用V$SYSAUX_OCCUPANTS查SM/AWR和SM/OPTSTATS是否异常增长，空间碎片会导致WRH$表写入变慢，反向拖累快照流程
真正要警惕的不是TYPICAL这个开关，而是它暴露出来的底层问题：绑定变量滥用、硬解析泛滥、共享池管理松散。快照只是镜子，照出的是SQL质量本身。
