DBMS_ROLLING不适用于11g→19c升级，因其仅支持12.1.0.2及以上版本；11g源库会触发ORA-16234错误，必须改用逻辑DG+autoupgrade组合方案。
不能直接用 dbms_rolling 从 oracle 11g 升级到 19c —— 这个包从 12.1.0.2 才开始支持，且只适用于 12c 及以上版本间的滚动升级。如果你的源库是 11g，dbms_rolling 在第一步就会报错退出，根本走不下去。
为什么 DBMS_ROLLING 不适用于 11g→19c 场景
DBMS_ROLLING 是 Oracle 12c 引入的自动化滚动升级工具，它依赖主备库都运行在 12c+ 环境下的内部机制（比如统一的 LogMiner 解析器、增强的 SQL Apply 控制流）。11g 的日志格式、SCN 语义、字典结构与 19c 差异过大，DBMS_ROLLING 启动时会立即拒绝识别 11g 主库的控制文件和归档日志。
常见失败现象：
- 执行
DBMS_ROLLING.BUILD时报ORA-16234: database version is not supported for rolling upgrade - 日志中出现
Rolling upgrade requires primary database version >= 12.1.0.2 - 即使绕过版本检查，后续
DBMS_ROLLING.UPGRADE_DATABASE也会因字典对象不兼容而卡在PREPARE阶段
11g→19c 必须用逻辑DG + autoupgrade 组合
真正可行的路径是：先建物理 Data Guard → 转为逻辑备库 → 停同步 → 用 autoupgrade 升级备库软件至 19c → 恢复 SQL Apply → 切换主库。这个流程绕过了 DBMS_ROLLING 的版本硬限制，靠人工控制同步启停来适配跨代差异。
关键操作点：
- 转换前必须清空
DBA_LOGSTDBY_UNSUPPORTED中的ROWID、UROWID、XMLTYPE字段表，否则升级后同步直接中断 -
autoupgrade必须用 19c 自带版本（如autoupgrade.jarfrom 19.17 RU），不能混用 12c 或 18c 的 jar 包 - 升级后首次启动 19c 逻辑备库时，需显式加参数
_disable_implicit_log_archive=TRUE，避免因 11g 归档格式解析异常导致 MRP 进程崩溃
DBMS_ROLLING 只在什么情况下能用
如果你当前环境已经是 12.2.0.1 或更高（比如 12.2→19c、19c→23c），DBMS_ROLLING 才是首选。它把原来 30+ 步的手动操作压缩成 4 个核心调用：
-
DBMS_ROLLING.BUILD：初始化滚动升级上下文 -
DBMS_ROLLING.UPGRADE_DATABASE：自动完成备库升级、重启、同步恢复 -
DBMS_ROLLING.SWITCHOVER：原子化切换主备角色 -
DBMS_ROLLING.CLEANUP：清理临时对象和日志标记
但注意：启用前必须禁用 DG Broker（12.2.0.1 之前），且 COMPATIBLE 参数不能低于 12.1.0.2；任何含 LONG 或未建主键的表都会让 BUILD 阶段直接失败。
最容易被忽略的兼容性断点
不是版本号本身，而是 11g 默认关闭的补充日志（SUPPLEMENTAL_LOG_DATA_MIN）和 19c 强制要求的 FORCE LOGGING。很多团队在物理 DG 阶段没开全补充日志，转逻辑备库时 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA 看似成功，实际只生效了部分字段 —— 导致后续 19c 备库应用日志时反复报 ORA-16116: no work available，查 DBA_LOGSTDBY_EVENTS 才发现是主键列没记录旧值。
