滚动补丁升级必须分节点依次执行，不能并行；RU补丁只需用root执行opatchauto打GI HOME即可自动同步DB，PSU则需分别打GI和DB补丁；所有节点补丁完成后，必须逐个实例运行datapatch并编译失效对象。
滚动补丁升级必须分节点依次执行，不能并行
Oracle RAC 的 rolling patch 本质是“单节点停服、打补丁、重启、验证、再切下一个节点”，不是所有节点同时操作。一旦两个节点同时执行 opatchauto 或 opatch，会触发 CRS 资源锁冲突，crsctl start resource 失败，甚至导致集群分裂（split-brain）风险。
常见错误现象：节点1刚完成 GI 补丁应用，节点2立刻开始执行，结果节点2的 root.sh 卡在 ora.asm 启动阶段，日志反复报 CRS-2674: Start of 'ora.asm' on 'node2' failed——这是因为节点1已注册新版本 ASM 元数据，节点2仍用旧 GI 连接 OCR，协议不兼容。
- 必须严格按顺序：先 node1 完成 GI + DB 补丁 → 验证通过 → 再 node2 执行同等流程
- 每个节点操作前，确认
crsctl check crs全部服务 online，且srvctl status database -d <db_name>显示所有实例 running - 节点切换间隙，业务流量由另一节点承接，但监听器（SCAN Listener）和 VIP 必须保持在线；若误停
srvctl stop listener，客户端连接会中断
GI 和 DB 补丁是否要分开打？看 RU 还是 PSU
从 19.3 开始，Oracle 官方发布的 Release Update（RU）补丁包（如 19.20）中，GI 补丁已包含 DB 补丁逻辑——只需用 root 用户在各节点运行一次 opatchauto 打 GI HOME，DB HOME 自动同步更新。但 PSU（Patch Set Update）仍需分别打 GI 和 DB 补丁，否则 datapatch 会报错 ORA-00942: table or view does not exist（缺失新字典视图）。
判断依据看补丁 README：搜索 “This patch includes both GI and DB components” 或检查解压后目录结构——若含 etc/config.txt 且标记 GI_HOME 和 DB_HOME 均为 target，则为 RU；若只有 29585399（OCW）和 29517242（DB RU）两个独立子目录，则需分打。
- RU 场景：直接
opatchauto apply /path/to/rupatch -oh /u01/app/19.0.0/grid，无需额外打 DB 补丁 - PSU 场景：先打 GI 补丁（grid 用户），再打 DB 补丁（oracle 用户），顺序不可颠倒
- 无论 RU/PSU，
datapatch必须在所有节点补丁完成后，用 oracle 用户逐个实例执行：datapatch -verbose
opatchauto 执行失败时，别急着回滚，先查这三处
opatchauto 中断后，很多人直接 opatchauto rollback，结果发现 inventory 损坏、opatch lspatches 显示乱码。其实多数失败源于前置校验未过，而非补丁本身问题。
典型错误信息：OPATCHAUTO-72031: Failed to execute command: /u01/app/19.0.0/grid/perl/bin/perl -I /u01/app/19.0.0/grid/perl/lib -I /u01/app/19.0.0/grid/crs/install /u01/app/19.0.0/grid/crs/install/rootcrs.pl —— 实际是 /tmp 空间不足或 perl 权限不对，不是脚本缺陷。
- 检查
/tmp是否 ≥7GB：df -h /tmp；不足则清理或设TMPDIR=/largefs/tmp后重试 - 确认
root.sh所需的perl在 GI HOME 下可执行：/u01/app/19.0.0/grid/perl/bin/perl -v，若报libperl.so not found，需chown root:oinstall /u01/app/19.0.0/grid/perl/bin/perl - 验证 Oracle Inventory 是否一致：
runInstaller -debug -invPtrLoc /etc/oraInst.loc -executeScript -script "cat /u01/app/oraInventory/ContentsXML/comps.xml | grep -i 19.20"，两节点输出必须完全相同
补丁后必须手动运行 datapatch，且不能跳过编译失效对象
很多人以为 opatchauto 结束就万事大吉，结果第二天应用连不上——因为 datapatch 没跑，数据字典没升级，V$DATABASE.OPEN_MODE 显示 MOUNTED 而非 READ WRITE，或查询 DBA_REGISTRY 发现组件状态为 LOADING。
更隐蔽的问题是：datapatch 成功但未编译失效对象，导致 PL/SQL 包调用时报 PLS-00905: object SYS.DBMS_AQADM_SYS is invalid，这类对象在 dba_objects where status = 'INVALID' 中有上百个，必须显式处理。
- 每个节点上，用 oracle 用户登录任意实例，执行：
datapatch -verbose -pdbs ALL（含 PDB 场景） - 执行后立即检查：
SELECT patch_id, action, status FROM dba_registry_sqlpatch WHERE action = 'APPLY' ORDER BY bundle_sequence;，确认最新 patch_id 状态为SUCCESS - 运行
@?/rdbms/admin/utlrp.sql编译全部失效对象；若耗时过长，可限定范围：EXEC UTL_RECOMP.RECOMP_PARALLEL(4);
最容易被忽略的是：滚动升级中，节点1打完补丁后，节点2尚未升级时，节点1的 datapatch 只能作用于该节点实例，不能跨节点生效——必须等所有节点都完成补丁和 datapatch，才算真正完成。
