Oracle Data Guard滚动打补丁（Rolling Patch）不依赖DBMS_ROLLING包，而是通过OPatch+RAC Rolling Patch机制或物理standby逐节点升级实现；逻辑standby才使用DBMS_ROLLING，且仅限跨版本大升级场景。
Oracle Data Guard 补丁滚动安装（Rolling Patch Application）不是靠 DBMS_ROLLING 包，而是依赖 OPatch + RAC Rolling Patch 机制或物理 standby 逐节点升级；逻辑 standby 才用 DBMS_ROLLING，且仅限跨版本大升级场景。
滚动打补丁 ≠ 滚动升级
很多人混淆“滚动打补丁”（Rolling Patch）和“滚动升级”（Rolling Upgrade）。前者是给同版本数据库（如 19.22 → 19.23）打 RU/One-off 补丁，目标是零停机；后者是跨版本（如 12.1 → 19c），必须用逻辑 standby + DBMS_ROLLING 或 physru 脚本。
- 物理 standby 环境下，
OPatch apply -rolling只适用于 RAC 集群：先在 standby 节点打补丁、重启实例、验证同步，再 switchover，最后在原 primary 节点打补丁 - 单实例 DG 不支持真正的 rolling patch —— 你无法在主库运行时对物理 standby “热打补丁”，因为 standby 实例必须
MOUNT状态才能应用 redo，而 OPatch 要求实例完全关闭 -
DBMS_ROLLING包压根不处理补丁（patch），它只协调跨版本的逻辑 standby 切换流程；调用它前，你得自己在新 ORACLE_HOME 里装好 19c 软件并打好对应 RU
RAC 环境下真正能滚动打补丁的路径
只有 RAC + 物理 standby 组合，才可能实现接近零停机的补丁应用。关键不在 DG 配置本身，而在 GI 和 DB 的 rolling 行为是否协同。
- GI 补丁必须先于 DB 补丁应用，且需用
opatch auto并指定-rolling参数，否则会强制全集群重启 - DB 补丁应用前，确认
v$dataguard_stats中apply_lag≤ 0，且 standby 处于MANAGED RECOVERY状态（非 ADG OPEN READ ONLY） - 打补丁后必须立即运行
datapatch，否则DBA_REGISTRY_SQLPATCH不更新，下次opatch lsinventory会漏报 - 切记：switchover 后，原 primary 节点升级前，要手动拷贝新 ORACLE_HOME 下的
orapw<sid>和spfile到旧位置，否则启动报ORA-01102: cannot mount database in EXCLUSIVE mode
单实例 DG 滚动打补丁的现实做法
没有银弹。所谓“滚动”，实际是人工编排的最小化停机流程，核心是把风险转移到 standby 上验证。
- 在 standby 服务器上新增一个与 production 同版本的 ORACLE_HOME（例如 19.22），用
opatch apply打好目标 RU - 停 standby 的 MRP 进程：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;，然后用新 HOME 启动到MOUNT，运行datapatch - 不做 open，直接
STARTUP MOUNT+RECOVER MANAGED STANDBY DATABASE DISCONNECT恢复同步 —— 此时若 redo 应用失败，说明补丁有兼容性问题，立刻回退 - 验证通过后，才在 primary 执行同样流程：停业务 → 关库 → 切 ORACLE_HOME → 启动到
MOUNT→datapatch→ open
最容易被忽略的是 datapatch 的执行时机和用户权限：datapatch 必须用 ORACLE_HOME 下的 sqlplus / as sysdba 运行，且数据库需处于 UPGRADE 或 OPEN 状态；如果 standby 在 MOUNT 状态下运行 datapatch，它会静默跳过所有 SQL patch，导致后续 DBA_REGISTRY_SQLPATCH 显示为空。
