rootupgrade.sh 在 11g/12.1 rac 上必然失败，因 19c gi 移除了 cssd、ohasd 等旧协议栈，导致 crs offline、ora-600/crs-4640 错误，且 ocr/asm 元数据不兼容，autoupgrade 也拒绝识别该配置。
不能直接在旧 GI 上运行 rootupgrade.sh 升级到 19c，除非当前 GI 版本 ≥ 12.2 —— 11g 或 12.1 的 RAC 必须先迁移到新节点或通过逻辑 DG 滚动切换，否则 crsctl start resource 会因协议不兼容直接失败。
为什么 rootupgrade.sh 在 11g/12.1 RAC 上必然失败
19c GI 已移除 cssd、ohasd 等核心进程的旧协议栈，而 11g/12.1 数据库实例强依赖这些组件注册进集群。强行升级 GI 后：
-
crsctl check crs显示 CRS offline，crsctl start resource报 ORA-600 或 CRS-4640 - OCR 和 ASM 元数据格式变更，11g 实例即使挂载磁盘组，也无法写归档、无法启动 ADG 同步
-
autoupgrade -mode analyze在 11g GI 下直接拒绝识别目标为 19c 的场景，报ORA-65535: upgrade not supported for this configuration
19c GI 升级只适用于 ≥12.2 的现有 GI 环境
若当前 GI 是 12.2、18c 或 19.x（如 19.3 → 19.28），可走标准滚动补丁流程：
- 必须先升级
OPatch到最新版（如p6880880_190000_Linux-x86-64），否则opatchauto会跳过关键 RU 补丁 - GI 补丁（如
p37957391_190000_Linux-x86-64）必须在 DB 补丁前应用，顺序颠倒会导致crsctl命令异常 - 静默升级时，响应文件中
INVENTORY_LOCATION必须指向/u01/app/oraInventory，且该路径需对grid用户可写 - 执行
rootupgrade.sh后，务必检查日志：/u01/app/oracle/crsdata/<node>/crsconfig/rootcrs_<node>_*.log</node></node>，重点确认CLSRSC-595（TFA 升级）、CLSRSC-400（ASM 兼容性检查）是否成功
ASM 磁盘组 compatible.asm 和 compatible.rdbms 必须显式升级
GI 升级本身不自动修改磁盘组兼容性属性，但 19c 要求 compatible.asm ≥ '12.1.0.0'，否则后续创建 ACFS 或启用 Flex ASM 会失败：
- 升级 GI 后，用
sqlplus / as sysasm连接 ASM 实例，逐个检查：SELECT NAME, COMPATIBILITY, DATABASE_COMPATIBILITY FROM V$ASM_DISKGROUP; - 若
COMPATIBILITY ，执行：<code>ALTER DISKGROUP <dg_name> SET ATTRIBUTE 'compatible.asm' = '12.1.0.0';</dg_name> -
DATABASE_COMPATIBILITY应设为对应数据库版本（如 19c 数据库设为'19.0.0'），否则 19c 实例无法挂载该磁盘组 - 该操作不可逆，且需所有节点离线该磁盘组（即无数据库使用），建议在维护窗口执行
升级后最易忽略的验证点：TFA、OCR 备份与网络 VIP 状态
很多人看到 crsctl check crs 返回 online 就认为完成，但以下三项不验证，上线后大概率出故障：
- TFA（Trace File Analyzer）未升级成功会导致诊断日志丢失，检查命令：
tfactl status，应显示Running且版本 ≥ 19c；若卡在Starting，需手动执行tfactl stop && tfactl start - OCR 自动备份可能因 GI 升级中断，运行
ocrconfig -showbackup，确认最近一次备份时间在升级后，并用ocrconfig -restore测试可恢复性 - VIP 和 SCAN VIP 可能未绑定到正确网卡，尤其多网卡环境：用
srvctl config nodeapps核对 VIP 所属 interface，再用ifconfig确认该 interface 已 up 且有对应 IP
