oracle 19c rac下唯一不中断业务的ru升级方式是opatchauto rolling模式，它通过逐节点迁移集群资源实现滚动补丁，需满足opatch版本、共享存储、集群健康及补丁标注等前提，并严格完成版本校验、comps.xml检查和空间预留三步，执行时须用root用户、指定grid_home、加-analyze参数，补丁后必须人工运行datapatch并验证版本、对象状态和业务链路。
opatchauto rolling 是唯一可行路径
Oracle 19c RAC 环境下，真正能实现“不中断业务”的 RU 补丁应用方式只有 opatchauto 的 rolling 模式。它不是靠“不停库”蒙混过关，而是依赖集群资源的逐节点迁移：自动将实例、监听、ASM 实例等关键资源从待补丁节点迁出，执行补丁后重新拉起，再切回服务。任何试图用 opatch apply + 手动启停的方式都必然导致全局服务中断。
必须满足的前提条件包括：
-
opatchauto要求 GI 和 DB 的$ORACLE_HOME下 OPatch 版本 ≥ 12.2.0.1.43（例如 RU 19.24/19.25 明确要求） - 所有节点的 GI HOME 和 DB HOME 必须使用共享存储（或至少是同步镜像），否则
opatchauto会拒绝 rolling 模式 - 集群必须处于健康状态：
crsctl check cluster -all全部通过，且olsnodes -s -t显示所有节点为Active - 补丁包本身需标注 “rolling RAC installable” —— 查看 README 中的
Installation Type字段，不能是Non-rolling或留空
滚动升级前必须做三件事
跳过这三步，opatchauto 很可能在第二节点失败，或补丁后出现 ORA-00600/ORA-00704 等字典级错误。
第一，确认当前 GI 和 DB 的 RU 版本可线性升级。19c RU 升级不是任意跳转，必须满足 c >= a 且 c + d >= a + b（如 19.15.0 → 19.24.0 合法，但 19.10.2 → 19.24.0 不合法）。执行 opatch lsinventory -detail -oh $GRID_HOME 和 opatch lsinventory -detail -oh $ORACLE_HOME 获取当前版本号。
第二，检查 $ORACLE_HOME/inventory/ContentsXML/comps.xml 文件完整性。该文件若被手动修改或残留旧补丁注册信息，opatchauto 不报错但后续 datapatch 会静默跳过组件更新。可用 cat comps.xml | grep -E "(COMP_NAME|VERSION)" | head -10 快速核对主组件版本是否与 opatch lsinventory 输出一致。
第三，预留足够空间。RU 补丁解压后常达 2–3 GB，opatchauto 还需临时空间存放备份归档（如 $GRID_HOME/.patch_storage）。建议 /u01 或 $ORACLE_BASE 所在文件系统剩余 ≥ 25 GB。
执行 opatchauto apply 时的关键参数和陷阱
opatchauto apply 命令本身简单，但参数错一个，就退化成全停机模式。
正确命令格式（以 root 用户在节点 1 执行）：
cd /u01/media/ru/36912597 /u01/app/19.24.0/grid/OPatch/opatchauto apply -oh /u01/app/19.24.0/grid -analyze
注意：
- 必须用
root用户执行，且-oh指向的是$GRID_HOME（不是$ORACLE_HOME），opatchauto会自动识别并同时处理 GI 和 DB HOME - 首次运行务必加
-analyze参数。它会模拟整个流程，输出详细检查项（如空间、冲突、依赖），但不实际改动任何文件。忽略此步等于闭眼开车 - 不要加
-nonrolling—— 即使你只打一个节点，加了这个参数也会强制停掉整个集群 - 如果遇到 “PRCR-1079: Failed to start resource ora.crsd” 类错误，大概率是
$GRID_HOME/bin/crsctl权限异常，执行chmod 6751 $GRID_HOME/bin/crsctl后重试
补丁后验证不能只看 opatch succeeded
opatchauto 最后输出 OPatchauto succeeded. 只代表补丁文件已复制、GI 重启成功，不代表数据库字典已升级、业务可正常访问。
必须依次验证：
- 登录每个节点数据库，执行
SELECT BANNER_FULL FROM V$VERSION;，确认显示为新 RU 版本（如Oracle Database 19c Enterprise Edition Release 19.24.0.0.0） - 执行
datapatch -verbose（用 oracle 用户，在任一节点运行），观察输出中是否包含Applied Patches且无ERROR行；若提示 “No patches to apply”，说明opatchauto未触发字典升级，需手动运行$ORACLE_HOME/OPatch/datapatch -verbose - 检查无效对象：
SELECT COUNT(*) FROM DBA_OBJECTS WHERE STATUS != 'VALID';，数值应与打补丁前一致（或仅增加极个别系统包，属正常） - 跑一次最小业务链路：连入应用用户、查一张核心表、执行一条带绑定变量的
SELECT，确认硬解析、软解析、游标共享均无异常
最容易被忽略的是 datapatch 执行时机 —— 它不会在 opatchauto 中自动完成，必须人工触发，且必须在所有节点数据库都 open 状态下运行一次即可。漏掉这步，新特性（如 Automatic Indexing 增强）和 CVE 修复（如 CVE-2024-20358）都不会生效。
