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 显式声明顺序。
