根本原因是memory_target启用自动内存管理，导致sga与pga动态分配失衡；应先调整或禁用memory_target，再合理设置sga_target和pga_aggregate_target。
oracle 12c 启动后 sga 占用过高，根本原因往往不是 sga 本身“失控”，而是 memory_target 参数启用后，oracle 自动在 sga 和 pga 之间分配内存，但默认值可能远超你物理内存的合理配比——尤其在开发机或小内存服务器上，memory_target 常被设为物理内存的 60%~80%，直接导致 sga “吃掉”大部分可用内存。
为什么改 MEMORY_TARGET 比单独调 sga_target 更治本
当 MEMORY_TARGET 非零时，Oracle 启用自动内存管理（AMM），此时 sga_target 和 pga_aggregate_target 实际由系统动态计算并覆盖；你手动设的 sga_target 只会成为下限（soft limit），而 AMM 会根据负载把内存不断往 SGA 倾斜（尤其高并发查询、大量缓存场景）。所以只改 sga_target 很可能无效，甚至触发 ORA-00823 错误（因为 sga_target > MEMORY_TARGET - pga_aggregate_target）。
-
MEMORY_TARGET是总闸门，它决定 SGA + PGA 的上限，必须先关掉或重设它，才能真正约束 SGA - 如果保留 AMM，
MEMORY_TARGET应 ≤ 物理内存 × 0.6（开发环境可压到 2G~4G），且必须 ≥ 当前sga_target+pga_aggregate_target的和 - 若彻底禁用 AMM（更可控），需将
MEMORY_TARGET和MEMORY_MAX_TARGET都设为 0，再单独配sga_target和pga_aggregate_target
MEMORY_TARGET=0 后，SGA 和 PGA 怎么分才不打架
禁用 AMM 后，SGA 和 PGA 完全解耦，但必须手动平衡：SGA 太小会导致频繁物理读、library cache latch 等争用；PGA 太小则排序溢出到临时表空间，拖慢 SQL 执行。关键看业务类型：
- OLTP 类（事务多、SQL 短）：SGA 占 70%~80%，PGA 占 20%~30%。例如总内存 8G →
sga_target=5g,pga_aggregate_target=1.5g - DW/报表类（大排序、哈希连接多）：PGA 可提至 40%，SGA 保持 60%。避免
ORA-04030（进程内存不足） - 注意：
sga_max_size必须 ≥sga_target，且两者差值不宜过大（否则浪费内存预留）；pga_aggregate_limit建议设为pga_aggregate_target的 2~3 倍，防突发内存 spike
执行时最容易踩的三个坑
这些错误会导致实例无法启动，或重启后参数未生效：
- 没备份 spfile：修改前务必运行
create pfile='/tmp/init_bak.ora' from spfile;，否则scope=spfile写错就只能靠恢复 - 参数冲突：如果
MEMORY_TARGET=0，但 spfile 里还残留sga_target和pga_aggregate_target的旧值，Oracle 会忽略它们——必须显式用alter system set ... scope=spfile覆盖 - Linux 下权限问题：
startup失败报ORA-00845: MEMORY_TARGET not supported on this system，大概率是/dev/shm大小不足（需 ≥MEMORY_TARGET），用df -h /dev/shm检查，不够就重挂：mount -t tmpfs -o size=4g tmpfs /dev/shm
最常被忽略的是：调整后别只看 show parameter sga，一定要查 v$sga_dynamic_components 确认各子池（buffer cache、shared pool）是否真按新目标重新分配了——有时 sga_target 降了，但 shared pool 还卡在旧值，说明 AMM 残留或 granule 分配未刷新，得强制 flush shared pool 或重启两次。
