在Oracle RAC环境中安装one-off补丁与单实例有显著不同，多个节点共享同一套集群件和数据库，任何操作都需要考虑节点间状态同步与业务连续性。如果直接在两个节点同时执行opatch apply，很容易触发集群资源异常，甚至导致脑裂。因此，Oracle官方推荐使用opatch auto或手动逐节点滚动安装。本文将以一个实际的RAC数据库补丁安装为例，梳理从环境检查、补丁应用到验证回滚的完整流程。
一、安装前的准备工作
RAC补丁安装失败常见原因包括：OPatch版本过低、补丁与现有PSU或BP冲突、节点间GI home不一致、归档日志空间不足等。这些问题如果在应用补丁前没有排查清楚，很容易在打补丁过程中卡住，甚至需要紧急回滚。因此，正式操作前必须逐项检查集群状态、软件版本和补丁兼容性。
首先确认集群所有节点都处于在线状态，并且OCR、voting disk等集群组件工作正常。可以在任意节点执行以下命令查看集群资源概况，确保没有资源处于offline或intermediate状态。
# 查看集群整体状态 crsctl check cluster -all # 查看集群资源状态（输出较长，可重点观察target和state列） crsctl stat res -t
接下来需要确认Oracle RAC使用的两个Home：Grid Infrastructure Home（通常称为GI_HOME）和数据库Home（ORACLE_HOME）。one-off补丁可能只针对其中一个，也可能两者都要打。查看当前OPatch版本，如果版本过低，需要先升级OPatch，否则补丁应用会直接报错。
# 查看GI_HOME的OPatch版本 $GI_HOME/OPatch/opatch version # 查看数据库Home的OPatch版本 $ORACLE_HOME/OPatch/opatch version # 查看数据库版本 sqlplus -v
补丁冲突检测也是关键一环。在应用one-off补丁前，应当使用opatch prereq命令检查该补丁是否与当前已安装的补丁存在冲突。如果检测到冲突，需要先卸载冲突补丁再继续，否则apply阶段会失败并可能留下不一致状态。
# 进入补丁解压目录，执行冲突检测 cd /u01/stage/12345678 opatch prereq CheckConflictAgainstOHWithDetail -ph ./
完成上述检查后，强烈建议对两个Home以及OPatch目录做一次完整备份。虽然Oracle官方提供回滚机制，但备份能在极端情况下提供最快速的恢复手段。可以使用tar命令将相关目录打包到独立存储位置，同时注意各节点的备份要保持一致。
# 备份GI_HOME（示例为/u01/app/19.0.0/grid） tar -czf /backup/grid_home_$(date +%F).tar.gz /u01/app/19.0.0/grid # 备份数据库Home（示例为/u01/app/oracle/product/19.0.0/dbhome_1） tar -czf /backup/db_home_$(date +%F).tar.gz /u01/app/oracle/product/19.0.0/dbhome_1
二、使用opatch auto进行滚动安装
opatch auto是Oracle专门为集群环境设计的补丁应用模式，它会自动识别RAC所有节点，并按照顺序在一个节点完成补丁应用后再切换到下一个节点。在应用数据库Home补丁时，opatch auto会在目标节点上停止数据库实例，应用补丁，然后重新启动实例，再移动到下一节点。对于GI Home补丁，它还会处理root脚本和集群服务的重启，确保整个集群不会同时失去全部节点。
执行opatch auto前，需要以对应Home的拥有者用户登录，通常GI_HOME使用grid用户，数据库Home使用oracle用户。设置好环境变量后，进入补丁目录，执行带有-ocmrf参数的opatch auto命令。OCM响应文件用于自动应答Oracle配置管理器的问题，避免交互式输入。如果补丁目录中没有现成的ocm.rsp，可以使用以下命令生成一个空响应文件。
# 以oracle用户生成OCM响应文件 $ORACLE_HOME/OPatch/ocm/bin/emocmrsp -no_banner -output /home/oracle/ocm.rsp
接下来实际执行补丁应用。注意这里需要确保PATH中包含OPatch目录，或者直接使用绝对路径调用opatch。命令中的补丁号需要根据实际文件调整。整个过程中，终端会输出每个节点的日志位置和进度，可以另开一个终端实时查看日志文件。
# 设置环境变量 export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export PATH=$ORACLE_HOME/OPatch:$PATH # 进入补丁目录 cd /u01/stage/12345678 # 使用opatch auto滚动应用补丁 opatch auto . -ocmrf /home/oracle/ocm.rsp
opatch auto执行过程中会输出类似“Patching node1”和“Patching node2”的信息，并显示每个节点的完成状态。如果中途某个节点失败，不要急于重新运行，应当先查看该节点的opatch日志，通常位于$ORACLE_HOME/cfgtoollogs/opatch/目录下。很多失败是因为环境变量不一致、空间不足或补丁包损坏，解决根因后再重新执行opatch auto，工具会从失败节点继续，而不是从头开始。
需要注意的是，如果补丁针对的是GI Home，opatch auto可能需要以root用户执行，或者需要sudo权限来运行root脚本。这种情况下建议以grid用户启动opatch auto，工具会提示在适当的时候执行root脚本，按照提示操作即可。生产环境中务必预留足够的维护窗口，因为每个节点的数据库实例都会短暂停机。
三、验证补丁结果与回滚
补丁应用完成后，不能只看终端输出“successful”就结束，还需要通过inventory和数据库内部视图确认补丁真正生效。首先使用opatch lsinventory查看已安装补丁列表，确认目标补丁号出现在输出中。如果输出内容较多，可以使用grep过滤。
# 查看数据库Home已安装补丁 opatch lsinventory -oh $ORACLE_HOME | grep 12345678 # 查看GI Home已安装补丁（如适用） opatch lsinventory -oh $GI_HOME | grep 12345678
很多one-off补丁包含SQL变更，需要在数据库层面执行datapatch脚本。对于RAC环境，可以在任意一个存活节点上执行datapatch，它会自动连接到每个实例并应用SQL补丁。注意datapatch需要数据库处于open状态，并且监听正常。执行前最好先确认所有实例都已启动。
# 以oracle用户执行datapatch $ORACLE_HOME/OPatch/datapatch -verbose
执行完毕后，可以连接数据库查询补丁注册状态。如果补丁是数据库补丁，它的补丁号会出现在dba_registry_sqlpatch视图中，状态应为SUCCESS。如果状态为FAILED，需要查看datapatch日志并重新执行。
-- 查询SQL补丁应用状态 SELECT patch_id, version, status, action_time FROM dba_registry_sqlpatch WHERE patch_id = 12345678;
如果补丁应用后发现性能衰退、功能异常或其他问题，可以使用opatch auto的rollback功能进行回滚。回滚同样遵循滚动顺序，先在一个节点回滚并恢复服务，再处理下一节点。回滚前需要停止相关节点的数据库实例或集群资源，具体操作与apply类似。执行回滚的命令如下：
# 进入补丁目录 cd /u01/stage/12345678 # 使用opatch auto回滚补丁 opatch auto -rollback 12345678 -ocmrf /home/oracle/ocm.rsp
对于包含SQL变更的补丁，回滚补丁后还需要运行datapatch回滚SQL部分。通常opatch auto在回滚过程中会提示是否执行datapatch，或者可以手动运行datapatch -rollback 12345678。务必确保所有节点都回滚完成后，再验证inventory和数据库视图，确认补丁已被彻底移除。
最后还要强调一点：RAC环境中的one-off补丁安装一定要避免在业务高峰期进行，即使opatch auto号称滚动不中断服务，但实例切换和重启仍会导致瞬间连接中断。建议提前与应用团队沟通，将连接串配置为合理的failover模式，并在维护窗口内完成操作。补丁安装完成后，应当监控一段时间，观察AWR、告警日志和集群日志，确认没有异常错误。
Oracle RACone-off补丁OPatch修改时间：2026-09-29 05:03:23