v$sga_target_advice仅在asmm模式（memory_target=0且sga_target>0）下有效；若memory_target>0则启用amm，其建议参考价值低。需先查参数确认模式，再结合sga_size_factor=1行的estd_db_time和estd_physical_reads评估调优效果。
查 v$sga_target_advice 前先确认当前模式
如果 memory_target > 0，说明启用了自动内存管理（amm），此时 sga_target 是由 oracle 自动推导的，v$sga_target_advice 的建议值参考价值低——它只在 asmm（memory_target=0 且 sga_target>0）下真正有效。
执行这条语句快速判断：
SELECT name, value FROM v$parameter WHERE name IN ('memory_target', 'sga_target');
若结果是 memory_target=0 且 sga_target=5200M，才继续看 SGA 建议；否则应优先考虑改用 memory_target 或检查是否误启 AMM。
解读 v$sga_target_advice 输出的关键列
运行 SELECT * FROM v$sga_target_advice ORDER BY sga_size; 后，重点关注三列：
-
SGA_SIZE_FACTOR = 1对应的行，是当前sga_target值（比如 580 MB） -
ESTD_DB_TIME：预估完成当前负载所需的数据库时间，数值越小越好 -
ESTD_PHYSICAL_READS：预估物理读次数，下降趋势说明缓存效率提升
常见误读：
- 看到
ESTD_DB_TIME在某个更大SGA_SIZE下没再下降（如从 725 MB 到 870 MB 时值不变），就认为“再加也没用”——这没错，但得确认该平台是否真有足够空闲内存支撑这个大小 - 忽略
SGA_SIZE_FACTOR 的行：如果当前值偏大（比如 ESTD_DB_TIME 反而比 0.75 倍时还高），说明当前 <code>sga_target已超配，反而拖慢性能
动态调整 sga_target 的实操边界
ASMM 模式下可在线调 sga_target，但受两个硬限制：
-
sga_target不能超过sga_max_size（静态参数，改完需重启） -
sga_target必须是 4MB 的整数倍（Oracle 内部对齐要求） - 若
sga_max_size == sga_target（常见于 RAC 升级后未扩容），必须先设更大的sga_max_size并重启，否则ALTER SYSTEM SET sga_target=6G会报错ORA-02097: parameter cannot be modified because specified value is invalid
安全操作顺序：
ALTER SYSTEM SET sga_max_size = 6G SCOPE=SPFILE;<br>SHUTDOWN IMMEDIATE;<br>STARTUP;<br>ALTER SYSTEM SET sga_target = 6G SCOPE=BOTH;
AWR 报告里容易被忽略的配套验证点
单看 v$sga_target_advice 不够，必须交叉验证 AWR 中三项指标：
- Buffer Cache Hit Ratio 是否稳定 ≥ 95%？低于 90% 且
v$sga_target_advice显示加大 SGA 能显著降物理读，才值得调 - Shared Pool Free Memory（单位：bytes）是否长期 sga_target 没用，得单独调
shared_pool_size - DB Time 中 “SQL execute elapsed time” 占比是否高？如果占比低但 DB Time 高，问题可能在 I/O 或锁，不是 SGA 不够
最常踩的坑：在 OLAP 类查询频繁的库上盲目按建议把 sga_target 加到 8G，结果 pga_aggregate_target 不足，大量临时表空间溢出，v$pgastat 里 extra_bytes_read/written 猛涨——SGA 和 PGA 必须协同看。
