datapump跨平台升级迁移的总结-阿里云开发者社区

开发者社区> jeanron100> 正文

datapump跨平台升级迁移的总结

简介: 最近测试了使用datapump来迁移百G数据的场景,因为实际需要,需要把Unix下10gR2的库迁移到Linux下11gR2,所以这个过程相对来说牵制也较多。考虑了多种方案,最后权衡后决定使用datapump来迁移。
+关注继续查看
最近测试了使用datapump来迁移百G数据的场景,因为实际需要,需要把Unix下10gR2的库迁移到Linux下11gR2,所以这个过程相对来说牵制也较多。考虑了多种方案,最后权衡后决定使用datapump来迁移。
其实整个迁移的过程还算顺利,完整模拟了整个生产环境的迁移情况,datapump的全库导入还是比较方便省心,只要导出得当,导入基本不需要太多的检查选项,导入的过程中的可操作选项也非常有限。如果数据库里存在大量的结构信息,而且关系错综复杂,使用datapump还是比较通用快捷。
datapump对于中小型的迁移场景来说还是比较合适,里面的一个优势就是并行,但是实际中的并行情况粒度还不够细,
比如对于下面的这个表,尽管数据量还是比较大,但是导入的时候还是按照表为单位,无法在表级更细粒度做更多的工作。

Worker 10 Status:

  Process Name: DW09

  State: EXECUTING                     

  Object Schema: TEST

  Object Name: SWD_BACKPOINT_LOG

  Object Type: DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA

  Completed Objects: 1

  Completed Rows: 10,795,489

  Completed Bytes: 2,873,852,728

  Percent Done: 32

  Worker Parallelism: 1

当然数据量百G迁移还是很快到,使用datapump迁移时,首先会导入哪些结构型信息,然后导入数据,最后创建索引,大体的性能消耗点就在这三个方面。
对于迁移中存在的一些小问题也总结了一下。
1.首先就是归档的情况,在归档模式下,这个导入的过程是两份写数据,一份写入日志,一份写入数据文件,所以IO会有很大的压力。归档还是需要重点关注。

ORA-19815: WARNING: db_recovery_file_dest_size of 214748364800 bytes is 100.00% used, and has 0 remaining bytes available.

2.数据问题
如果导入的过程中出现了下面的报错信息,其实还是很无奈的。不过这类数据着实是少数,而且出现这个问题也是约束的校验方式不够严格导致。

ORA-12899: value too large for column DES (actual: 51, maximum: 50)

ORA-12899: value too large for column DES (actual: 53, maximum: 50)

ORA-12899: value too large for column DIST_SEX (actual: 3, maximum: 2)
如果数据量不大,也可以适当对字段进行扩展,当然是在业务允许范围内,或者由应用来评估是否需要这批超出限制的数据。
3.数据库日志中的警告
在数据导入的过程中,留意到数据库日志里面有如下的告警信息:

WARNING: Oracle executable binary mismatch detected.

 Binary of new process does not match binary which started instance

issue alter system set "_disable_image_check" = true to disable these messages


这个问题主要在数据库open时打patch有关,所以唯一能让我想起来的就是,前些天做orion测试的时候,因为配置的误导,自己relink了整个$ORACLE_HOME,所以对于这个问题的彻底解决还是可以重装数据库软件。
4.导入过程中的控制粒度不足
如果全库导入的过程中,没有太多的选项限制,就可能出现下面的警告信息

ORA-31684: Object type USER:"OUTLN" already exists

ORA-31684: Object type USER:"ANONYMOUS" already exists

ORA-31684: Object type USER:"OLAPSYS" already exists

ORA-31684: Object type USER:"SYSMAN" already exists

ORA-31684: Object type USER:"MDDATA" already exists

ORA-31684: Object type USER:"MGMT_VIEW" already exists

ORA-31684: Object type USER:"SCOTT" already exists

这种情况在绝大多数的情况下还是没有问题的,就怕这类的数据冲突,所以为了稳妥起见还是需要跳过这些本来数据库中就有的默认用户。如果查看导入的明细日志,其实整个过程都会检查然后忽略,其实我们可以更彻底的屏蔽这些不必要的变更。
在这个基础上,就是考虑更好的性能,更短的窗口时间,可以做一些对比测试来逐步完善,当然这种测试时间还是比较紧的,所以需要更多的预备工作,保证在生产迁移中能够平滑过渡。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
【换脸AI升级版】面部表情、身体动作、视线方向都能实时迁移
“变脸”技术已经不新奇,来自德国慕尼黑工业大学、斯坦福大学等的一组研究人员最近开发了一个叫“HeadOn”的AI,它可以“变人”——根据输入人物的动作,实时地改变视频中人物的面部表情、眼球运动和身体动作,使得图像中的人看起来像是真的在说话和移动一样。
1451 0
怎么设置阿里云服务器安全组?阿里云安全组规则详细解说
阿里云服务器安全组设置规则分享,阿里云服务器安全组如何放行端口设置教程
8378 0
《PhoneGap精粹:构建跨平台的移动App》——导读
本节书摘来自异步社区《PhoneGap精粹:构建跨平台的移动App》一书中的目录,作者 【美】John M. Wargo,更多章节内容可以访问云栖社区“异步社区”公众号查看
1095 0
12. Html5的局:WebGL跨平台的取与舍
# 紧接上文 在阅读WebKit源码中,讨论了Canvas在iOS平台使用的CoreGraphics框架作为渲染的工具,它运行在CPU上。WebGL是直接运行在GPU上的API,因此优化空间更大,对程序员要求更高。这次我们看看,WebGL如何对格式转换的,为我们后续three.js导入数据模型做铺设。 #常见的纹理格式 ## OpenGL ES2.0在多终端的差异 在WebKit中,默
3373 0
Elasticsearch 跨集群数据迁移方案总结
Elasticsearch 跨集群数据迁移方案总结 -- elasticsearch-dump、reindex、snapshot、logstash
204 0
+关注
jeanron100
Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
1180
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
《2021云上架构与运维峰会演讲合集》
立即下载
《零基础CSS入门教程》
立即下载
《零基础HTML入门教程》
立即下载