不存在“pdb级快照”，所有pdb共用cdb$root的snap_interval和retention配置，awr数据通过con_id字段在cdb统一视图中按pdb筛选，dba_hist_snapshot无con_id，其子表才承载pdb数据。
不是PDB没生成快照，是根本不存在“PDB级快照”这回事
查DBA_HIST_WR_CONTROL必须在CDB$ROOT里执行
你在PDB里执行SELECT SNAP_INTERVAL, RETENTION FROM DBA_HIST_WR_CONTROL看到的值，只是CDB$ROOT配置的镜像，不代表PDB有独立控制权。所有PDB共用CDB$ROOT的SNAP_INTERVAL和RETENTION，没法给某个PDB单独设15分钟、另一个设60分钟。
- 真正生效的配置只能从
CDB$ROOT查：连接后先ALTER SESSION SET CONTAINER = CDB$ROOT -
AWR_PDB_SNAPSHOT视图为空不等于没数据——它只记录PDB级ASH flush动作，依赖底层CDB快照已存在 - 验证快照是否真生成，查
DBA_HIST_SNAPSHOT（注意它的CON_ID永远是0），再等满一个SNAP_INTERVAL周期（比如设了30分钟，至少等35分钟）
@awrrpt.sql在PDB里必报ORA-13541或静默失败
直接在PDB中运行@?/rdbms/admin/awrrpt.sql会失败，因为脚本底层调用DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML，该函数强制要求session位于CDB$ROOT，且PDB缺少WRM$_DATABASE_INSTANCE元数据。
- 生成PDB报告的正确方式：在
CDB$ROOT中运行脚本，传入inst_num和dbid，脚本自动按CON_ID过滤 - PDB性能数据全靠
CON_ID字段从CDB统一视图里筛选，比如DBA_HIST_ACTIVE_SESS_HISTORY里的CON_ID非0记录才属于某PDB -
DBA_HIST_SNAPSHOT本身没有CON_ID，别指望靠它定位PDB快照——它的子表才有
MMON挂起或SYSAUX空间假性耗尽是真因
看到ORA-1688别急着扩SYSAUX，大概率是MMON异常导致WRH$表积压、自动清理失效。哪怕SYSAUX还剩20%空间，也会报错。
- 查MMON真实状态：
SELECT * FROM v$bgprocess WHERE pname = 'MMON'，没返回行或SPID为空说明异常 - 别用
ps -ef | grep mmon找进程——Linux下它混在oram000*里；也别kill -9，会导致后续快照永久失败 - SYSAUX里
WRH$_%段占超70%，基本可判定MMON清理已滞后；先查dba_segments确认真实占用，再看DBA_HIST_WR_CONTROL的RETENTION是否被设成10000天这种不合理值
STATISTICS_LEVEL=BASIC或归档满会直接掐断快照
STATISTICS_LEVEL设为BASIC时，AWR快照压根不会触发；RAC环境归档日志满也会让MMON卡住，表现为ORA-32701或enq: WF - contention等待。
- 检查当前值：
SHOW PARAMETER STATISTICS_LEVEL，必须是TYPICAL或ALL - 归档满时，
MMON可能hang住，重启MMON可用ALTER SYSTEM SET "_swrf_mmon_flush"=false再=true，但更稳妥的是清归档+等MMON自恢复 -
WRH$_SQL_BIND_METADATA这类表因绑定变量过多导致flush超时，可临时禁用：ALTER SYSTEM SET "_awr_disabled_flush_tables" = 'wrh$_sql_bind_metadata'
最易被忽略的点：以为AWR_PDB_SNAPSHOT为空就代表PDB没采集数据，其实只要CDB快照存在，PDB的ASH、SQL、等待事件等数据全在带CON_ID的子表里——查DBA_HIST_ACTIVE_SESS_HISTORY比盯着那个空视图有用得多。
