SGA_TARGET设为0将禁用自动共享内存管理（ASMM），Oracle不再动态调整shared_pool_size、db_cache_size等，完全依赖手动配置；此时SGA_TARGET失效，但SGA_MAX_SIZE仍作为上限有效。
SGA_TARGET 设为 0 会怎样？
设为 0 表示禁用自动共享内存管理（asmm），oracle 不再动态调整 shared_pool_size、db_cache_size 等内部组件，而是完全依赖你手动设置的各池大小。这时候 sga_target 失效，但 sga_max_size 仍起作用——它只是上限，不参与分配逻辑。
常见错误现象：DB 启动时报 ORA-00843: SGA_TARGET must be greater than 0，往往是因为你启用了 MEMORY_TARGET 或 MEMORY_MAX_TARGET，而 Oracle 要求两者互斥且不能同时为 0；或者你在 12c+ 的多租户环境中对 PDB 单独设了 SGA_TARGET=0，但 CDB 级未配妥。
- 使用场景：老系统迁移、需要精确控制 shared pool 和 buffer cache 比例时才手动关 ASMM
- 参数差异：
SGA_TARGET可在线修改（只要不超过SGA_MAX_SIZE），但设为0后再想开 ASMM，必须重启实例 - 性能影响：关闭 ASMM 后，如果 workload 突然变重（比如大量硬解析），
shared_pool不会自动扩容，容易触发ORA-04031
PGA_AGGREGATE_TARGET 和实际 PGA 使用量差很多？
这个参数只控制“自动 PGA 管理”的总预算，并不强制限制进程实际申请的 PGA 内存。Oracle 允许单个会话临时突破该值（尤其在排序、哈希连接、位图合并等操作中），只要整体平均不长期超标即可。所以你看到 V$PGASTAT 里 total PGA allocated 是 PGA_AGGREGATE_TARGET 的 2–3 倍，不一定异常。
真正卡住你的往往是 OS 层面的限制：比如 Linux 的 vm.overcommit_memory=2 + vm.overcommit_ratio 设置过低，或容器环境没配 --memory，导致进程 malloc 失败后报 ORA-04030: out of process memory，而不是 Oracle 自己抛错。
- 检查方法：对比
V$PGASTAT的total PGA used for auto workareas和total PGA allocated，前者才反映 ASMM 真正调度的部分 - 参数差异：
PGA_AGGREGATE_TARGET在 12c+ 多租户中可按 PDB 单独设（需 CDB 级启用ENABLE_PLUGGABLE_DATABASE），但子句是ALTER PLUGGABLE DATABASE ... SET PGA_AGGREGATE_TARGET = ... - 兼容性注意：11g R2 开始支持自动 PGA 管理，但若 SQL 中用了
/*+ USE_HASH(a) */且没给足够_hash_join_enabled预留空间，仍可能 fallback 到临时表空间
SGA_TARGET + PGA_AGGREGATE_TARGET 总和能超物理内存吗？
能，而且经常如此——但风险极高。Oracle 只校验启动时是否满足最低要求（比如 SGA_MAX_SIZE + PGA_AGGREGATE_TARGET ≤ /proc/meminfo 中 MemTotal × 0.8 左右），后续运行中完全不管 OS 是否真能扛住。一旦两者加起来接近或超过物理内存，就会触发 OS OOM killer 杀掉 ora_* 进程，日志里只留一句 Killed process xxx (oracle)，没有 Oracle 错误码。
更隐蔽的问题是 swap：即使没 OOM，频繁换页会让 db file scattered read 等等待事件飙升，AWR 里看 % DB time waiting 里 direct path read/write 异常高，其实是底层内存抖动。
- 安全建议：生产库保守按物理内存的 60%–70% 分配 SGA+PGA 总和，剩余留给 OS、其他进程、page cache
- 监控要点：定期查
/proc/meminfo的MemAvailable（不是MemFree），持续低于 1G 就得预警 - 容器部署特别注意：Docker/K8s 中
memory.limit_in_bytes必须显式大于SGA_MAX_SIZE + PGA_AGGREGATE_TARGET，否则 cgroup 会直接 oom_kill
改完参数不生效？别忘了 MEMORY_MAX_TARGET
SGA_TARGET 和 PGA_AGGREGATE_TARGET 的可调上限，受制于 MEMORY_MAX_TARGET（如果启用 AMM）或 SGA_MAX_SIZE（如果只用 ASMM）。很多人改了 SGA_TARGET 发现无法超过某个值，翻来覆去查文档，最后发现 MEMORY_MAX_TARGET 还停在初始安装时的默认值（比如 1G），而 SGA_TARGET 想设到 4G，Oracle 直接静默截断。
这个参数只能在实例关闭时修改，且修改后必须重启才能生效。线上改它等于计划停机，不是 ALTER SYSTEM 能搞定的事。
- 验证命令：
SHOW PARAMETER memory_max_target和SHOW PARAMETER sga_max_size必须都查 - 容易踩的坑：在 12c+ 中混用
MEMORY_TARGET和SGA_TARGET，Oracle 会忽略后者并报ORA-00837: MEMORY_TARGET not supported on this system（某些内核版本或缺 hugepage 支持） - 真实限制链：
SGA_TARGET ≤ SGA_MAX_SIZE ≤ MEMORY_MAX_TARGET（如果启用了 AMM），三者关系必须理清，否则任何调整都是徒劳
MEMORY_MAX_TARGET 和 SGA_MAX_SIZE 的隐式绑定，以及 OS 层面对“内存超卖”的零容忍——Oracle 参数再准，也救不了被 OOM killer 清退的进程。 
