必须先升级数据库再升级Grid Infrastructure，因为19c GI不兼容11g数据库软件，强行先升GI会导致11g实例无法注册集群、crsctl启动失败；正确顺序是并行部署新环境，在19c GI下用11g HOME挂载数据库后，再以autoupgrade升级并手动设置compatible='19.0.0'。
不能先升级grid infrastructure再升级数据库（db），这是oracle rac滚动升级中最容易踩的致命顺序错误。
为什么GI必须和DB同步升级或后于DB？
Oracle官方明确要求：19c的GI（Grid Infrastructure）**不兼容** 11g数据库软件。如果你强行先升级GI到19c，11g RAC实例将无法注册进集群，crsctl start resource会直接失败，报错类似ORA-01034: ORACLE not available或CRS-2674: Start of 'ora.db11g.db' failed。这不是配置问题，是版本互斥的硬性限制。
- 11g RAC依赖11g GI中的
ohasd、cssd等进程协议，19c GI已移除或重构这些组件 -
GI的OCR和ASM磁盘组元数据格式在19c有变更，11g DB无法识别 - 即使你绕过启动检查强行挂载，后续ADG同步、日志归档、甚至
srvctl命令都会不可预测中断
正确顺序：先建新GI + 新DB软件，再迁移
所谓“滚动”，本质是异机迁移+角色切换，不是原地升级。必须在目标服务器上并行部署两套环境：
- 先安装19c
GI（含19c ASM），确保集群正常crsctl check cluster - 再在同一台机器安装19c
DB软件（不建库），用于后续autoupgrade或DBUA - 保留源端11g RAC和其配套的11g
GI运行，作为主库 - 用RMAN或ADG把数据同步到新环境——此时新环境是11g DB + 19c GI，但DB仍用11g二进制启动（需显式指定
ORACLE_HOME指向11g路径）
autoupgrade必须在19c GI下运行，但目标库要先“降级”启动
当你把11g数据库文件复制到19c GI管理的ASM磁盘组后，不能直接用19c ORACLE_HOME启动它——11g数据文件不被19c实例识别。必须分两步：
- 用11g
ORACLE_HOME启动实例（startup nomount），仅加载控制文件；再用alter database mount挂载（此时依赖11g GI的ASM driver，但实际走的是19c GI的ASM实例，所以需提前在19c GI中创建兼容11g的diskgroup，COMPATIBLE.ASM = '11.2.0'） - 确认挂载成功后，再切换到19c
ORACLE_HOME，执行autoupgrade -mode analyze，它会自动识别底层是11g数据，并生成升级路径 - 关键参数：
-target_db_version 19.0.0必须显式指定，否则autoupgrade可能误判为就地升级而拒绝执行
切换前最后验证：compatible参数不是升级完成的标志
很多人看到autoupgrade报告“SUCCESS”就以为结束，结果应用连不上。真正卡点在compatible：
- 升级过程本身不会修改
compatible，它仍为'11.2.0'，导致19c新特性（如SQL Quarantine、Hybrid Partitioning）全部不可用 - 必须在
autoupgrade完成后、业务切换前，手动执行ALTER SYSTEM SET COMPATIBLE='19.0.0' SCOPE=SPFILE;，然后重启实例 - 重启后立刻查
V$VERSION和V$PARAMETER双验证，缺一不可；否则切换后应用报ORA-00406（COMPATIBLE参数太低）就只能回退
最易忽略的是：RAC环境下，这个ALTER SYSTEM必须在所有节点都执行，且SPFILE必须存于共享存储（如19c ASM），否则节点间compatible值不一致，集群资源无法稳定上线。
