跨平台的oracle迁移对于企业在目前来讲是比较少碰到的.碰到跨平台项目一般都是碰到数据整合,或者项目升级的情况.这里我以个人的角度浅浅的描述下oracle跨平台迁移涉及到的一些技术以及解决方案,顺便附上关于这方面的资料,只作个人的闲余消遣,更多的是我把我某一个项目中关于oracle迁移的经验思路理出来作分享
Oracle跨平台迁移一般使用手段便是如下所列的几种：
1.使用export工具，包括Datapump，对于Datapump，要求数据库为10.1.0.2以上版本
2.10G 或更高版本可使用 Transportable Tablespaces（TTS）。
3.10G 或更高版本可使用 RMAN Convert Database 功能。
4.Streams 流复制。
5.Create Table As Select (CTAS)
6.Dataguard 基于异构平台的物理主备库。
7.Oracle Golden Gate
每种办法都会有其优势和局限，包括数据类型、所需时间和潜在成本，我列举一个我迁移项目的例子：
(如要转载请标注原创）.
首先平台环境,原始环境平台：
oracle 10203 aix 5203
目标环境平台：
oracle rac 11.2.0.3.8 OElinux 6.1 aix 5203
这是我一个金融行业用户的核心生产要升级的项目,从Ibm的aix平台迁移到linux 平台,单机变双机,数据库版本也横跨了大版本.那么在项目初期,客户的期望就是我要迁过去,这样硬件升级还能有双活节点,有高可用做保障,对于DBA怎么迁移,他可不管,也不会问到非常细的环节(每个客户都是不一样的).那么作为乙方,我认为在处理这样的项目的时候,从接手开始就应该尽量的把你专业的一方面表现出来,尽可能的考虑到各种情况.这个升级项目涉及到的方方面面,在这个项目中我通常首先要了解的是时间窗口、整个DB的数据量,在我这项目中一开始我得到的信息为时间窗口是24小时,数据量是600多g.哟呵,有点儿意思,时间很充足,数据量马马虎虎,在这个行业里算大了,眼看就要想要用什么技术来迁移了.其实还早,时间窗口是用户确定了足信,至于数据量更多时候我一定会到数据库里再确定一次,那么怎么确定正确的数据量?确定数据量的办法挺多,肯定会有人说看dba_data_files的总和减去dba_free_space，剩下的就是实际数据量了，没准还会有更可爱的说看tablespace占了多少.哎呀其实都没错，在一些特定的技术环节下是要看这些，但是这里我想补充2个信息，就是从exp或者datapump的导出dump文件大小以及用rman做备份后的实际的备份集考虑.这只是在选择迁移技术前的信息判断而已,这些信息是越多越好,我最终选择的技术还是使用expdp，没有选择tts或者是dg.
那么为啥呢？别急容我慢慢述来.
1.数据量实际大小为290G,这与用户的描述有出入,经过了解是因为客户是通过sql语句来计算容量的，而实际上客户经常对一些历史表做delete的清理，并未做空间的回收操作，这样就会有大量的空间实际上是没有数据但是确占用着表空间容量的.得出这个数据后我逐测试了下exp和expdp的在生产系统空闲时间段的导出时间,expdp导出大小为270左右,开8个并行耗时80–120分钟.
2.在搭建好的linux平台（未来的核心平台）上测试导入时间，采取并行,索引分离,扩大PGA，分用户（应用用户相对独立）双节点导入等手段,最终在导入时间可以控制在80分钟以内.
那大头为什么不用tts或者dg,ogg,stream呢？
.
1.tts虽然我用的次数挺多,这里不用是因为用户表空间建的较大,整体加起来接近2t,表空间众多,操作繁冗.
2.虽然dg支持aix和linux的异构同步,但是这里对停机时间要求没有很严格，而且如果用dg一开始就要对生产系统停机维护,还需要规避bug.最重要的是,大头对这个技术虽然做过测试,但是经验不足，我不能保证会没有问题.我肯定会选择我可控的胸由成竹的技术.
3.ogg很美好，但是转眼想下，做ogg有必要么？初始化过程就相当于一次迁移了.又不需要无缝停机,即使真的无缝停机,ogg也不大可能会满足要求的,因为注定要经过一翻波折之后ogg才会这服在你额运维手段之下.
4.stream,快要淘的技术了,转眼像在ogg上复活了,ogg我都拒绝了,流再见吧.
理解了大头的用心良苦了么？汇总下上面的信息
项目起始选择迁移方式无外乎要注意几个重点：
1.尽可能多的收集和迁移相关的信息,而且要亲自去确认排除可能的情况
2.如果有测试数据支持,那么方案将更加有说服力
3.尽可能去结合项目的场景要求选择自己熟悉的适合技术,不要为项目,为自己,为技术团队添加意外的风险
4.如果遭遇客户的追问,123就是你的答复.
其实这个项目在使用datapump过程也对工程师的技术要求较高,虽然本身datapump的技术并不复杂,但是需要考虑的方面很多,我总结如下：
1.dblink，无论是出去的，还是进来的dblink都需要做一遍梳理.11.2.0.2之后重建dblink可以使用转换过的密码直接重建哦！
2.函数，同义词与dblink的依赖需要格外关注
3.物化视图迁移到11g后是一起迁移的，需要关注迁移后的物化视图是否为正常状态
4.导出的dump文件传输到目标库的时间是要计算到整个迁移时间的
5.统计信息最好不要一起迁移
6.如果导入过程碰到约束错误不要慌，报错的表可以在后续重新导入
7.在导入完成后需要验证每个用户下的对象信息是否与原库相符,最好有类似veridata软件对比原库和目标库行数信息的工具来支撑，否则就需要应用来做验证数据迁移的完整性
8.迁移的回退工作,万一遭遇datapump的bug,如何快速恢复初始环境？最好是在导入之前做一份目标库的rman全备份.
9.记得把temp表空间设大,把pga调大,把DB的归档关闭.
有不足的地方大家继续补充~欢迎大家斧正.
以上这就是一个最基本的迁移工作要注意的环节，以及datapump的使用注意事项.其他跨平台迁移方式相关资料大家可以参考如下，
luadtou
Note.556636.1 Oracle Server – Export Data Pump and Import DataPump FAQ
Note.351598.1 Export/Import DataPump The Minimum Requirements to Use Export DataPump and Import DataPump (System Privileges)
Note.243304.1 10g : Transportable Tablespaces Across Different Platforms
Note:371556.1 How move tablespaces across platforms using Transportable Tablespaces with RMAN
Note: 413484.1 Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration
NOTE:1401921.1 – Cross-Platform Database Migration (across same endian) using RMAN Transportable Database
NOTE:62290.1 – Changing between 32-bit and 64-bit Word Sizes
