为什么Oracle 12c启动遇到ORA-00845_通过调整/dev/shm共享内存大小

ORA-00845 根本原因是 /dev/shm 空间小于 MEMORY_TARGET 或 MEMORY_MAX_TARGET 中较大值，Oracle 启动时拒绝加载 AMM；需用 df -h /dev/shm 和 show parameter memory_target/max_target 定位，永久修改 /etc/fstab 中 tmpfs size 参数（建议 ≥1.5×较大值），并排查 SELinux、容器限制及挂载时机问题。

ora-00845 不是 oracle 配置错了，而是 /dev/shm 这个 tmpfs 挂载点空间小于 memory_target 或 memory_max_target 中的较大值，oracle 启动时直接拒绝加载 amm（automatic memory management）。

确认 /dev/shm 当前大小和 Oracle 内存参数

先别急着改配置，用两行命令快速定位是否真踩中这个坑：

• 运行 df -h /dev/shm —— 如果显示 64M、512M 或明显小于你的 MEMORY_TARGET，就是它了
• 以 sysdba 登录后执行 show parameter memory_target 和 show parameter memory_max_target，记下两个值（单位是字节，但比较时可直接按 GB 看）
• 注意：Oracle 实际需要的 /dev/shm 空间 ≈ 1.2×max(MEMORY_TARGET, MEMORY_MAX_TARGET)，不是“刚好相等”就够

永久修改 /etc/fstab 是唯一可靠方式

临时挂载 mount -o remount,size=4G /dev/shm 重启就丢，且 Oracle 启动常早于 systemd 的 mount 单元，容易抢在重挂前读取旧 size。必须走 /etc/fstab：

• 编辑 /etc/fstab，添加或修正这一行：tmpfs /dev/shm tmpfs size=4G,mode=1777 0 0（把 4G 换成你计算出的目标值，建议 ≥ 1.5× 较大内存参数）
• 不能写成 defaults —— tmpfs 的 defaults 不含 size=，结果仍是默认 64M 或 2G（取决于发行版）
• 改完后立即测试：sudo umount /dev/shm && sudo mount /dev/shm，再跑 df -h /dev/shm 和 mount | grep shm 确认 size 已生效
• 某些 RHEL/CentOS/Oracle Linux 7+ 环境会由 systemd-tmpfiles 覆盖 fstab 设置，需同步执行：sudo systemctl mask dev-shm.mount

容器、SELinux 和 ksm 是隐形拦路虎

即使 df -h /dev/shm 显示大小正确，Oracle 仍报 ORA-00845，大概率是底层机制在“看不见的地方”卡住了：

• Docker/Podman 容器内 Oracle：宿主机改 /dev/shm 完全无效，必须启动容器时显式加 --shm-size=4G
• SELinux 启用状态下，Oracle 可能被禁止访问扩展后的 shm，检查：getsebool virt_use_shm，若为 off，运行 setsebool -P virt_use_shm on
• Oracle Linux 上若启用了 ksm（Kernel Samepage Merging），可能干扰大页共享内存分配，临时禁用：echo 0 | sudo tee /sys/kernel/mm/ksm/run
• 验证权限：ls -ld /dev/shm 应显示 drwxrwxrwt，且 oracle 用户属组能写；手动 chown 过的要复位

最易被忽略的是挂载时机 —— /dev/shm 必须在 Oracle 实例启动前完成挂载，而 cloud-init、minimal systemd 配置或某些容器初始化流程会让它 late-mounted，导致 Oracle 读到的是空或极小的 shm。查 systemd-analyze blame | grep shm，如果挂载耗时排在 oracle.service 之后，就得调整依赖或用 Before=oracle.service 显式声明顺序。