ORA-27102启动失败主因是vm.nr_hugepages配置错误或配套参数缺失，必须用Oracle官方脚本$ORACLE_HOME/rdbms/install/hugepages_settings.sh在已STARTUP实例上运行，取推荐值再上浮5%并向上取整，同时配齐vm.hugetlb_shm_group、kernel.shmmax/shmall、memlock unlimited及禁用THP，且HugePages_Rsvd>0才真正生效。
ora-27102 启动失败，八成不是内存不够，而是 vm.nr_hugepages 没配对或配套参数缺失——改完就跑 startup 是无效的，必须验证 hugepages_rsvd > 0 才算真正生效。
怎么算对 vm.nr_hugepages 值（别手算）
直接用 sga_max_size / 2048 得到的数字，99% 会翻车。Oracle SGA 实际占用大页数包含保留区、IPC 共享段、LMS/LMD 的 buffer、内核向上取整开销，实测多出 20～40 页很常见。
- 必须在数据库已
STARTUP状态下运行 Oracle 官方脚本：$ORACLE_HOME/rdbms/install/hugepages_settings.sh（注意是install/，不是admin/） - 以
oracle用户执行，且该用户需能读取/proc/<pid>/maps（ps -ef | grep pmon确认进程存在） - 从输出中提取
Recommended setting: vm.nr_hugepages=XXXX这一行，忽略其他说明文字 - 把该值再上浮 5%，并向上取整：比如脚本输出
3120，实际设为3276 - 若节点有多个实例（如 RAC 双实例或主库+ADG），分别运行脚本，把各推荐值相加后再上浮 5%
只改 vm.nr_hugepages 为什么还是失败
Oracle 启动时会校验四项参数是否同时就位，缺一不可。仅写 vm.nr_hugepages 到 /etc/sysctl.conf，大概率静默降级回普通页——此时 grep Huge /proc/meminfo 显示 HugePages_Free 接近 HugePages_Total，就是典型假象。
-
vm.hugetlb_shm_group = <oinstall_gid>：必须设为oinstall组 ID（用id -g oinstall查），否则grid/oracle用户无权挂载大页共享段 -
kernel.shmmax和kernel.shmall必须 ≥ 当前实例 SGA 实际大小（单位：字节 / 页）。shmall是总页数上限，shmall × 4096要 ≥ 物理内存；shmall × 2048 × 1024要 ≥ SGA 总量（单位 MB） -
memlock必须为unlimited：检查ulimit -l，并在/etc/security/limits.conf中为oracle用户显式设置oracle soft memlock unlimited和oracle hard memlock unlimited - 改完后必须执行
sysctl -p，且确认输出无 error；若提示"vm.nr_hugepages" is an unknown key，说明内核未启用CONFIG_HUGETLB_PAGE=y
为什么 sysctl -p 成功了，但 Oracle 还是不用大页
关键信号不是 HugePages_Total 有值，而是 HugePages_Rsvd > 0 且 HugePages_Free 显著下降（例如只剩个位数）。如果 HugePages_Rsvd == 0，说明 Oracle 启动时跳过了大页绑定。
- 检查
use_large_pages参数：必须设为only（ALTER SYSTEM SET use_large_pages=only SCOPE=SPFILE），设为auto或false会 fallback - 确认 AMM 已禁用：
memory_target和memory_max_target必须为0；AMM 与 HugePages 不兼容 - RHEL8+/OL8+ 上，systemd 会覆盖
limits.conf：需在/etc/systemd/system/oracle.service.d/override.conf中添加LimitMEMLOCK=infinity并systemctl daemon-reload - 验证 transparent_hugepage 是否永久禁用：
cat /sys/kernel/mm/transparent_hugepage/enabled应输出[never]；临时命令echo never > /sys/kernel/mm/transparent_hugepage/enabled重启即失效 - 启动后立刻查：
grep -i hugetlb /proc/<pmon_pid>/maps（pmonPID 用ps -ef | grep pmon查），有输出才表示大页已映射
RAC 环境最容易被忽略的同步点
RAC 不是“配好一个节点就行”。所有节点的 vm.nr_hugepages、vm.hugetlb_shm_group、kernel.shmall、kernel.shmmax 值必须完全一致，且 sysctl -p 后每个节点都得单独验证 HugePages_Rsvd > 0。
- 不要在节点 A 上跑脚本、抄值到节点 B；必须在每个节点上分别运行
hugepages_settings.sh，再统一加总、上浮、分发 - CRS 启动顺序影响验证时机：先启 ASM，再启 DB；确保 ASM 实例也已
STARTUP，否则脚本无法计入 ASM buffer 开销 - RHEL9.6+ 上，
vm.nr_hugepages超过物理内存 75% 可能触发 OOM killer——这不是配置错，而是内核水位误判，需留出余量 - 改完参数后必须重启 Oracle 实例（
SHUTDOWN IMMEDIATE+STARTUP），不是 reload；大页分配只发生在启动瞬间
