内核升级后oracle 19c rac几乎必然故障，必须重配vm.nr_hugepages、永久禁用transparent_hugepage=never、同步设置hugetlb_shm_group/shmmax/shmall、调高fs.aio-max-nr和defaulttasksmax，并重启验证。
内核升级后 Oracle 19c RAC 几乎必然故障，不是“可能出问题”，而是 vm.nr_hugepages、transparent_hugepage、fs.aio-max-nr 等关键参数全部重置，且新内核常默认启用 THP 或禁用大页支持——必须逐项重配，不能依赖旧配置。
检查 transparent_hugepage 是否被内核自动启用
新内核（尤其是 OL8/RHEL8+）升级后默认开启 transparent_hugepage=always，与 Oracle 的 use_large_pages=only 冲突，导致实例启动时反复 fallback，报 ORA-27102: out of memory 或静默挂起。
- 立即验证：
cat /sys/kernel/mm/transparent_hugepage/enabled—— 若输出含[always]或[madvise]，即已触发冲突 - 临时禁用（仅本次生效）：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久禁用（必须）：编辑
/etc/default/grub，在GRUB_CMDLINE_LINUX行末追加transparent_hugepage=never，再执行grub2-mkconfig -o /boot/grub2/grub.cfg并reboot - 验证生效：
grep AnonHugePages /proc/meminfo应返回AnonHugePages: 0 kB
重算并重载 vm.nr_hugepages 及配套参数
内核升级会清空 /proc/sys/vm/nr_hugepages，且旧 /etc/sysctl.conf 中的值可能因新内核不支持或计算错误而失效。只改 vm.nr_hugepages 不够，四项必须同步到位。
- 先确认数据库已 STARTUP（哪怕只在一个节点）：
ps -ef | grep pmon - 运行官方脚本获取基准值：
$ORACLE_HOME/rdbms/install/hugepages_settings.sh，提取Recommended setting: vm.nr_hugepages=XXXX - 实际设值 = 脚本输出 × 1.05 向上取整（例如 3120 → 3276）；多实例 RAC 需累加各节点推荐值再上浮
- 四个参数必须同时写入
/etc/sysctl.conf：vm.nr_hugepages = 3276-
vm.hugetlb_shm_group = 54321（用id -g oinstall查真实 GID） -
kernel.shmmax = 4398046511104（≥ 单实例最大 SGA 字节数） -
kernel.shmall = 33554432（≥ 物理内存总页数，按 4KB/页算）
- 执行
sysctl -p，若报错"vm.nr_hugepages" is an unknown key，说明内核未编译CONFIG_HUGETLB_PAGE=y，需换内核或联系 OS 厂商
验证 fs.aio-max-nr 和 systemd DefaultTasksMax 是否回归默认低值
内核升级常连带重置 fs.aio-max-nr（影响异步 I/O）和 systemd 的 DefaultTasksMax（限制 fork 数），这两项是 ORA-27300 和 fork() failed with status 11 的直接元凶。
- 查当前 AIO 上限：
cat /proc/sys/fs/aio-max-nr—— 若低于1048576，立刻补：echo 1048576 > /proc/sys/fs/aio-max-nr，并写入/etc/sysctl.conf持久化 - 查 systemd 任务上限：
systemctl show --property DefaultTasksMax—— 若仍为默认512，编辑/etc/systemd/system.conf，取消注释并设为DefaultTasksMax=infinity - 改完必须
reboot，因为DefaultTasksMax是启动时加载的 cgroup 限制，systemctl daemon-reload无效 - 重启后验证：
cat /proc/sys/fs/aio-nr应远小于aio-max-nr；cat /proc/sys/kernel/pid_max应 ≥ 65536
确认 ohasd 和 CRS 是否因参数缺失而无法拉起
内核升级后 ohasd 进程常因 /etc/oracle/olr.loc 路径失效或 IPC 参数未就位而静默退出，导致 crsctl check crs 报 CRS-4537，所有集群命令失灵。
- 先看进程：
ps -ef | grep ohasd—— 若无输出，不要执行crsctl start crs - 检查
/etc/oracle/olr.loc是否存在且内容有效：cat /etc/oracle/olr.loc，路径如olrconfig_loc=/u01/app/19c/grid/cdata/olr.ocr必须真实可读 - 手动启 ohasd：
sudo $GRID_HOME/bin/crsctl start ohasd，然后立刻crsctl check crs—— 成功应显示CRS-4638: Oracle High Availability Services is online - 若仍失败，检查
$GRID_HOME/log/<hostname>/client/ohasd.log</hostname>，重点搜semget、shmget、Permission denied，大概率是vm.hugetlb_shm_group或memlock未生效
最易被忽略的是：内核升级后 ulimit -l（memlock）自动回落为默认值，即使 /etc/security/limits.conf 没动，也需重新以 su - oracle 登录才能加载；而 ohasd 是 root 启的，它依赖的 grid 用户 limits 也必须单独验证。
