oracle rac补丁安装失败后无法无条件安全回退，因opatch rollback仅撤回文件变更，对sql执行、字典升级、jvm补丁及人工配置无效；真正可用回退路径依赖提前备份oracle_home/gi_home、ocr/voting disk及rman全库恢复。

Oracle RAC补丁安装失败后，不能无条件安全回退 —— opatch rollback 只能撤回文件级变更，对已执行的 SQL、字典升级、JVM 补丁或人工配置修改完全无效。

为什么 opatch rollback 常常不生效

很多人以为只要补丁装了就能用 opatch rollback 撤回，但实际失败率很高，核心原因在于 RAC 环境下补丁行为远不止“替换几个 .so 文件”：

• datapatch -verbose 执行后写入的 dba_registry_sqlpatch 记录和触发的元数据变更（如 obj$、col$）无法通过 rollback 恢复
• 含 ojvm 子补丁的 RU/RUR 补丁包被 Oracle 明确标记为 non-rollbackable，哪怕整个补丁包带 rollback 能力，只要含 ojvm 就整体不可逆
• RAC 场景下 opatch auto 会自动调用 rootcrs.pl -unlock 和 CRS 停启流程，这些操作不在 opatch 管控范围内，回退时不会还原 CRS 状态
• 人工改过的 ocr、voting disk、init.crs 或 listener.ora 不进 inventory，rollback 根本不知道它们存在

RAC 补丁失败后真正可用的回退路径

必须提前准备、按优先级排序使用：

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

• 立即停止所有节点的 CRS 和数据库实例，防止 datapatch 自动触发或后台 job 写入更多字典变更
• 若已备份 $ORACLE_HOME 和 $GI_HOME（推荐 tar 打包而非 rsync），可直接解压覆盖： tar -xvf ohome_backup.tar -C $ORACLE_HOME --overwrite tar -xvf ghome_backup.tar -C $GI_HOME --overwrite
• 若做过 OCR/Voting Disk 备份（ocrconfig -export / dd if=/dev/zero 清盘前快照），用 ocrconfig -restore + crsctl replace votedisk 恢复集群注册状态
• 数据库层必须依赖 RMAN 全库恢复到补丁前 SCN 或时间点，不能只靠 opatch rollback —— 因为 catbundle.sql 已改数据字典，仅文件还原会导致字典与物理块不一致

滚动安装（Rolling）失败时的特殊处理

滚动打补丁中途失败，节点状态不一致，此时 opatch rollback 在部分节点上可能报错 “inventory mismatch” 或 “patch is not applied”：

• 先统一所有节点的 opatch lsinventory 输出，确认哪些节点真打了补丁、哪些卡在中间状态
• 对已成功应用补丁的节点，仍可尝试 opatch rollback -id <patch_id></patch_id>，但必须确保该补丁支持 rolling rollback（查 README 中 Rolling: true 字样）
• 对卡住的节点，不要强行重跑 opatch auto，应先用 crsctl stop crs + crsctl start crs -excl 进入独占模式，再清理 $GRID_HOME/crs/install/backup_* 下残留锁文件
• 最稳妥做法仍是切到备份节点，用完整 tar + RMAN 恢复，滚动的本质是降低风险，不是消除回退成本

真正关键的不是“怎么 rollback”，而是补丁前是否做了三件事：全量 tar 备份 ORACLE_HOME/GI_HOME、ocrconfig -export、RMAN 到最近归档 SCN。没这三样，任何回退命令都是在赌运气。