手工迁移数据库Oracle 11.2.0.4到新机器并升级到12.2.0.1版本

3    962    5

👉 本文共约1524个字,系统预计阅读时间或需6分钟。

前言

在最近的项目里,客户有2套11.2.0.4的数据库,需要迁移上云,数据量较大(一个600g,一个2T),停机时间6小时以内,还有很多其它的库需要同时切割,目前想到的迁移方案有:
1、XTTS进行全量+增量迁移

缺点:物理迁移,在最后一次增量的时候,源端数据库需要设置为只读模式,只能读,不能写。云端数据库在最后一次增量之前都不能使用。

由于客户需要提前做POC测试,而且网络不是直达的,需要经过中转机,所以,该方案放弃。

​ 2、使用数据泵+OGG方式

缺点:逻辑迁移,对于特殊的列不能同步(例如long列),需要正式切割前进行大量的实验观察,否则可能造成个别数据不一致。

这个方案,我想着使用OGG的微服务会比较好,结果安装了好几个版本的OGG微服务(从12.3到21.3),兼容性都不支持11.2.0.4,无奈只能放弃!

​ 3、进行全量+增量的rman备份恢复,最后做数据字典升级。可以使用手动脚本升级,也可以使用DBUA升级,也可以使用最新的AutoUpgrade工具升级。

缺点:数据字典升级时间稍微长点,预估1~2小时左右,但可控在切割时间内。

优点:方案成熟,变数少,可以做压缩备份,减少中间网络传输的时间。

本文我们使用方案3来做演练。

环境介绍

手工迁移数据库Oracle 11.2.0.4到新机器并升级到12.2.0.1版本

参考文档:

源端准备

源端全备

拷贝全备文件+密码文件+tnsnames.ora+sqlnet.ora到目标端

目标端恢复全备

源端增量备份

目标端恢复增量备份

目标端升级数据字典

准备工作

开始升级

升级过程:

数据字典大概1个小时。

升级后操作

最后组件的状态:

使用rman全备+增备+dbupgrade成功异机升级到12.2.0.1.

总结

1、如果在原Oracle 11g数据库系统中,有使用WM_CONCAT函数,那么在升级到12c后会报错:ORA-00904: "WM_CONCAT": invalid identifier,解决办法请参考:https://www.xmmup.com/ora-00904-wm_concat-invalid-identifiercuowujiejue.html

2、只有在编译失效对象完成后,dba_registry中的statu列才会变为VALID。若编译过程很慢,那您得找一下原因了,找找是否有大量存储过程,而存储过程中含有dblink连接等问题,等这些问题修复后,再编译起来就很快了。编译脚本:

    头像

    小麦苗

    学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

    您可能还喜欢...

    3 条回复

    1. 头像 小麦苗说道:

      文中所说的数据泵+ogg方式其实是可行的,不能使用微服务,但是可以使用传统模式,请参考 https://www.xmmup.com/shiyongogg-21-3yuanchengshishihuxiangtongbuoracle-11-2-0-4shuangzhu.html

    2. 头像 xnyfred说道:

      这个升级,目标机器12C 中没有PDB,只有CDB吧?

    发表评论

    您的电子邮箱地址不会被公开。

    13 + 2 =

     

    嘿,我是小麦,需要帮助随时找我哦
    • 18509239930
    • 个人微信

    • 麦老师QQ聊天
    • 个人邮箱
    • 点击加入QQ群
    • 个人微店

    • 回到顶部
    返回顶部