Oracle 19c物理备库默认不启用Standby Result Cache，因共享池未分配内存且RESULT_CACHE_MAX_SIZE=0，需在READ ONLY WITH APPLY状态下设参重启才能生效。
standby result cache 在 oracle 19c 物理备库上默认不启用，且不能直接复用主库的结果缓存；它必须显式开启并独立配置，否则备库上的只读查询无法受益于结果缓存加速。
为什么备库默认没有 Result Cache？
物理备库（Physical Standby）的共享池（Shared Pool）默认不分配 Result Cache 内存区域，RESULT_CACHE_MAX_SIZE 参数在备库实例中仍为 0（即使主库已设为非零值）。这是设计使然：主库的缓存内容不可直接同步到备库，因为结果缓存依赖于精确的执行上下文、绑定变量、会话状态和底层数据一致性——而备库的 SCN 滞后、只读模式、无事务提交点，导致缓存结果无法安全复用。
- 查证方式：
SELECT value FROM v$parameter WHERE name = 'result_cache_max_size'，备库返回 0 是常态，不是配置遗漏 -
V$RESULT_CACHE_STATISTICS在备库中存在但所有计数器为 0，说明缓存未激活 - 即使主库用了
/*+ RESULT_CACHE */提示，备库执行相同 SQL 也不会命中缓存——提示被忽略，除非备库自己启用了 Result Cache
如何在备库启用 Standby Result Cache？
需在备库处于 READ ONLY WITH APPLY 状态下，手动分配内存并重启生效。这不是“打开开关”，而是重新初始化共享池中的缓存子系统。
- 确认备库当前状态：
SELECT open_mode, database_role FROM v$database，必须是READ ONLY WITH APPLY - 设置参数（需重启）：
ALTER SYSTEM SET result_cache_max_size=256M SCOPE=SPFILE（建议值：128–512MB，取决于只读查询负载和共享池剩余空间） - 重启备库：
SHUTDOWN IMMEDIATE→STARTUP，仅此一步才会真正划分内存区域 - 验证是否生效：
SELECT * FROM v$result_cache_statistics中Create Count开始增长，且Find Count> 0 表明缓存已工作
启用后要注意哪些关键限制？
Standby Result Cache 不是主库缓存的镜像，它完全独立运作，但也因此有几处极易踩坑：
- 缓存失效逻辑不同：主库 DML 触发的缓存失效不会传播到备库；备库只对本地查询触发缓存，且依赖关系基于备库当前 SCN 下的对象状态——这意味着同一 SQL 在主备库可能缓存不同结果（尤其当备库延迟较大时）
- 不支持跨 PDB 共享：如果备库含多个 PDB，每个 PDB 的
RESULT_CACHE_MAX_SIZE需单独设置（在各自 PDB 内执行ALTER SYSTEM），且内存不共享 - 与
STANDBY_FILE_MANAGEMENT无关：临时表空间、redo 日志等同步机制不影响 Result Cache，它纯属备库实例级内存配置 - 监控要分开看：主库的
V$RESULT_CACHE_MEMORY和V$RESULT_CACHE_DEPENDENCY对备库无参考价值；备库必须用自己的视图诊断，例如SELECT dependency_type, object_name FROM v$result_cache_dependency JOIN dba_objects USING(object_id)查依赖对象
真正起效的前提是备库持续处于 READ ONLY WITH APPLY 状态且有稳定只读查询流量；如果频繁切换 OPEN/RECOVER 模式，Result Cache 会被反复清空，反而增加开销。别指望它解决同步延迟问题，它只加速“已经到达备库的数据”的重复查询。
