ADG备库默认不生成AWR快照，需手动执行CREATE_REMOTE_SNAPSHOT创建远程快照，并用awrgrpti.sql指定主库DB_ID生成报告，否则无法获取有效快照数据。
ADG备库默认不生成AWR快照，必须手动触发
Oracle Data Guard的物理备库（ADG）在MOUNT或READ ONLY状态下，MMON进程默认不运行，因此不会自动采集AWR快照。即使你看到DBA_HIST_WR_CONTROL里显示快照间隔为60分钟，那也只是主库的配置，对备库无效。
常见错误现象：在备库上执行@?/rdbms/admin/awrrpt.sql时，脚本能运行，但列出的快照ID极少或全是0，或者提示“no snapshots found”。这是因为没有真实快照数据可选。
正确做法是用DBMS_WORKLOAD_REPOSITORY.CREATE_REMOTE_SNAPSHOT显式创建快照：
-
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_REMOTE_SNAPSHOT('orcldr');—— 其中'orcldr'是主库注册到该备库的DB Link名（即V$ARCHIVE_DEST中DEST_NAME对应的DB_UNIQUE_NAME或TNS别名） - 执行前确认备库已打开（
OPEN READ ONLY WITH APPLY），且LOG_ARCHIVE_DEST_STATE_2为ENABLE - 首次调用可能耗时稍长（需拉取主库部分元数据），成功后可在
DBA_HIST_SNAPSHOT中查到新快照，SNAP_LEVEL为2表示远程快照
生成备库AWR报告要用awrgrpti.sql而非awrrpt.sql
awrrpt.sql只读本地WRH$_*表，而ADG备库的AWR历史数据实际来自主库的远程快照——这些数据被映射进备库的WRH$_*视图，但awrrpt.sql默认不识别这种跨库上下文。
必须改用awrgrpti.sql（Global RAC + Instance-aware）脚本，它支持指定DB_ID并强制走远程快照路径：
- 登录备库后执行：
@?/rdbms/admin/awrgrpti.sql - 当提示
Enter value for dbid:时，输入主库的DB_ID（查SELECT dbid FROM v$database;得来，不是备库自己的） - 后续选择时间范围时，看到的快照ID就是之前用
CREATE_REMOTE_SNAPSHOT生成的那些 - 若报错
ORA-13541: system moving window baseline not found，说明备库缺少基线元数据，可跳过基线相关章节，不影响核心等待事件和SQL分析
分析备库延迟时，AWR报告里要盯紧三个地方
备库AWR报告的价值不在“整体负载”，而在定位同步卡点。重点不是看TOP 5 Timed Events平均值，而是交叉验证三组数据：
-
v$system_event中Timer等待占比是否＞10%：超过就说明MRP0/LNSn频繁休眠重试，不是健康心跳 -
DBA_HIST_SYSMETRIC_SUMMARY里Redo Apply Rate和Redo Generate Rate的比值是否持续＜0.9：比值越低，应用越跟不上生成 - 报告末尾的
Instance Activity Stats节中physical reads与redo applied增长是否匹配：如果redo applied停滞而physical reads飙升，大概率是备库I/O瓶颈（如log file parallel write平均等待＞15ms）
注意：备库AWR里的apply lag字段来自V$DATAGUARD_STATS估算值，受SCN增速影响大；真实延迟必须用DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER在主备两端分别查SCN再相减。
CREATE_REMOTE_SNAPSHOT失败的典型原因和绕过方法
执行CREATE_REMOTE_SNAPSHOT报错最常见于网络或权限问题，而不是语法错误：
-
ORA-16778: unable to create remote snapshot：通常是主库监听未开或备库tnsnames.ora里orcldr指向错误；检查TNSPING orcldr能否通，且主库lsnrctl status显示服务已注册 -
ORA-20100: invalid DB link name：传入的字符串不是有效的DB Link名，也不是主库DB_UNIQUE_NAME；确认V$ARCHIVE_DEST中DEST_NAME列的值 - 实在无法建快照，可临时用
awrsqrpt.sql按SQL ID生成单条SQL的AWR报告（依赖SQL在备库有执行计划缓存），或直接查V$MANAGED_STANDBY实时状态
真正容易被忽略的是：ADG备库上的AWR报告永远反映的是“主库当时的负载+备库当时的处理能力”的混合体，不能单独归因。比如db file sequential read高，既可能是备库存储慢，也可能是主库发来的日志块太碎——得结合transport lag与apply lag差值判断责任段。
