从浪潮k1到Oracle Exadata的跨版本数据库迁移

元鼎科技帮助某金融客户完成数仓迁移

Posted by 冯栋华 on January 16, 2019

背景

近期,元鼎科技帮助某金融客户完成了,有可能是”国内首例“的,从浪潮k1到oracle exadata一体机的数据库迁移,数据量达到数十TB。虽然正式迁移比较顺利,但前期方案选型、验证和测试的过程还是比较曲折的,主要是因为作为客户核心数据仓库业务,本次迁移面临多重技术要求上的困难:

  • 源端是国产小型机浪潮k1(IA-64,非标准X86架构),数据库版本为Oracle 10.2.0.5;
  • 目标端是Oracle Exadata x7,数据库版本为Oracle 12.2.0.1;
  • 停机时间有限,需要在8个小时内完成迁移,数据和业务验证;
  • 数据总量超过28T,每天数据增量数百G;

以及,各种体会不到的现场限制和困难,比如:

  • 客户没有足够的存储空间
  • 客户使用的k1已经没有厂商支持
  • k1操作系统内核经过更改,rac两个节点系统内核不一致
  • 网络协议,存储路径和权限等一系列问题

以及最重要的,我们确实没干过类似的迁移啊。。。所以注定是一场奇(qu)妙(zhe)之旅。

来自现场工程师的画外音:“上一次我进行如此大规模的跨平台、跨版本的数据库迁移,还要追溯到深圳电信aix小机到exadata一体机的迁移项目了,当时也是在业务不能中断的极端条件下,穷尽各种技术手段完成数TB数据的迁移…但好像这次的环境更复杂一些

方案选型

上面说了这么多,可能有人要问:“好像xtts从2015年都支持增量的U2L迁移了吧,不是已经有很多利用xtts实现数据库跨平台迁移的案例了吗?“ 确实如此,而且元鼎的Oracle技术团队也曾多次利用xtts帮用户完成过oracle数据库的跨平台迁移。所以,首先想到的方案就是xtts神器,主要是考虑最小停机时间和风险可控;

同时我们也制定了rman+upgrade的备用方案,先从10.2.0.5升级到11.2.0.4,然后再升级到12.2.0.1(注:由于两端数据库版本和系统版本差别较大,直接从10.2.0.5升级到12.2.0.1的风险较高)

前期准备

由于客户环境没有足够的存储空间,存放源库的原始备份数据,本计划通过千兆网络映射Exadata一体机的ASM空间到源端服务器,但用户的K1设备已经没有厂商支持,系统内核也经过修改(Rac两节点系统内核不一致),无法使用正常的Linux系统的安装包。最终通过ICFS和NFS协议将目标端存储空间映射到源端K1环境,来解决网络协议以及路径权限等一系列问题。

方案验证(测试)

首先验证xtts方案,在经过长达1周的初始备份和2天的数据还原之后,发现源库备份增量所需的时间较长,且时间不可控,这样就会导致正式迁移到生产环境的停机时间不可控。所以,XTTS方案被推翻,看来只有选择第二种方案了。

备用方案主要的设计思路如下:

  1. 在oracle一体机上先安装过渡版本11.2.0.4(参照oracle12.2升级路线图);
  2. 修改源库生成的参数文件,将compatible设置为11.2.0.4,并且去掉11G版本不支持的相关参数。
  3. 将10.2.0.5的rman数据还原到11.2.0.4,并完成upgrade;
  4. 将数据库从11.2.0.4升级到12.2.0.1

这种方案存在的风险主要包括:

  1. 数据库需要两次upgrade,升级过程中可能会有各种问题;
  2. 需要应用备份时间到停机时间的归档日志,才能保证数据的一致性;

想都是问题,做才有答案。经过漫长的测试和验证,尽管过程中也出现了各种问题,最终还是成功完成迁移测试,主要问题包括:

  1. rman初始备份多次不成功,原因是较大数据文件的备份需要限制每个备份片的大小;通过ICFS协议发现备份文件不可用,最后切换成NFS备份正常;
  2. recover的过程中,由于源库开启了块跟踪,所以recover失败;
  3. 由于源库开启了EM,在从10.2.0.5 upgrade到11.2.0.4的过程中,upgrade的过程中报错,最后修改upgrade升级脚本,将EM部分跳过;
  4. 从11.2.0.4 到12.2.0.1的upgrade脚本运行报错,最终通过分析upgrade脚本,在源端执行Preupgrade脚本检测失败项,并逐一修复解决;

附:升级到数据库12.2路径图(参考MOS文档ID 2297983.1)

能够直接升级到 Oracle 12c Release 2 (12.2) 的数据库最小版本:

源数据库 目标数据库
11.2.0.3 / 11.2.0.4 12.2.x
12.1.0.1 / 12.1.0.2 12.2.x

以下的数据库版本需要间接升级:

源数据库   升级路径   目标数据库
11.2.0.1 / 11.2.0.2 –> 11.2.0.4 –> 12.2.x
11.1.0.6 / 11.1.0.7 –> 11.2.0.4 –> 12.2.x
10.2.0.2/10.2.0.3/10.2.0.4/10.2.0.5 –> 11.2.0.4 / 12.1.0.2 –> 12.2.x
10.1.0.5 –> 11.2.0.4 / 12.1.0.2 –> 12.2.x
9.2.0.8 –> 11.2.0.3 / 11.2.0.4 –> 12.2.x

正式迁移

迁移过程:

  1. 在源库生成最新的Rman备份文件
  2. 在目标端的11.2.0.4的软件环境进行数据恢复及历史归档日志recover
  3. 停止源端数据写入,切换归档日志,然后将数据库设置为 readonly
  4. 将新增的归档再次做recover
  5. 将还原完成的实例upgrade到11.2.0.4的数据库版本
  6. 切换目标端的环境变量,将数据库实例的版本切换到12.2.0.1

由于在正式生产迁移之前,经过多轮的测试和数据验证,所以在正式迁移过程中,除11.2.0.4升级到12.2.0.1耗时较长外,其他步骤都符合预期,圆满完成本次迁移工作。

迁移完成之后,通过SQL的执行时长和其他一些指标的对比,数仓业务的整体性能提升近5倍。

选择元鼎,选择专业

最后通过一张现场照片,感受下元鼎Oracle团队几位工程师,在用户现场的专业和认真:) img-2019-01-17-am1.15.35