备库上直接修改SGA_TARGET是安全的，但必须确保未启用MEMORY_TARGET且SGA_TARGET不超过SGA_MAX_SIZE；若SGA_MAX_SIZE不足需重启调整，同时需检查OS级共享内存参数及大页配置。
备库上直接改 SGA_TARGET 是安全的，但必须避开 MEMORY_TARGET
Oracle 物理备库（Physical Standby）默认运行在 READ ONLY 或 READ ONLY WITH APPLY 模式下，其 SGA 配置与主库一致，且内存参数本身不参与日志应用逻辑。只要没启用 AMM（MEMORY_TARGET），SGA_TARGET 就是动态可调参数，修改后立即生效，不影响 MRP（Managed Recovery Process）进程持续应用归档日志。
关键限制只有一条：SGA_TARGET 不能超过当前实例的 SGA_MAX_SIZE —— 而后者是静态参数，需重启才生效，所以你得先确认备库的 SGA_MAX_SIZE 是否足够大。如果不够，必须停库改 SGA_MAX_SIZE 再重启，否则后续调高 SGA_TARGET 会报 ORA-02097。
- 查当前值：
SHOW PARAMETER sga_max_size和SHOW PARAMETER sga_target - 若
SGA_MAX_SIZE是 4G，你想调到 12G，就必须先停库、改 SPFILE、再启库 - 若
SGA_MAX_SIZE已是 16G，那直接ALTER SYSTEM SET SGA_TARGET = 12G SCOPE=BOTH即可，MRP 不中断
MEMORY_TARGET 在备库上根本不能开
物理备库不支持自动内存管理（AMM）。一旦你在备库上设了 MEMORY_TARGET，实例启动时就会报 ORA-00844 或 ORA-00851，根本起不来；即使侥幸启动，在日志应用过程中也极可能因内存重分配失败导致 MRP 异常终止。
检查方法：SHOW PARAMETER memory_target。如果返回非零值，立刻清掉：
ALTER SYSTEM RESET MEMORY_TARGET SCOPE=SPFILE;- 重启备库（这是唯一办法）
- 确认
MEMORY_MAX_TARGET和MEMORY_TARGET都为0再继续
调整后要盯住 Buffer Cache 命中率和 MRP 延迟
调大 SGA 不等于性能变好。重点看两个指标是否同步改善：
-
Buffer Cache Hit Ratio：用SELECT 1-(physical.value–direct.value–lobs.value)/logical.value FROM ...算，目标 > 90%。如果调完没变化，说明热点数据没进缓存，可能是 SQL 访问模式或绑定变量问题，不是内存大小的事 -
APPLY LAG：查SELECT * FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag';，确保没因内存抖动导致 MRP 处理变慢 - 观察
V$SGASTAT中free memory是否长期低于 100MB —— 过度压缩 free space 可能引发 shared pool 碎片，反而触发硬解析上升
别信“调大就稳”的直觉，备库 SGA 有隐性天花板
物理备库的 SGA 实际有效上限，往往卡在操作系统层面：Linux 的 shmmax 和 shmall 必须覆盖新 SGA 大小，否则 startup mount 阶段就失败；而 Oracle 11g 及以后版本，SGA_MAX_SIZE 超过 4GB 时还要求内核开启 USE_LARGE_PAGES=only，否则大量内存会 fallback 到小页，反而拖慢日志应用速度。
最常被忽略的一点：备库通常不跑业务查询，DB_CACHE_SIZE 和 SHARED_POOL_SIZE 没必要照搬主库。比如主库 SHARED_POOL_SIZE 设了 4G 是为了撑住几千个并发 SQL，备库只需维持 MRP 和少量监控语句，1G 往往更稳。
