awr快照生成失败主因是mmon进程卡住、sysaux表空间被wrh$表分区占满或wrh$_sql_bind_metadata因绑定变量泛滥扫描x$kqlfbc超时；需查v$bgprocess确认mmon状态、用dba_segments定位大wrh$段、禁用该表刷新或清理绑定变量源头。
AWR快照生成失败，大概率不是配置没开，而是后台进程被卡住或资源冲突了——直接查MMON状态、SYSAUX空间、绑定变量表性能这三项，比反复调参数更有效。
ORA-13502 / ORA-32701 报错：备库不能生成快照是设计限制，不是故障
在ADG备库上执行 dbms_workload_repository.create_snapshot() 必然报 ORA-13502: cannot create awr snapshot on a standby database。这不是bug，是Oracle硬性限制：19c及以前版本中，备库不采集本地快照，DBA_HIST_* 表里的数据全来自主库同步，哪怕你设了 STATISTICS_LEVEL = ALL，也只影响内存视图（如 V$SESSION_EVENT），不影响历史表。
常见误操作：
- 在备库跑
@?/rdbms/admin/awrrpt.sql，选“Local Database”，结果报告里全是主库负载 - 看到
SELECT COUNT(*) FROM DBA_HIST_SNAPSHOT返回非零值，就以为备库有自己快照——其实只是主库同步过来的旧数据 - 试图用
ALTER SYSTEM SET _awr_enabled=TRUE强开，无效，该参数在备库被忽略
真要监控备库自身性能，必须走Remote Management Framework（RMF）流程：主库解锁 SYS$UMF 用户、建双向DBLINK（注意备库连主库会报 ORA-16000，属正常）、主库设 "_umf_remote_enabled" = TRUE、调用 DBMS_UMF.CONFIGURE_TOPOLOGY 和 REGISTER_DATABASE，最后用 DBMS_UMF.CREATE_REMOTE_SNAPSHOT 触发备库本地采样。生成报告时，脚本里必须选“Remote Database”类型，并填对备库的 DBID 和 INSTANCE_NUMBER。
MMON卡住、快照长时间无响应：先看SYSAUX和绑定变量表
手动执行 dbms_workload_repository.create_snapshot() 卡住，或告警日志频繁出现 ORA-32701、Slave action has been temporarily suspended，说明MMON进程被阻塞。最常踩的坑是：
-
SYSAUX表空间满或碎片高：查dba_data_files看剩余空间，尤其注意WRH$_*表是否因保留策略过长而膨胀 -
WRH$_SQL_BIND_METADATA插入慢：大量绑定变量导致该表写入超时，错误日志里会出现insert into wrh$_sql_bind_metadata ... SELECT /*+ ordered use_nl(bnd) ... */卡住。此时禁用该表刷新最直接：ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'wrh$_sql_bind_metadata' - 固定表统计信息陈旧：运行
dbms_stats.gather_table_stats('SYS', 'X$KEWRATTRNEW')和dbms_stats.gather_table_stats('SYS', 'X$KEWRSQLIDTAB')，别漏掉X$KQLFBC（对应v$sql_bind_capture）
清空shared_pool（ALTER SYSTEM FLUSH SHARED_POOL）能临时缓解，但治标不治本；重启MMON需谨慎，建议先停掉自动任务再启：EXEC DBMS_SCHEDULER.DISABLE('BSLN_MAINTAIN_STATS_JOB')，否则可能立刻重陷循环。
AWR报告“缺失”或为空：检查快照是否存在，而非只盯报告脚本
执行 awrrpt.sql 报 ORA-13509 或返回空内容，第一反应不该是重跑脚本，而是确认底层快照有没有真正生成：
- 查
dba_hist_snapshot：如果SNAP_ID跳号（比如从100直接到105），说明那几轮快照根本没成功落盘 - 查
dba_hist_wr_control：确保STATUS是ENABLED，且RETENTION没被设成0（有些升级后默认被清空） - 查
v$session中阻塞MMON的会话：等待事件为enq: WF - contention或latch: shared pool时，大概率是shared_pool争用或内部锁 - RAC环境多实例记录混乱：主机名变更后（如从
lxsu1改为xmsu1），dba_hist_database_instance里可能残留旧记录，需人工清理过期行
手动生成快照失败时，别反复试，先用 SELECT SNAP_ID, BEGIN_INTERVAL_TIME, FLUSH_ELAPSED FROM dba_hist_snapshot ORDER BY snap_id DESC 看最近一次成功快照耗时——若 FLUSH_ELAPSED 超过300秒，说明写入已严重延迟，得优先处理SYSAUX I/O或归档压力。
执行计划分析依赖AWR？别只信v$sql，重点核对plan_hash_value稳定性
查SQL性能问题时，很多人盯着 v$sql 里当前缓存的 PLAN_HASH_VALUE，但这个值随时可能被刷出共享池。AWR才是唯一能回溯真实执行路径的依据：
- 用
dba_hist_sqlstat查某sql_id在7天内是否出现多个plan_hash_value：返回多行才说明真漂移；只有一行，问题可能在I/O、锁或内存，不在执行树 - 用
DBMS_XPLAN.DISPLAY_AWR查具体计划时，必须加'ADVANCED'参数，否则看不到关键Note，比如SQL plan baseline used for this statement——没这行，基线就是没生效 -
dba_hist_sql_plan默认最多存1000行/SQL（受_cursor_plan_cache_threshold控制），高频SQL可能被截断，查不到不等于没历史计划 - RAC下必须逐实例查
gv$sql和dba_hist_sqlstat，同一sql_id在不同节点可能走不同计划，单节点加载基线无效
AWR报告本身不会“失效”，但它的数据源（快照）一旦生成异常，所有基于它的分析都会失真——所以排查永远从快照生成环节开始，而不是报告输出环节。
