sga与pga比例依业务类型动态调整：oltp推荐sga:pga≈60%–80%:20%–40%，olap则为50%:50%，混用场景取60%:40%为起点；须启用memory_target统一自动管理，设为物理内存70%–80%，并依据v$pgastat和v$sgastat实际指标持续调优。
sga 和 pga 的比例不是固定值，得看你的业务类型
oltp 系统（比如交易型应用）要高频访问少量数据、并发会话多，sga 需要更大——通常占总 oracle 内存的 60%–80%，pga 只需 20%–40%；olap 或 dss 类系统（比如报表、批量计算）大量排序、哈希连接，pga 必须拉高，常见配比是 sga:pga = 50%:50%。混用场景取中间值（如 60%:40%）只是起点，不能直接套用。
关键判断依据是实际负载：如果 v$pgastat 中 cache hit percentage 低于 90%，或 workarea executions - multipass 明显上升，说明 PGA_AGGREGATE_TARGET 不够；如果 v$sgastat 显示 free memory 长期接近 0，且 physical reads 持续偏高，SGA 就该加了。
别硬设 sga_target 和 pga_aggregate_target，先开自动内存管理
Oracle 11g 起支持统一自动管理，用 memory_target 代替分开调两个参数。只要操作系统内存充足，优先设这个：
-
memory_target设为物理内存的 70%–80%，但必须 ≤memory_max_target -
memory_max_target是上限，设为和memory_target相同或略大，避免重启才能扩容 - 确保
statistics_level='TYPICAL'（默认），否则自动管理不生效 - 关掉手动组件参数：把
sga_target、pga_aggregate_target、shared_pool_size等全设为 0 或删掉，让 Oracle 自主分配
手动拆分 SGA/PGA 只在特殊场景有用（比如容器环境限制单进程内存），日常运维反而容易失衡。
调整后必须验证，而不是只看参数生效
改完参数重启实例，下一步是盯住真实运行指标：
- 查
v$pgastat：重点看aggregate PGA target parameter（是否是你设的值）、total PGA allocated（实际用了多少）、cache hit percentage（低于 90% 就危险） - 跑
SELECT name, value FROM v$sga确认各组件（Database Buffer Cache、Shared Pool）确实按预期增长，不是全堆在某一块 - 观察
v$sysstat中physical reads和db block gets的比率，下降才说明缓存有效；如果sorts (disk)比sorts (memory)高，PGA还不够 - 别信任务管理器里 Oracle 进程的“内存占用”——那是虚拟地址空间，看
/proc/pid/status（Linux）或Process Explorer的 Working Set 才是真实物理内存
最容易被忽略的坑：OS 内存预留和 swap 干扰
Oracle 实例内存不是孤立存在的。即使你设了 memory_target=12G，也得给 OS 至少留 2–4G（尤其 Linux 下 vm.swappiness=1 仍可能触发 swap）。
常见翻车点：
-
ulimit -m或ulimit -v限制过严，导致 Oracle 启动时 silently 截断内存分配 - 启用了 AMM（
memory_target）但没关掉USE_LARGE_PAGES=TRUE，结果因 hugepage 分配失败退回到普通页，性能反降 - 在虚拟机里没关透明大页（
transparent_hugepage），和 Oracle 的内存管理冲突，引发周期性卡顿 -
pga_aggregate_target设太高，但临时表空间（temp）文件太小，SQL 排序被迫写磁盘，监控却显示 PGA “够用”
真正稳的配置，永远是从 OS 层确认可用内存 → 设 memory_target → 看 v$pgastat 和 v$sgastat 实际分配 → 跑典型 SQL 验证逻辑读/物理读比，三步缺一不可。
