ORA-00845错误主因是/dev/shm空间不足，需先检查df -h /dev/shm大小是否小于memory_target值，再通过mount -o remount,size=2G调整，并确认/proc/mounts中生效及排除Java等进程占满干扰。
oracle 11g 启动失败，很大概率不是参数文件或 sid 搞错了，而是 /dev/shm 空间根本不够 —— 它连 oracle 的共享内存段都分配不出来，直接拒绝启动。
ORA-00845 报错时先别急着改 initorcl.ora
看到 ORA-00845: Memory target not supported on this system，第一反应不该是找参数文件路径，而是立刻查 /dev/shm 大小。这个错误不是 Oracle 在“报错”，是在“拒绝启动”：它读取了 memory_target 或 memory_max_target（比如设成了 2G），再一检查 /dev/shm 只有 64M，就直接退出，连参数文件都不继续读了。
- 执行
df -h /dev/shm，如果输出是64M或明显小于你的memory_target值，就是它了 - 查 Oracle 实际要多少：
sqlplus / as sysdba→SHOW PARAMETER memory_target和SHOW PARAMETER memory_max_target，取两者中较大者（单位是字节，但挂载时用size=2G这种写法） - 注意：
ipcs -m查的是 System V 共享内存，不占/dev/shm；真正占这里的，是 POSIX 共享内存对象（/dev/shm/ora_*文件）
临时调大 /dev/shm 但 Oracle 还是报 ORA-00845
执行 sudo mount -o remount,size=2G /dev/shm 后仍报错，说明挂载没真正生效，或者被其他机制覆盖了。
- 运行
cat /proc/mounts | grep shm，确认输出里有size=2097152k（即 2G），而不是size=65536k - RHEL/CentOS 7+ 默认用
systemd-tmpfiles管理/dev/shm，即使改了/etc/fstab，也会被重置；需同时执行sudo systemctl mask dev-shm.mount - 某些 Oracle Linux 发行版启用了
ksm（Kernel Samepage Merging），会干扰大页共享内存分配，临时关掉：echo 0 | sudo tee /sys/kernel/mm/ksm/run - 容器环境（Docker/Podman）下，宿主机改
/dev/shm对容器内完全无效；必须显式加--shm-size=2G启动容器
Java 或其他进程把 /dev/shm 塞满了，Oracle 启动时“莫名失败”
Oracle 启动前，/dev/shm 已被其他程序写满（比如 Java 应用误配 java.io.tmpdir=/dev/shm，或 Python 多进程残留 /dev/shm/psm_*），会导致 Oracle 分配共享内存失败，且不提示具体原因，只报 ORA-00845 或静默退出。
- 手动清理（谨慎！）：
sudo rm -f /dev/shm/ora_* /dev/shm/PostgreSQL.* /dev/shm/redis.*，避免删正在使用的文件（可用lsof +D /dev/shm检查） - 查谁在狂写：
ls -lt /dev/shm | head -20看最新文件名和时间戳，结合进程名判断来源 - Java 应用严禁将
java.io.tmpdir指向/dev/shm；Docker 启动 Java 服务时，应显式挂载独立 tmp 目录，如-v /tmp/java-tmp:/tmp - 定时清理旧文件更可靠：
find /dev/shm -name ".*" -mmin +60 -delete 2>/dev/null（每小时清一次 60 分钟前创建的隐藏文件）
真正麻烦的不是调大小，而是多个服务共用一个 /dev/shm 时，谁写多一点、谁清理不及时、谁在容器里被隔离——这些细节不盯住，调完 size=2G 下周照样崩。
