datapump跨平台升级迁移的总结 (r8笔记第77天)
最近测试了使用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
这种情况在绝大多数的情况下还是没有问题的,就怕这类的数据冲突,所以为了稳妥起见还是需要跳过这些本来数据库中就有的默认用户。如果查看导入的明细日志,其实整个过程都会检查然后忽略,其实我们可以更彻底的屏蔽这些不必要的变更。 在这个基础上,就是考虑更好的性能,更短的窗口时间,可以做一些对比测试来逐步完善,当然这种测试时间还是比较紧的,所以需要更多的预备工作,保证在生产迁移中能够平滑过渡。
- JavaScript 教程
- JavaScript 编辑工具
- JavaScript 与HTML
- JavaScript 与Java
- JavaScript 数据结构
- JavaScript 基本数据类型
- JavaScript 特殊数据类型
- JavaScript 运算符
- JavaScript typeof 运算符
- JavaScript 表达式
- JavaScript 类型转换
- JavaScript 基本语法
- JavaScript 注释
- Javascript 基本处理流程
- Javascript 选择结构
- Javascript if 语句
- Javascript if 语句的嵌套
- Javascript switch 语句
- Javascript 循环结构
- Javascript 循环结构实例
- Javascript 跳转语句
- Javascript 控制语句总结
- Javascript 函数介绍
- Javascript 函数的定义
- Javascript 函数调用
- Javascript 几种特殊的函数
- JavaScript 内置函数简介
- Javascript eval() 函数
- Javascript isFinite() 函数
- Javascript isNaN() 函数
- parseInt() 与 parseFloat()
- escape() 与 unescape()
- Javascript 字符串介绍
- Javascript length属性
- javascript 字符串函数
- Javascript 日期对象简介
- Javascript 日期对象用途
- Date 对象属性和方法
- Javascript 数组是什么
- Javascript 创建数组
- Javascript 数组赋值与取值
- Javascript 数组属性和方法
- 解决php用mysql方式连接数据库出现Deprecated报错问题
- Laravel自动生成UUID,从建表到使用详解
- Python中Selenium库使用教程详解
- 浅谈laravel aliases别名的原理
- Yii2框架中一些折磨人的坑
- php获取是星期几的的一些常用姿势
- laravel 实现用户登录注销并限制功能
- PHP Swoole异步Redis客户端实现方法示例
- PHP全局使用Laravel辅助函数dd
- 在laravel中实现ORM模型使用第二个数据库设置
- laravel5.1 ajax post 传值_token示例
- Laravel框架处理用户的请求操作详解
- Laravel实现ORM带条件搜索分页
- Laravel等框架模型关联的可用性浅析
- laravel5.6中的外键约束示例