我们的文章会在微信公众号Oracle恢复实录和博客网站同步更新 ,欢迎关注收藏,也欢迎大家转载,但是请在文章开始地方标注文章出处,谢谢!
由于博客中有大量代码,通过页面浏览效果更佳。
今天分享一个几年前做的一个三甲医院的SUN到X86环境的一个11.2.0.4的迁移案例,分享的初衷来跟一个朋友的迁移的交流,讨论在医院行列中怎么快速的实现小机环境到X86的迁移。这里为什么要说是医院行业呢?因为医院行业跟其它的行业有一些差异性。
- 医院系统各系统很混乱,医院系统不算多,但是多数医院中各个系统由不同的厂商开发,各系统之前相互交叉,所以迁移一个系统关联多个系统,并且很多连调测试。
- 医院里面存在很大的技术壁垒,就如前面说的各系统由不同厂商开发,相互之间存在技术壁垒,相互之间的访问可能都关系到额外的费用。
- 医院系统大量使用LOB字段,特别是电子病历系统、PACS系统和HIS系统(比较老的),很多系统中,LOB字段的容量就占了整个数据库的30%的容量,并且还是一个LOB字段,特别是没有分区的的LOB,采用自带的逻辑迁移,那效率是杠杠的慢,当然基于rowid分片的技术可以规避这个问题。
- 医院系统技术迭代慢,很多医院的系统、硬件、数据库使用的时间都长达10年以上,受限于各种迁移技术的限制和性能的限制。
- 医院IT投入成本低,最近几年随着区域医疗、医院数字化等政策的政策的刺激,医院IT的投入的比例逐渐的增多,但是相比医疗上的投诉,IT投入的比例还是非常低的,导致很多好的产品、好的解决方案、好的专业的人才无法服务于医院IT系统中。
- 医院IT技术参差不齐,虽然医院系统个数不是很多,但是“麻雀虽小五脏俱全”,网络、存储、数据库、系统、容灾、监控、桌面电脑、打印机等等什么都还是,并且每一样可能还有多个厂商的产品,同时医院信息科的人员一般就只有几个人员,所以要求他们精通,真的太难了。
扯远了,回到跟朋友的交流话题,医院里面小机环境到X86迁移时,朋友认为首选XTTS迁移,然后再考虑其它的方案,理由就是跨平台迁移时,XTTS非常简单,使用Oracle提供的脚本就可以解决。XTTS方案虽然是11.2.0.4引入的方案,也算比较新的方案,解决了之前很多方案存在的不足,但是XTTS迁移确认“非常简单”,通过官方的脚本,修改几个参数就可以迁移了。但是XTTS真心的不简单,真心的非常不简单,只是Oracle通过脚本的方式屏蔽了技术的复杂度,但是如果遇到BUG时,或者脚本没有考虑到的场景时,那才是非常痛苦。记得15年给某省电信做AIX、HP迁移到X86时,那时官方自带的脚本还不支持ADG平台做为源端复制数据文件和新增加数据文件时,自己是把整个XTTS里面每一步操作先手动验证通过,再通过shell脚本做成自动化的脚本,脚本实现ADG作为源端迁移数据库、自动全量、自动传数据文件、源端支持raw和asm、自动covert、自动前滚、支持数据文件级别的并行、自动识别主备环境及相互转换、自动判断全量和增量等工作,从此那个省后期的XTTS迁移全部使用这个脚本,节约了大量的时间,同时除了第一套、第二套是我迁移的意外,后期的都是其它的同时使用这个脚本来迁移的。XTTS迁移方案,我认为还是目标最复杂、风险最大的迁移方案,如果遇到BUG,可能就会导致整个迁移失败,所以对我来说,除非是其它的迁移方案不能满足客户需求时,才会选择XTTS迁移方案。
数据库迁移难的不是迁移技术,而是选择满足客户需求的迁移方案,只要迁移方案选择对了,基本上整个迁移项目就已经成功了80%,后续就是具体操作的内容,只要细心一点就可以了。
怎么选择一个合适的迁移方案,基本上我们为考虑如下几点内容,越靠前,权衡越重
- 停机时间
- 版本是否变化
- 是否跨平台
- 数据量(存量、变换)
- 硬件物理资源
- 迁移对象
- 程序管控能力
常见的数据库迁移方案如下,也可以相互组合:
- 数据库逻辑迁移(包括但不限于expdp\impdp\exp\imp\create as select)
- XTTS(包括TTS)
- ADG(DG)
- RMAN备份与还原
- OGG、DSG等
- 第三方文件系统(VERTAS SF等)
根据需求和每个迁移方案的优缺点,选着合适的迁移技术或者组合的技术。
回到几年前的做这个医院案例,这个医院的迁移背景很搞笑的。环境信息如下:
- 平台:SUN
- 数据库版本:11.2.0.4
- 系统:主要是his、电子病历,还有很多其它小业务系统。
- 迁移时间:4个小时
- 数据量:2T左右
在迁移找了很多所谓的专业的迁移公司给他们做迁移方案,但是当工程师现场收集完信息后,都选择放弃了,最后来到公司的销售,希望我们收集信息,看是否可以搞定。将迁移脚本发给客户,远程指导客户收集完信息,同时了解完客户需求,明确给客户和销售恢复,这个事情可以搞,让销售去谈业务。
在前面的环境信息少二个核心信息,就是迁移对象和程序管控能力,通过脚本和询问完善了这部分信息。
- 客户有几千用户。
- 业务用户、SYS、SYSTEM等都有业务对象
- 存在LOB字段,单个LOB字段最大为90G
- 设计程序完全是采购的,部分程序已经无开发厂商了。
通过以上信息汇总后,选择逻辑迁移方案(impdp+network_link和基于rowid分片)。
最后整个数据迁移的时间在2个小时(包括数据校验的时间),完全满足客户的预期。
真实的迁移方案的操作步骤如下,整个迁移都是复制、粘贴方式运行,迁移对象都是通过脚本在运行时自动生成和自动执行的。
——————作者介绍———————–
姓名:黄廷忠
现就职:Oracle中国高级服务团队
曾就职:OceanBase、云和恩墨、东方龙马等
电话、微信、QQ:18081072613
公众号二维码:
个人微信二维码
案例分享:医院行业数据泵迁移最佳实践案例分享:等您坐沙发呢!