DBMS_ROLLING不能用于11g→19c升级，因其仅支持12.1.0.2及以上版本；执行BUILD必报ORA-16234，根本原因在于11g与19c的日志格式、SCN语义及字典结构不兼容。
dbms_rolling 在 oracle 19c 中不能用于从 11g 升级到 19c，这是硬性限制，不是配置或操作问题。它只适用于主备库均为 12.1.0.2 或更高版本的环境。
DBMS_ROLLING.BUILD 报 ORA-16234：版本不支持是明确信号
这个错误不是偶然或权限问题，而是 Oracle 内部校验直接拒绝启动：
执行 DBMS_ROLLING.BUILD 时若源库是 11g（哪怕 11.2.0.4），必然触发 ORA-16234: database version is not supported for rolling upgrade，日志中会紧跟着出现 Rolling upgrade requires primary database version >= 12.1.0.2。
原因很底层：DBMS_ROLLING 依赖 12c+ 的统一 LogMiner 解析器、增强型 SQL Apply 控制流、以及与 19c 兼容的字典结构。11g 的 SCN 语义、归档日志格式、内部对象元数据与 19c 不匹配，根本无法初始化滚动上下文。
常见误操作：
- 试图用 19c 的
DBMS_ROLLING包反向兼容 11g —— 不行，包本身在 11g 库里都不存在 - 跳过
BUILD直接调用UPGRADE_DATABASE—— 会报PLS-00201: identifier 'DBMS_ROLLING.UPGRADE_DATABASE' must be declared - 在 11g 主库上启用 DG Broker 后强行运行 —— Broker 会主动拦截并报错
DBMS_ROLLING 可用的前提：必须是 12c+ → 19c 或 19c → 23c
如果你当前主库已是 12.2.0.1、18c 或 19c，且备库也运行同代或更高版本（如 12.2 主库 + 19c 备库），DBMS_ROLLING 才真正可用。
关键前提条件：
- 主备库
COMPATIBLE参数 ≥12.1.0.2 - 必须禁用 DG Broker（12.2.0.1 之前版本）
- 所有参与复制的表必须有主键或唯一约束；含
LONG、LONG RAW、XMLTYPE、ROWID字段的表会导致BUILD阶段失败 - 升级前需手动清理
DBA_LOGSTDBY_UNSUPPORTED中的不兼容对象（即使版本达标）
典型调用链只有 4 步，但每步都强依赖环境一致性：
DBMS_ROLLING.BUILD → DBMS_ROLLING.UPGRADE_DATABASE → DBMS_ROLLING.SWITCHOVER → DBMS_ROLLING.CLEANUP
11g → 19c 的真实可行路径：逻辑DG + autoupgrade
这不是“替代方案”，而是官方唯一支持的跨代滚动升级路径。核心是绕过 DBMS_ROLLING 的版本绑定，靠人工控制同步启停来适配差异。
关键实操点：
- 先建标准物理 Data Guard（ADG），再用
ALTER DATABASE RECOVER TO LOGICAL STANDBY转为逻辑备库 - 转换前必须清空
DBA_LOGSTDBY_UNSUPPORTED中含ROWID、UROWID、XMLTYPE的表，否则升级后 SQL Apply 会中断 -
autoupgrade必须使用 19c 自带版本（如autoupgrade.jarfrom 19.17 RU），混用 12c/18c jar 包会导致静默失败 - 19c 逻辑备库首次启动时，必须加参数
_disable_implicit_log_archive=TRUE，否则 MRP 进程可能因解析 11g 归档格式异常而崩溃
整个流程中，最易被忽略的是补充日志（SUPPLEMENTAL_LOG_DATA_MIN = 'YES'）和表主键检查 —— 它们不报错，但会导致切换后数据不一致，问题暴露在业务高峰时段。
