备库查询慢是因为未启用active data guard，必须购买并启用adg许可才能进入read only with apply模式；否则mrp进程不运行、scn不推进，导致查不到最新数据，且需检查open_mode、mrp状态、内存配置及service_name隔离。
备库查询慢是因为没开 Active Data Guard
物理备库默认不能查，ALTER DATABASE OPEN READ ONLY 执行失败或查不到最新数据，基本都是因为没启用 ADG 许可。Oracle DG 本身不支持只读查询，必须购买并启用 Active Data Guard 才能进入 READ ONLY WITH APPLY 模式。否则即使挂载成功，V$DATABASE.OPEN_MODE 也只会显示 MOUNTED 或 READ ONLY（无 WITH APPLY），此时 MRP 进程根本不会运行，日志不应用，SCN 不推进，自然查不到主库刚提交的数据。
- 执行
SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE，返回必须是PHYSICAL STANDBY+READ ONLY WITH APPLY - 检查
V$MANAGED_STANDBY中MRP0进程状态是否为APPLYING_LOG，且SEQUENCE#持续增长 - 没买 ADG 许可？
ALTER DATABASE OPEN READ ONLY会报ORA-16004或ORA-01153，不是配置问题，是许可缺失
查得到但查得慢：SGA/PGA 配置不合理
ADG 备库的内存压力和主库完全不同——它不处理 DML、不维护大量 buffer cache，但 MRP 进程 apply 大事务时极度依赖 PGA 做排序/哈希/临时段操作。SGA 设太大反而挤占 OS 和 PGA 空间，导致 ORA-04030 或被 OOM killer 杀进程。
-
SGA_TARGET建议设为物理内存的 30%～40%，上限不超过 50%；若还跑报表，可上浮至 45%，但必须预留 ≥2GB 给 OS -
PGA_AGGREGATE_TARGET建议设为SGA_TARGET的 30%～50%，且绝对值不低于 2GB（小内存除外） - 必须禁用
MEMORY_TARGET—— 它会让 Oracle 动态挪内存，而 MRP 对 PGA 稳定性敏感，一抖就卡住 - 改完参数后，
SHOW PARAMETER确认已生效，再查v$memory_dynamic_components看实际分配，最后手动重启 MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL→ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
应用连错库：tnsnames.ora 没隔离 SERVICE_NAME
客户端连不上备库、或者连上了却查到主库数据，90% 是因为 SERVICE_NAME 没做区分。主备库如果共用同一个服务名（比如都叫 orcl），TNS 解析后流量仍打到主库，备库完全没被用上。
- 在备库执行：
ALTER SYSTEM SET SERVICE_NAMES='orcl_ro' SCOPE=BOTH - 执行
lsnrctl services，确认输出里有orcl_ro且状态为READY - 客户端
tnsnames.ora单独配一段，SERVICE_NAME必须指定为orcl_ro，不能复用主库的服务名 - 验证：连接后执行
SELECT INSTANCE_NAME, HOST_NAME FROM V$INSTANCE，确保返回的是备库主机名和实例名
网络和传输层拖慢同步：SDU 和 Socket Buffer 没调大
主备之间 redo 传输效率低，会导致备库 SCN 落后，哪怕开了 ADG、内存也够，查询仍看到旧数据。尤其在高吞吐场景（如批量导入、大事务），默认 SDU=2KB 和系统级 socket buffer 极易成为瓶颈。
- 在备库
sqlnet.ora加：DEFAULT_SDU_SIZE=32767；或在tnsnames.ora连接串里加(SDU=32767) - 同步调整
listener.ora中对应 SID 的SDU参数 - 增大 socket 缓冲区：在
tnsnames.ora连接串加(SEND_BUF_SIZE=9375000)(RECV_BUF_SIZE=9375000)，并在listener.ora监听地址里补上相同参数 - OS 层也要调：确认
net.core.rmem_max/wmem_max≥ 9MB，否则 Oracle 设置无效
V$DATAGUARD_STATS.APPLY_LAG 里的估算值；而 SCN 能不能及时推进，取决于 MRP 是否真在跑、内存是否撑得住、网络是否传得快——这三环缺一不可。
