Oracle 19c启动强制校验shmmax≥MEMORY_TARGET且无fallback，而11g校验宽松、支持SGA分段与IPC回退；RHEL 8+/openEuler等系统还受cgroup、SELinux、/dev/shm挂载参数三重影响。
因为 Oracle 11g 和 19c 对共享内存（SGA）的管理机制、默认内存模式及系统依赖发生了实质性变化，kernel.shmmax 不再只是“够大就行”，而是直接参与启动校验逻辑和内存分配路径选择。
Oracle 19c 启动时强制校验 shmmax 是否 ≥ MEMORY_TARGET
19c 默认启用自动内存管理（AMM），即依赖 MEMORY_TARGET 或 MEMORY_MAX_TARGET。此时 Oracle 必须通过 /dev/shm 分配整块内存——而 shmmax 必须 ≥ 这个值，否则启动直接失败，报 ORA-00845。
- 11g 即使启用了 AMM，对
shmmax的校验较宽松；部分场景下会 fallback 到传统共享内存（System V IPC）路径，只要sga_max_size≤shmmax就可能绕过错误 - 19c 彻底移除 fallback 路径，
shmmax不达标就拒绝启动，不给“碰运气”机会 - 验证方式：
cat /proc/sys/kernel/shmmax与show parameter memory_target对比，单位要统一（字节）
11g 允许 SGA 拆分，19c 更倾向单段连续分配
11g 在非 AMM 模式（手动设置 sga_target）下，SGA 可被拆分为多个共享内存段（如 shared pool、buffer cache 各占一段），因此 shmmax 只需 ≥ 最大的那一段（通常是 buffer cache），而非整个 SGA。
- 19c 的内存管理器更激进地尝试单段分配，尤其在启用 HugePages 但未正确配置时，会回退到要求
shmmax≥ 总 SGA - 典型表现：同为 32GB SGA，11g 可能只要
shmmax=16G就能启动；19c 常需设为32G甚至36G（留余量） - 查当前实际使用：
ipcs -m | awk '$5 ~ /^[0-9]+$/ {sum += $5} END {print sum}'
RedHat/CentOS 系统演进放大了参数敏感性
从 CentOS 7 到 RHEL 8/9 或 openEuler，内核对共享内存的管控逻辑收紧，shmmax 不仅影响 Oracle，还与 systemd 的资源限制、cgroup v2 冲突策略联动。
- RHEL 8+ 默认启用 cgroup v2，若未显式为 oracle 用户配置 memory.max，则
shmmax实际生效值可能被 silently capped - openEuler 22.03 明确要求禁用 transparent_hugepage，否则即使
shmmax足够，ORA-27102仍可能因页表映射失败触发 - 检查是否被 cgroup 限制：
cat /sys/fs/cgroup/memory/memory.max（若为 max，通常无限制；若为数字，需调整）
真正容易被忽略的是：19c 下 shmmax 不仅要算“够不够”，还要看“能不能被 Oracle 看见”——它可能被 SELinux、cgroup、/dev/shm 挂载参数（如 size=）三重覆盖。改完 /etc/sysctl.conf 后，务必验证 ipcs -lm 输出的 “max seg size” 是否已更新，而不是只信 sysctl kernel.shmmax 返回值。
