核心原因是AUTO_START未设为always或系统资源限制被重置：必须在各节点执行crsctl modify resource ora..db -attr "AUTO_START=always"，并同步配置hugepages、禁用transparent_hugepage、设置kernel.sched_rt_runtime_us=-1及DefaultTasksMax=infinity。
Oracle 19c RAC节点重启后集群无法自动拉起，**核心原因几乎总是 AUTO_START 属性没设成 always，或底层系统资源限制（如 cgroup、HugePages、semaphores）被重置**。不是“可能出问题”，而是生产环境里反复验证过的硬性前提。
crsctl modify resource ora..db -attr "AUTO_START=always" 必须执行
srvctl enable database 只影响 srvctl 命令层面的启用开关，对节点重启时 CRS 是否自动拉库完全无效。真正起作用的是 CRS 资源的 AUTO_START 属性。
- 查当前值：
crsctl status resource ora.，若返回.db -p | grep AUTO_START restore或never，必须改 - 改命令：
crsctl modify resource ora..db -attr "AUTO_START=always" - 该操作需在**每个 RAC 节点上单独执行**，不能只跑一遍就认为全好了
- 修改后无需重启 CRS，但必须用
crsctl stat res -t确认状态列显示为ONLINE且没有 INTERMEDIATE
ORA-00800 / CRS-1726：检查 kernel.sched_rt_runtime_us 和 cgroup 配置
ORA-00800（Set Priority Failed）和 CRS-1726（Process failed to run in real-time priority）本质是同一类问题：VKTM、LMHB、OCSSD 这些 Oracle 核心进程需要 real-time 调度权限，但被 Linux cgroup 限死了。
- 临时验证：
cat /proc/sys/kernel/sched_rt_runtime_us，若为950000（默认值）或更小，大概率不够；应设为-1（不限制） - 永久生效：在
/etc/sysctl.conf加一行kernel.sched_rt_runtime_us = -1，然后sysctl -p - 同时确认 systemd 的
DefaultTasksMax没被卡住：systemctl show --property DefaultTasksMax，若仍是512，编辑/etc/systemd/system.conf，取消注释并设为DefaultTasksMax=infinity，再systemctl daemon-reload && reboot
ora.storage 卡在 OFFLINE：先看 ASM 实例是否真起来了
crsctl stat res -t 显示 ora.storage 是 OFFLINE，常见报错是 CRS-5055: unable to connect to an ASM instance 或 ORA-12541: TNS:no listener——这说明 ASM 实例根本没起来，或者监听没注册上。
- 别急着 restart ora.asm，先手动连：
sqlplus / as sysasm，看能否登录；如果连不上，ps -ef | grep pmon确认ora_pmon_+ASM进程是否存在 - 若 ASM 进程不存在，检查
ora.asm资源状态：crsctl stat res ora.asm -t，若也是 OFFLINE，重点查$GRID_HOME/log/下的 trace 日志/asm/ - 常见诱因：HugePages 没配对（
hugepages_settings.sh输出值没写进/etc/sysctl.conf），或transparent_hugepage=never没永久禁用（仅 echo 写 /sys/ 是重启即失效） - 验证 THP 是否真正禁用：
cat /sys/kernel/mm/transparent_hugepage/enabled输出必须是[never]，且grep AnonHugePages /proc/meminfo应为0 kB
OCR/voting disk 不可达导致 cssd 启动失败
CRS-4537（OHAS not online）或 cssd 日志里反复出现 CRS-1726 + IPC Send timeout，往往不是软件坏了，而是 OCR 所在磁盘组压根没 mount 上来。
- 用
asmcmd lsdg看 OCRVOTE（或类似名）磁盘组状态，若为DISMOUNTED，手动 mount：sqlplus / as sysasm→ALTER DISKGROUP OCRVOTE MOUNT - 确认 voting disk 路径可访问：
crsctl query css votedisk输出路径（如+OCRVOTE或/dev/mapper/mpathb），在所有节点上用ls -l检查属主是否为grid:oinstall，权限是否为660（裸设备）或644（NFS） - 私网不通也会导致 cssd 卡死：
olsnodes -n应列出全部节点编号；若某节点缺失，查$GRID_HOME/log/中是否有/cssd/ocssd.log Failed to connect to CSS daemon，重点排查防火墙是否放行 UDP 12345 端口
真实重启后的拉起链条比想象中脆弱：AUTO_START=always 是开关，kernel.sched_rt_runtime_us=-1 是油，hugepages_settings.sh 算出的 vm.nr_hugepages 是燃料，olr.loc 文件存在且路径有效是点火器——漏掉任意一环，集群都只会停在半路。
