Oracle 19c RU补丁需满足三条件才支持真滚动升级：README明确标“Rolling RAC installable: YES”“Post-installation steps require downtime: NO”且OPatch≥12.2.0.1.43；grid与oracle用户各自$ORACLE_HOME下OPatch均须达标并分别验证；执行opatchauto apply -rolling（不带-oh）由工具自动逐节点处理。
确认补丁是否支持Rolling Patch
不是所有Oracle 19c RU补丁都真正支持零停机滚动升级。必须先查补丁的README文件，重点看这三行：
Rolling RAC installable: YESPost-installation steps require downtime: NOOPatch version required: 12.2.0.1.43+
例如36916690（19.25 GI RU）明确标为Rolling RAC installable，但若其README里提到需运行catbundle.sql或datapatch且注明“must be run with all instances down”，那就不能算真零停机——哪怕OPatch本身是滚动的，SQL脚本阶段仍会中断服务。
OPatch版本与用户权限必须双达标
GI补丁滚动升级要求grid用户和oracle用户各自$ORACLE_HOME下的OPatch都≥12.2.0.1.43。常见错误是只升级了oracle用户的OPatch，忘了grid用户。
- 用
su - grid -c "$ORACLE_HOME/OPatch/opatch version"和su - oracle -c "$ORACLE_HOME/OPatch/opatch version"分别验证 - 升级时必须用对应用户解压
p6880880_190000_Linux-x86-64.zip到自己的$ORACLE_HOME，不能由root直接mv - 解压后检查权限：
chown -R grid:oinstall $ORACLE_HOME/OPatch（grid用户），同理oracle用户
执行opatchauto rolling时的关键参数和顺序
在任意节点以root身份运行opatchauto，但必须指定-rolling且不带-oh（否则退化为All-Node Patch）：
opatchauto apply /soft/36916690 -rolling
该命令会自动识别RAC拓扑，并按节点顺序逐个打补丁。过程中你会看到类似输出：
Applying patch on node 'racnode1' ... SUCCESS Shutting down instance on node 'racnode1' ... SUCCESS Starting up instance on node 'racnode1' ... SUCCESS Applying patch on node 'racnode2' ... SUCCESS
- 每个节点实例只短暂关闭（通常
- 不要手动
crsctl stop crs或srvctl stop instance——opatchauto会自己控制 - 若中途失败，用
opatchauto rollback /soft/36916690 -rolling回滚，而非opatch rollback
datapatch必须在所有节点补丁完成后统一执行
GI补丁本身不改数据库字典，但配套的DB补丁（如36912597）安装后，必须运行datapatch更新数据字典。这一步不能滚动——它需要所有实例都在线，且必须在最后一个节点打完DB补丁后，用oracle用户在任一节点执行：
cd $ORACLE_HOME/OPatch ./datapatch -verbose
常见坑点：
-
datapatch报错ORA-20001: Latest opatch version is not installed：说明某个节点的oracle用户OPatch版本没跟上 - 卡在
Connecting to database...：检查监听是否正常、tnsnames.ora中service_name是否指向CDB（非PDB） - 执行时间长（尤其含大量PDB时）：这是正常现象，别中断；它本质是串行执行SQL，无法并行
真正容易被忽略的是：滚动升级的“零停机”只到opatchauto结束为止；datapatch虽不关实例，但会锁住部分字典表，高并发DML场景下可能引发短暂阻塞——这点在变更窗口评估时必须计入。
