怎样在Oracle 19c RAC上执行GI零停机滚动补丁升级-Oracle-PHP中文网

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）由工具自动逐节点处理。

怎样在oracle 19c rac上执行gi零停机滚动补丁升级

确认补丁是否支持Rolling Patch

不是所有Oracle 19c RU补丁都真正支持零停机滚动升级。必须先查补丁的README文件，重点看这三行：

Rolling RAC installable: YES
Post-installation steps require downtime: NO
OPatch 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）：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

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场景下可能引发短暂阻塞——这点在变更窗口评估时必须计入。