必须用hugepages_settings.sh在已启动实例上运行并加5%余量，否则rac节点重装后因参数清空、thp默认开启及配套参数缺失，将导致启动失败、被驱逐或静默降级；验证需确认hugepages_rsvd>0且启动日志含large pages信息。
为什么HugePages在19c RAC里不是“开了就快”，而是必须算准再配
Oracle 19c RAC默认不启用HugePages，即使系统支持、内核已开启vm.nr_hugepages，DBA不显式配置并重启实例，SGA仍走4KB小页。更关键的是：HugePages是静态预分配的，一旦设少，实例启动时会因内存不足报ORA-27102: out of memory；设多又浪费，且无法被其他进程复用。它不像AMM或ASMM那样能动态伸缩。
计算HugePages数量不能只看sga_target，得扣掉非共享内存段
直接用sga_target除以2MB（默认HugePage大小）会高估——因为SGA里包含不走HugePages的部分：
-
PGA_AGGREGATE_TARGET完全不走HugePages，必须排除 - 某些19c RAC组件如
GES（Global Enqueue Service）和GCS（Global Cache Service）内存结构默认用小页，尤其在高并发跨节点块请求场景下 - 如果启用了
INMEMORY_SIZE，其内存池独立于SGA，也不计入HugePages需求
正确做法是查V$SGASTAT中真正归属SGA共享池的项：
SELECT ROUND(SUM(bytes)/1024/1024/2) hugepages_needed
FROM v$sgastat
WHERE pool IN ('shared pool', 'large pool', 'java pool', 'streams pool')
OR name IN ('buffer_cache', 'log_buffer');
结果向上取整，再加10%余量防碎片。
配置后RAC节点不生效？大概率是没绕过AMM/ASMM冲突
19c RAC中，只要memory_target或sga_target设为非零值，Oracle就会禁用HugePages（即使use_large_pages=only）。这是硬性限制，不是bug。
- 必须显式关闭自动内存管理：
ALTER SYSTEM SET memory_target=0 SCOPE=SPFILE;和ALTER SYSTEM SET sga_target=0 SCOPE=SPFILE; - 改用手动SGA参数：
db_cache_size、shared_pool_size等，并确保总和 ≤ 预留HugePages总量 - 每个RAC节点的
spfile都要单独修改，不能只改一个节点再同步 - 重启前确认：
cat /proc/meminfo | grep -i huge显示HugePages_Free≥ 计算值，否则sysctl -w vm.nr_hugepages=XXX补足
验证是否真走HugePages，别信v$parameter里的use_large_pages
use_large_pages参数显示ONLY不代表成功——它只说明“想用”，不等于“已用上”。真实证据在OS层：
- 查
ps -eo pid,comm,pmem,vsz,rss | grep pmon，对比RSS值与SGA大小：若RSS ≈ SGA，说明HugePages生效；若RSS远小于SGA，说明仍在用小页（大量内存被mmapped但未锁定） - 查
/proc/<pid>/smaps</pid>中MMUPageSize字段：对pmon进程，应出现多行MMUPageSize: 2048 kB，而非全为4 kB - RAC环境下，必须逐个节点检查，常见问题是节点2因
/etc/sysctl.conf未同步导致nr_hugepages为0
最易被忽略的一点：HugePages分配发生在实例启动瞬间，若此时HugePages_Free不足，Oracle静默回落到小页，且不会报错——只在alert日志里写一行WARNING: Large pages not used，极易被扫过。
