ORA-00845错误本质是/dev/shm空间不足，因Oracle 11g起启用AMM需将MEMORY_TARGET/MAX_TARGET控制结构存入该tmpfs，而默认大小（64M或2G）常小于实例需求，须通过/etc/fstab显式配置size=参数并挂载生效。
ORA-00845 错误不是 Oracle 不支持你的系统，而是 /dev/shm 太小，撑不住你设的 MEMORY_TARGET 或 MEMORY_MAX_TARGET。
/dev/shm 空间不足是主因
- Oracle 11g 起启用 AMM（Automatic Memory Management）后，必须把内存管理结构存进
/dev/shm—— 它是 tmpfs 类型的内存文件系统，不是物理内存代理，而是独立分配的共享内存池 - 默认大小常为 64M（旧内核）或 2G（某些发行版），但 Oracle 19c 实例起步就要求 2G+，不调必报错
- 错误信息里 “not supported on this system” 是误导性提示，实际就是
/dev/shm不够用
验证方法：
-
df -h /dev/shm查当前挂载大小 -
mount | grep shm确认是否挂载、参数是否含size= - 登录数据库（若能）执行：
show parameter memory_target和show parameter memory_max_target，取较大值再乘 1.2～1.5 倍，就是/dev/shm最低目标大小
/dev/shm 没挂载或被 systemd 掩盖
- 某些最小化安装的 Oracle Linux 8/9、AWS EC2 或 OCI 云主机，
/dev/shm根本没挂载，df -h /dev/shm直接报 “No such file or directory” - RHEL/CentOS 7+ 及 Oracle Linux 7+ 中，
systemctl mask dev-shm.mount可能被自动启用，导致/etc/fstab配置失效 - 执行
systemctl status dev-shm.mount查看状态；若显示masked，需先systemctl unmask dev-shm.mount
/etc/fstab 配置写错导致无效
- 常见错误：抄模板写成
tmpfs /dev/shm tmpfs defaults 0 0——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或size=4G；df -h /dev/shm显示 “4.0G”
Docker/Podman 容器里启动 Oracle 19c 也报 ORA-00845
- 宿主机上改
/etc/fstab对容器无效；容器内的/dev/shm默认只有 64M - 启动容器时必须显式挂载更大空间：
docker run --shm-size=4G ...或podman run --shm-size=4G ... - 若用 Kubernetes，需在
securityContext中设置shmSize: 4Gi，否则 Pod 内的/dev/shm仍为默认值
最易被忽略的是：临时 mount -o remount,size=... 在重启或容器重建后全部丢失，只有 /etc/fstab（宿主机）或 --shm-size（容器）才能稳住配置。
