oracle 19c rac gi集群os升级必须停crs，因gi深度绑定内核、udev、systemd等组件，跨大版本升级（如ol7→ol8）会导致ohasd加载失败、ocssd崩溃、asm磁盘识别失效，且未停crs直接升级90%触发ora-15032/15063无法在线恢复。
不能“无缝”升级Oracle 19c RAC的GI集群底层操作系统——OS升级必然中断集群服务，所谓“无缝”只存在于单节点滚动停机+严格验证的可控窗口内。
为什么必须停CRS才能升级OS
Grid Infrastructure（GI）深度绑定内核模块、udev规则、systemd服务、网络命名空间和时间同步机制。CentOS 7 → Oracle Linux 8这类主版本升级会替换glibc、kernel、systemd等核心组件，直接导致crsctl无法加载ohasd，ora.cssd进程崩溃，ASM磁盘组丢失识别。实测中未停CRS就执行leapp upgrade，90%概率触发ORA-15032 + ORA-15063，且无法在线恢复。
- GI进程依赖特定内核ABI，跨major version的kernel升级后，
ocssd.bin会因符号缺失直接core dump - OL7的
network-scripts与OL8的NetworkManager配置冲突，不清理会导致VIP漂移失败 -
udev规则文件路径和语法在OL8中变更，未重载会导致ASM disk路径失效（如/dev/oracleasm/消失）
必须提前完成的3项关键检查
跳过任一检查，升级后大概率卡在crsctl start crs阶段，需手动干预甚至重装GI。
- 确认所有节点已配置root SSH互信：
ssh root@node2 date必须无密码返回时间，否则leapp无法同步升级状态 - 验证OCR磁盘组兼容性：
SELECT name, compatibility, database_compatibility FROM v$asm_diskgroup WHERE name = 'OCR';—— 若compatibility低于19.0.0.0，升级后GI无法挂载OCR，需先执行ALTER DISKGROUP OCR SET ATTRIBUTE 'compatible.asm'='19.0.0.0'; - 检查AHF（Automatic Health Framework）版本：低于
v23.4.0的AHF在OL8上无法启动tfactl，必须升级后再操作，否则健康诊断功能失效
升级时最关键的两个操作顺序
顺序错一步，整个RAC集群将无法自愈启动。
- 先执行
crsctl stop crs -f（所有节点），再运行leapp preupgrade；若反过来，leapp会检测到活跃的CRS进程并拒绝继续 - OS重启后，必须用
root用户先启动GI：/u01/app/19.0.0/grid/bin/crsctl start crs，再切回grid用户验证crsctl check cluster；若先用grid用户执行，因环境变量未加载完整，会报CRS-4640: Oracle High Availability Services is not running
升级后最易被忽略的ASM磁盘识别问题
即使crsctl check cluster显示正常，ASM实例也可能无法识别磁盘组——这不是权限问题，而是udev规则未生效。
- 执行
ls -l /dev/asm*，若无输出或设备名不匹配（如应为/dev/asm-data-1却显示/dev/sdb1），说明udev未应用 - 立即运行：
/u01/app/19.0.0/grid/bin/asmcmd afd_label DATA /dev/sdb1 --init（按实际盘符调整），否则sqlplus / as sysasm中SELECT name FROM v$asm_disk;返回空 - 切勿依赖
oracleasm工具（已废弃），19c RAC必须用AFD（ASM Filter Driver）或UDEV，且AFD需在OS升级前已启用
真正的难点不在命令本身，而在于每个节点的udev规则、AFD状态、OCR磁盘组兼容性这三者必须严格对齐——差一个字符、低一个版本、少一次--init，集群就停在“能ping通但CRS起不来”的灰色地带。
