ORA-00845报错本质是/dev/shm空间不足，因Oracle 19c启用AMM需将MEMORY_TARGET/MAX_TARGET控制结构存入该tmpfs，而默认大小（64M或2G）常小于实例需求，须通过/etc/fstab显式配置size=参数并挂载生效。
ORA-00845报错本质是/dev/shm空间不足
oracle 19c 启用 amm（automatic memory management）时，必须把 memory_target 或 memory_max_target 的控制结构存进 /dev/shm。这个 tmpfs 挂载点不是“可用物理内存”的代理，而是独立分配的共享内存池——linux 默认只给它 64m 或 2g，而 19c 实例起步就要 2g+，不调必报错。
别被错误信息里的 “not supported on this system” 迷惑：这不是 Oracle 不兼容，而是 /dev/shm 太小，Oracle 在启动早期检查失败后直接退出。
- 先确认是否真由它引起：
df -h /dev/shm和mount | grep shm必须一起看；如果显示64M、2G但你的MEMORY_MAX_TARGET是3G，就是它了 - 查 Oracle 参数要连 sysdba 登录后执行：
show parameter memory_target和show parameter memory_max_target，取两者中较大值（单位字节），再乘以 1.2～1.5 倍作为/dev/shm目标大小 - 注意：某些最小化安装的 Oracle Linux 8/9 或云主机（如 OCI、AWS EC2）可能压根没挂
/dev/shm，df -h /dev/shm会报 “No such file or directory”，这时不能只 remount，得先确保挂载点存在且 fstab 正确
永久修改/etc/fstab必须显式写size=，不能用defaults
/etc/fstab 是唯一能保证 Oracle 启动前就拿到正确 /dev/shm 大小的方式。systemd-tmpfiles、cloud-init 或 Docker 都可能覆盖临时 mount，只有 fstab 能稳住。
常见错误是抄网上的模板写成 tmpfs /dev/shm tmpfs defaults 0 0 —— 这等于没改，因为 tmpfs 的 defaults 不含 size，系统仍按内核默认（通常是 64M）挂载。
- 正确写法（以 4G 为例）：
tmpfs /dev/shm tmpfs size=4G,mode=1777 0 0 - 改完别急着 reboot：
sudo umount /dev/shm && sudo mount /dev/shm立即测试是否生效 - 验证是否真正挂上：
cat /proc/mounts | grep shm必须看到size=4294967296（即 4G 字节）或size=4G；df -h /dev/shm显示 “4.0G” 才算成功 - RHEL/CentOS 7+/Oracle Linux 7+ 用户额外注意：
systemctl mask dev-shm.mount可能被 systemd 自动启用，导致 fstab 生效失败；执行systemctl status dev-shm.mount看是否 active，若 masked 则需先systemctl unmask dev-shm.mount
Docker/Podman 容器里 Oracle 19c 报 ORA-00845 怎么办
宿主机上把 /dev/shm 改到 8G 没用——容器内 /dev/shm 是独立挂载的，大小默认仅 64M。Docker 不继承宿主机的 tmpfs 设置。
必须在 docker run 或 podman run 时显式指定 --shm-size，且该值要 ≥ Oracle 实例的 MEMORY_MAX_TARGET（建议 ×1.5）。
- Docker 示例：
docker run --shm-size=4G -v /path/to/oradata:/opt/oracle/oradata ... oracle/database:19.3.0-ee - Podman 示例：
podman run --shm-size=4G ... - 如果用 docker-compose.yml，写成：
shm_size: "4gb"（注意单位是gb，不是G） - Kubernetes 中需在
securityContext下配shmSize: 4Gi，并确保 Pod 使用的 RuntimeClass 支持大 shm
SELinux、UID 过大、ksm 都可能让/dev/shm“看起来够却用不了”
即使 df -h /dev/shm 显示 4G，Oracle 仍报 ORA-00845，就得排查底层拦截。
SELinux 默认禁止 Oracle 访问 /dev/shm，尤其在启用了 virtualization 相关策略的 RHEL 系统上；UID > 65535（如某些自动创建用户脚本生成的 UID）也会触发内核级拒绝；ksm（Kernel Samepage Merging）则会抢占大页内存，干扰 AMM 初始化。
- 检查 SELinux：
getsebool virt_use_shm，若输出virt_use_shm --> off，运行setsebool -P virt_use_shm on - 检查 Oracle 用户 UID：
id -u oracle，若 ≥ 65536，重建用户并设useradd -u 5000 oracle（值必须 - 临时禁用 ksm：
echo 0 | sudo tee /sys/kernel/mm/ksm/run；永久禁用加ksm_enabled=0到/etc/default/grub的GRUB_CMDLINE_LINUX行后更新 grub - 权限一般不用动，但若手动
chown过/dev/shm，确认ls -ld /dev/shm输出含drwxrwxrwt，否则chmod 1777 /dev/shm
最常被忽略的是挂载时机和多实例竞争：一台机器跑多个 Oracle 实例时，/dev/shm 大小必须 ≥ 所有实例的 MEMORY_MAX_TARGET 之和，而不是单个最大值。这点在测试环境容易漏，上线前务必按实际部署拓扑核算。
