Oracle 11g内存占用过高主因是未启用自动内存管理（AMM），SGA_TARGET和PGA_AGGREGATE_TARGET为0导致回退手动模式；ORA-00845源于/dev/shm空间不足，需扩容至≥MEMORY_TARGET；正确做法是清空SGA_TARGET/PGA_AGGREGATE_TARGET，仅设MEMORY_TARGET与MEMORY_MAX_TARGET，并清除DB_CACHE_SIZE等硬编码参数。
oracle 11g 安装后内存占用过高，不是配置“太高”，而是默认没开自动内存管理，sga_target 和 pga_aggregate_target 都为 0 —— 这会导致 oracle 回退到手动管理模式，但又没显式设任何子组件大小，结果可能触发保守预分配或异常行为，实际表现就是空跑就占满内存、启动慢、甚至报 ora-00845。
ORA-00845：MEMORY_TARGET 不被支持的真正原因
这个错误根本不是 Oracle 自身问题，而是 Linux 的 /dev/shm 大小不够。Oracle 启用 MEMORY_TARGET 时必须用共享内存段（tmpfs），而默认 /dev/shm 通常只有 4GB 或更小。一旦 MEMORY_TARGET 超过它，立刻报错。
- 查当前大小：
df -h /dev/shm - 临时扩容（重启失效）：
sudo mount -o remount,size=6G /dev/shm - 永久生效：编辑
/etc/fstab，把原有/dev/shm行改成类似tmpfs /dev/shm tmpfs size=6G 0 0 - 注意：改完必须
sudo umount /dev/shm && sudo mount /dev/shm才生效，不能只改 fstab 就以为 OK
SGA_TARGET 和 PGA_AGGREGATE_TARGET 设了反而更糟？
在 11g 中，只要显式设置了 SGA_TARGET 或 PGA_AGGREGATE_TARGET，哪怕只设一个，MEMORY_TARGET 就会被绕过——Oracle 会降级为“SGA 自动 + PGA 手动”模式，而 PGA_AGGREGATE_TARGET 默认为 0，导致排序/哈希连接大量走磁盘，临时表空间暴涨，看起来像“内存没用上”，其实是 PGA 被锁死在极小值。
通过IB网关在Interactive Brokers上投资股票/ETF，使用与okx交易相同的人机确认环节，适用于用户请求检查时
- 检查是否被手动设过：
SELECT NAME, VALUE, ISDEFAULT FROM V$PARAMETER WHERE NAME IN ('sga_target', 'pga_aggregate_target') - 如果
ISDEFAULT = 'FALSE'且VALUE != 0，说明你主动关掉了 AMM - 正确做法：清空这两个参数（设为 0 或删掉），只留
MEMORY_TARGET和MEMORY_MAX_TARGET - 别信“SGA_TARGET=1G + PGA_AGGREGATE_TARGET=200M”这种老 10g 配法，11g 下它们会互相打架
MEMORY_TARGET 该设多大才不翻车
别拍脑袋填 8G 或 16G。真实合理值取决于你实际负载，而不是物理内存总量。Oracle 提供了内置建议视图，比任何经验值都准。
- 先确保数据库已运行一段时间（至少几小时以上业务流量），再查：
SELECT * FROM V$MEMORY_TARGET_ADVICE ORDER BY MEMORY_SIZE; - 找
ESTD_DB_TIME最小的那一行对应的MEMORY_SIZE，就是当前负载下的最优值 - 若所有大于当前值的行
ESTD_DB_TIME都不变，说明再加内存也没收益，到顶了 -
MEMORY_MAX_TARGET必须 ≥ 当前MEMORY_TARGET，且是静态参数，改它必须重启；MEMORY_TARGET可在线调，但不能超MEMORY_MAX_TARGET
最常被忽略的一点：哪怕你设了 MEMORY_TARGET，只要 DB_CACHE_SIZE、SHARED_POOL_SIZE 这类底层参数在 spfile/pfile 里非零，Oracle 就会把它们当硬下限，导致 SGA 内部无法动态伸缩——查 V$PARAMETER 看这些值是否被显式写死，是的话得一并清掉。
