必须异机升级，不可原地滚动；GI须先于DB升级并用rootupgrade.sh；ASM磁盘组compatible.asm须提前设为12.1.0.2；RAC不支持AutoUpgrade，需手动分三步执行GI替换、DB部署和数据库升级。
升级必须走异机，别在原集群上直接升
Oracle RAC 11g（尤其是11.2.0.4）升级到19c，官方不支持原地滚动升级——rootupgrade.sh只能用于同大版本内小版本升（如12.1→12.2），跨代升级（11g→19c）必须新建节点或新机器部署。生产环境几乎全部采用“异机升级”：在新主机上装19c GI和DB，用RMAN或Data Guard同步数据，再切换。强行在原11g集群上跑gridSetup.sh会卡在OCR兼容性校验或ASM磁盘组挂载失败（常见报错：ORA-59303: The attribute compatible.asm should be 11.2.0.2.0 or higher，但19c要求至少12.1.0.2）。
GI和DB必须分两步升，顺序不能反
Grid Infrastructure（GI）必须先于数据库软件升级，且必须用rootupgrade.sh而非root.sh。这是因为19c GI自带新的Clusterware栈和OHASD守护进程，它要接管并重写OCR、OLR、表决盘等元数据。如果先装19c DB Home再升GI，srvctl会找不到有效集群栈，后续crsctl start resource全失败。
- 第一步：在目标节点解压
19c grid安装包，运行./gridSetup.sh图形或静默模式，选择“Upgrade Oracle Grid Infrastructure” - 第二步：以root身份在每个节点依次执行
/u01/app/19.0/grid/rootupgrade.sh（不是root.sh） - 第三步：确认
crsctl check cluster -all全部通过，再开始部署19c DB软件和升级数据库实例
ASM磁盘组compatible属性必须提前调高
11g默认的compatible.asm是11.2.0.0.0，而19c GI要求至少12.1.0.2；否则rootupgrade.sh执行到“Mount ASM diskgroups”阶段就会中断。这个值不能靠升级自动改，必须人工提前在11g环境下执行SQL：
ALTER DISKGROUP DATA SET ATTRIBUTE 'compatible.asm' = '12.1.0.2';<br>ALTER DISKGROUP FRA SET ATTRIBUTE 'compatible.rdbms' = '11.2.0.4';
注意：compatible.rdbms可暂留11g值（保证旧库还能启动），但compatible.asm必须一步到位设为19c能接受的最低值；改完需ALTER DISKGROUP ... MOUNT验证是否生效，否则升级时仍报ORA-15032或ORA-15260。
AutoUpgrade只适用于单实例，RAC必须手动拆解
autoupgrade.jar对RAC无效——它无法识别OCR位置、无法协调多节点DB启动顺序、也不处理ASM实例依赖。试图用upg1.upgrade_node=localhost指向RAC某节点，结果只会升级那个节点上的实例，其他节点实例丢失注册，集群资源紊乱。RAC升级本质是“GI栈替换+DB Home迁移+数据同步”，必须拆成三块操作：
- GI升级用
rootupgrade.sh（已述） - DB软件安装用
runInstaller -silent -responseFile静默部署19c DB Home - 数据库升级用
dbua或catctl.pl+catupgrd.sql，且必须在所有节点都完成GI升级后，逐个节点执行
最容易被忽略的是：升级后第一个启动的19c实例会自动创建新的PDB$SEED，但老11g的spfile里没这个结构，必须用CREATE SPFILE FROM PFILE重建，否则后续节点启动时报ORA-65096。
