不能在原11g rac集群上就地升级到19c,必须走“异机迁移 + data guard滚动切换”路径;强行在11g gi上安装19c数据库软件并启动实例会触发ora-00722或ora-01503错误,因19c内核无法解析11g asm磁盘组元数据和rdbms块格式。

不能在原11g RAC集群上就地升级到19c,必须走“异机迁移 + Data Guard滚动切换”路径;强行在11g GI上安装19c数据库软件并启动实例,会立即触发ORA-00722或ORA-01503错误,因为19c内核无法解析11g ASM磁盘组元数据和RDBMS块格式。
RMAN还原后为什么startup失败?
还原的是11g物理文件,但19c实例启动时校验控制文件和数据文件头版本不匹配。常见报错是ORA-00704(bootstrap failure)和ORA-00702(version of file is not compatible)。这不是RMAN命令写错了,而是跳过了关键前置动作:
- 必须先用19c的
sqlplus / as sysdba连接,执行STARTUP UPGRADE(不是STARTUP MOUNT) - 挂载后立刻运行
@?/rdbms/admin/catupgrd.sql,这才是真正做字典升级的脚本 - 还原前没跑
preupgrade.jar?升级大概率卡在30%——尤其当DBA_OBJECTS里有大量INVALID对象时
逻辑Data Guard切换前必须停SQL Apply
autoupgrade只对逻辑备库生效,且必须在ALTER DATABASE STOP LOGICAL STANDBY APPLY之后才能执行。边同步边升级会导致静默挂起或ORA-00054: resource busy,因为升级过程要锁OBJ$等核心字典表,而SQL Apply也在持续更新它们。
- 确认已停:执行
SELECT STATE FROM V$LOGSTDBY,返回值必须是IDLE或APPLYING BATCH,不能是WAITING FOR LOGS - 升级命令示例:
autoupgrade -mode UPGRADE -oracleHome /u01/app/oracle/product/19c -config upgrade.conf - 升级报告写
SUCCESS≠同步恢复成功——后续必须重建LOG_ARCHIVE_DEST_2并补对象:EXEC DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCHEMA','TABLE_NAME')
COMPATIBLE参数不手动改,切换后几秒就报错
DBUA或autoupgrade都不会自动修改COMPATIBLE。升级完成后仍为11.2.0.4,会导致逻辑DG应用中断,报ORA-16112或UNIQUE CONSTRAINT VIOLATION。
- 必须手动执行:
ALTER SYSTEM SET COMPATIBLE='19.0.0' SCOPE=SPFILE,然后重启实例 - 主库也需提前启用补充日志:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA - 所有复制表必须有主键或唯一约束,否则
V$LOGSTDBY_SKIP里会大量报错 - LOB字段若未设
ENABLE STORAGE IN ROW,逻辑应用会跳过该列,造成数据不一致
最容易被忽略的是:升级后没重建ASM磁盘组兼容属性。11g的compatible.asm和compatible.rdbms仍为11.2.0.4,19c GI无法完全识别其结构,必须在升级完成后逐个执行ALTER DISKGROUP ... SET ATTRIBUTE 'compatible.asm'='19.0.0'和'compatible.rdbms'='19.0.0'。这步漏掉,后续加节点或扩容会直接失败。











