转载

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

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

正文到此结束