DBMS_ROLLING在Oracle 12c中仅支持Active Data Guard与逻辑备库组合，物理备库须先转换；需满足FLASHBACK_ON= YES、COMPATIBLE≥12.1.0.2、OPEN READ ONLY WITH APPLY、保护模式为MAXIMUM AVAILABILITY/PERFORMANCE、无MANDATORY归档路径等硬性条件，且必须禁用Data Guard Broker。
DBMS_ROLLING 在 Oracle 12c 中只支持 Active Data Guard + 逻辑备库组合，物理备库必须先转换，否则调用 DBMS_ROLLING.START_UPGRADE 直接报 ORA-16826 或卡在 INITIALIZING 状态。
确认是否满足最低运行条件
不是装了 12c 就能用，DBMS_ROLLING 对底层状态有硬性校验：
-
V$DATABASE.FLASHBACK_ON必须为YES（主库和备库都要查） -
COMPATIBLE参数必须 ≥12.1.0.2（12c 默认满足，但若从 11g 升级而来可能被锁死） - 备库必须处于
OPEN READ ONLY WITH APPLY模式，不能是MOUNTED - 检查
SELECT PROTECTION_LEVEL FROM V$DATABASE，必须是MAXIMUM AVAILABILITY或MAXIMUM PERFORMANCE -
LOG_ARCHIVE_DEST_n不能含MANDATORY属性（否则 SQL Apply 会中断）
为什么必须停用 Data Guard Broker
Broker 会劫持角色切换和状态同步逻辑，与 DBMS_ROLLING 的内部状态机冲突：
- 在 DGMGRL 中执行
DISABLE CONFIGURATION（不是DISABLE DATABASE） - 主库和备库均需执行
ALTER SYSTEM SET DG_BROKER_START=FALSE - 升级完成后才能重新启用，提前开启会导致
FINISH_UPGRADE失败 - 注意：12.2.0.1+ 版本已支持 Broker 共存，但 12c 全系仍需禁用
逻辑备库同步前的兼容性筛查
逻辑复制不支持某些数据类型和对象，未提前识别会导致升级中途失败或数据丢失：
- 运行
SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED，重点检查含ROWID、UROWID、XMLTYPE、OBJECT或VARCHAR2(4000+)的表 - 若存在不支持对象，需改用其他方案（如停机升级），
DBMS_ROLLING不提供绕过机制 - 确保主库归档日志可被逻辑备库解析：检查
V$ARCHIVED_LOG中DELETED为NO，且APPLIED列无异常值
catctl.pl 升级备库时的关键参数陷阱
即使 START_UPGRADE 成功，后续用 catctl.pl 升级备库也极易因默认参数失败：
- 必须加
--n 2：避免 shared pool latch 争用引发ORA-04031 - 必须指定
--l /path/to/catupgrd/：防止日志残留污染 $ORACLE_HOME - 必须设
--p 300：组件超时从默认 180 秒延长，防 I/O 延迟误判失败 - 执行前备库需
SHUTDOWN IMMEDIATE，但升级脚本本身不自动启库，需手动STARTUP或靠 CRS 触发
最易被忽略的是：所有 DBMS_ROLLING 过程（包括 START_UPGRADE、FINISH_UPGRADE）必须在主库以 SYSDBA 身份调用，切勿在备库执行——函数内部不校验会话上下文，错误调用会导致元数据错乱且不可逆。
