能，但需规避物理i/o、实时性依赖和undo一致性读问题；否则触发fetch等待或日志应用暂停，导致性能下降甚至ora-16000报错。

active data guard备库能直接跑报表吗？

能，但不是所有报表都适合——关键看查询是否触发物理I/O、是否依赖实时性、是否绕过UNDO一致性读。Active Data Guard（ADG）的只读打开状态本身不阻塞日志应用，但一旦查询需要访问尚未应用到备库的归档或在线日志中的数据块，就会触发FETCH等待，甚至退化为“伪只读”：备库临时挂起日志应用，等查询完成再继续同步。

哪些SQL在ADG备库上容易变慢？

这类查询往往暴露ADG底层机制的约束：

• SELECT COUNT(*) FROM big_table —— 全表扫描+大量逻辑读，若表有高频DML，备库可能持续追赶，block version不一致导致反复回滚构造CR块
• 带AS OF TIMESTAMP或FLASHBACK QUERY的语句 —— ADG默认不保留UNDO用于闪回，除非显式启用UNDO_RETENTION并确保主库UNDO传输到备库（需配置LOG_ARCHIVE_DEST_n参数含SYNC和DB_UNIQUE_NAME）
• 未走索引的大范围RANGE SCAN（如WHERE create_time > SYSDATE - 7）—— 若索引字段被频繁更新，备库延迟几秒就可能让谓词匹配到大量“待清理”的ITL事务，拖慢一致性读构造

怎么让报表查询在ADG上更稳更快？

核心思路是减少对“未应用块”的依赖，把压力从物理I/O和UNDO构造转移到内存和索引效率：

• 强制走覆盖索引：SELECT /*+ INDEX(t idx_report_cover) */ col1, col2 FROM report_tab t WHERE ...，避免回表读表块
• 用RESULT_CACHE缓存结果集（注意：仅限静态维度表或TTL明确的汇总结果），但需确认RESULT_CACHE_MODE在备库设为MANUAL且SGA中有足够result_cache_max_size
• 对超大事实表，改用物化视图（ON COMMIT REFRESH FAST不行，必须ON DEMAND + 主库推送刷新），备库上建DISABLE QUERY REWRITE的MV，避免优化器误选主库对象
• 监控V$DATAGUARD_STATS中apply lag和transport lag，若常>2s，报表应避开高峰时段或加/*+ DRIVING_SITE(remote_table) */把计算推回主库（需DB Link）

为什么开了ADG还报ORA-16000？

这是最常被忽略的权限与状态陷阱：ORA-16000表示“数据库以只读方式打开”，但它不是错误，而是状态提示——真正的问题是应用连接串里没加READ_ONLY=TRUE，或用了ALTER SESSION SET CURRENT_SCHEMA后执行了隐式DML（比如INSERT /*+ APPEND */进全局临时表，触发日志生成）。更隐蔽的是PL/SQL包里调用了DBMS_MVIEW.REFRESH或DBMS_STATS.GATHER_TABLE_STATS，这些在ADG备库上默认禁用，会直接报ORA-16000而非ORA-16014。

检查点就一个：连上去先查SELECT OPEN_MODE, DATABASE_ROLE FROM V$DATABASE，确认是READ ONLY WITH APPLY；再查V$SESSION里你的会话SQL_ID对应语句是否含DDL/DML关键字——哪怕只是ANALYZE TABLE也不行。