ORA-00845 根本原因是 /dev/shm 空间不足，Oracle 11g+ 启用 MEMORY_TARGET 时依赖其存放 SGA/PGA 控制结构；需永久修改 /etc/fstab 中 tmpfs 挂载大小（如 size=4G），并确保挂载时机早于 Oracle 启动。
ORA-00845 报错本质是 /dev/shm 空间不足
oracle 11g 及以后版本启用 memory_target 或 memory_max_target 时，会依赖 /dev/shm（tmpfs 类型的共享内存）存放 sga/pga 的自动内存管理结构。报错不是 oracle 配置错了，而是底层 tmpfs 挂载空间太小，不够 oracle 启动时分配所需页表和控制区。
常见错误现象：ORA-00845: MEMORY_TARGET not supported on this system，即使 memory_target 设为 1G 也会触发——因为 Oracle 启动阶段需要预留比配置值更大的临时共享内存空间（含页表、ASMM 元数据等）。
-
/dev/shm默认挂载大小通常是 2G（RHEL/CentOS 6+），但 Oracle 实际需要 ≈ 1.2×MEMORY_TARGET的可用空间 - 不能只靠
mount -o remount,size=4G /dev/shm临时生效：重启后丢失，且 Oracle 实例启动顺序早于多数 systemd mount 单元，容易抢在重挂前就读取了旧 size - 若系统启用了
systemd-tmpfiles或使用了/etc/fstab之外的挂载机制（如 cloud-init），单纯改 fstab 可能不生效
永久调整 /dev/shm 大小必须改 /etc/fstab
这是最可靠、兼容性最好的方式，适用于 RHEL/CentOS 7+/Oracle Linux 7+，也兼容大多数 systemd 发行版。关键不是“能不能调”，而是“改哪里才真正起作用”。
操作步骤：
- 先确认当前挂载状态：
mount | grep shm，看是否已挂载及当前 size - 编辑
/etc/fstab，找到或添加这一行：tmpfs /dev/shm tmpfs size=4G,mode=1777 0 0（把4G换成你实际需要的值，建议 ≥ 1.5×MEMORY_TARGET） - 执行
sudo umount /dev/shm && sudo mount /dev/shm立即生效（注意：正在运行的 Oracle 实例不会中断，但下次启动才用新 size） - 验证：
df -h /dev/shm和mount | grep shm必须显示新 size；再检查cat /proc/mounts | grep shm是否带size=参数
注意：不要用 defaults 替代显式 size=，tmpfs 的 defaults 不包含 size，结果仍是默认 2G。
Oracle 启动失败仍可能因 /dev/shm 挂载时机不对
某些最小化安装或容器化环境（如 Oracle 在 Docker 中、或使用 cloud-init 初始化的云主机），/dev/shm 可能被 late-mounted，导致 Oracle 的 oraagent 或 init.ora 解析阶段读到的是空或极小的 shm。
- 检查
systemctl status proc-sys-fs-binfmt_misc.automount或systemd-analyze blame | grep shm，确认/dev/shm挂载是否晚于oracle.service - 临时 workaround：在 Oracle 启动脚本（如
/etc/init.d/oracle或 systemd service 的ExecStartPre）里加一行：mount -o remount,size=4G /dev/shm（仅应急，非长期方案） - 更稳妥的做法：在 systemd service 文件中加
After=local-fs.target并确保Wants=local-fs.target，避免依赖未就绪的挂载点
这个坑常被忽略——fstab 写对了，但 Oracle 还是报 ORA-00845，八成是挂载顺序没卡准。
不用 MEMORY_TARGET 就能绕过？可以，但代价明确
如果实在无法调整 /dev/shm（比如受限于云厂商模板、无 root 权限），唯一合法替代是关闭自动内存管理，改用静态 SGA/PGA：
- 把
MEMORY_TARGET和MEMORY_MAX_TARGET全设为0 - 显式设置
SGA_TARGET、SGA_MAX_SIZE、PGA_AGGREGATE_TARGET - 注意：失去 ASMM（自动共享内存管理）能力，buffer cache、shared pool 等不再动态伸缩，DBA 必须手动调优
- 性能影响：OLTP 类负载在并发波动大时可能更易出现 latch free 或 shared pool fragmentation
这不是“降级方案”，而是架构选择变更——自动内存管理不是可选项，它是 /dev/shm 存在的前提条件。绕过去，就得承担运维复杂度上升的后果。
