迁移式升级的一点思考

目前有一个很实际的需求，因为硬件老化严重，需要能够借助一次维护时机把数据库迁移到一台较好配置的机器上，避免潜在的硬件故障导致的业务停顿，也算防患于未然吧。
本来这个事情不是很紧急，但是因为硬件故障导致的问题防不胜防，踩过几次坑，就会有些经验教训，在这种情况下维持现状就是一个潜在的炸弹。
当前的硬件环境是Solaris，Oracle 10gR2 单实例,数据量在800G左右。我大体想了下，主要的目标有以下几个。
    1.借助这次维护的时机，能够把数据库升级至11g
    2.升级的过程需要尽可能保留一个较短的时间窗口，计划在2个小时以内完成
    3.有较好的解决方案去演练整个过程，多次总结，提高迁移的效率，保证质量
    4.有完善的回退计划，能够支持回退场景下业务平滑过渡
    5.目前对于跨平台没有明确的要求，可以继续使用Solaris，也可以考虑跨平台，但是影响范围要小。
大体就是如上的要求，这是我的想法，也得我自己想办法来落实这些问题：）
有以下几种方式可以做，不过都是在评估和考虑。
    exp的方案肯定是pass,这个数据量迁移2个小时是完全不可能。
    expdp的方案2个小时也是无法达到，有两个瓶颈，一个是CPU使用的瓶颈，导出dump,导入dump得依赖于系统资源，二是主库还得备有额外的空间，三是网络的瓶颈，传输dump这个地方无法控制，而且因为硬件老化，网卡在大批量并发的情况下出现故障那就悲剧了。
    OGG的方案可行性高，之前和几个兄弟讨论过，先在备库的基础上基于SCN做全量同步，再设定数据同步的频率从主库同步，这样第一次的初始化对于主库的压力大大降低。不过有个问题是服务器实在是年岁已高，不能完全保证在主库，备库折腾一番，服务器还依旧吃得消。当然这个也是借口啦，OGG也得花一些时间才能玩得转。高效，可控的基础是熟练掌握它。
    使用XTTS的方案也不错，技术实现上肯定是妥妥的。这种方案的一个瓶颈还是在于网络的带宽，而且XTTS的方案实现在10g版本上还没有亲自尝试过，如果试水，还是有一些风险。
    使用DBUA的方式来升级，也是一个不错的方案，先使用Data Guard切换，然后直接升级至11g，图形的方式或者是命令行的方式均可。这种方式的优点很明显，升级前的检查和准备足够充分，升级数据库的时候就会平滑许多，自己也这么参与过不少的案例。这种方案和数据量就没有太大的关系了，升级的本质就是升级数据字典，所以这部分的时间主要就花费在升级上。
    还有一种方案自己也在琢磨中，那就是Data Guard+TTS，实现的思路大体是备库上创建一个11g同名的数据库，然后原来10g的数据库Failover变为主库，导出元数据，然后修改11g数据库的配置，导入元数据，这个过程中出了系统表空间外，数据表空间不动。这样就可以直接避免文件迁移带来的很毒瓶颈和限制。
    这几种方案个人比较喜欢最后一种，先说维护窗口，如果免去了拷贝数据文件的时长，那么导出导入的过程就会很快，应该比手工/图形方式升级数据库还要快。如果保证能够反复演练，可以合理利用备库的闪回功能，failover之后闪回照样能够修改为物理备库正常应用日志，为了方便演练，可以拷贝一份数据的镜像，随时启用，这样10g,11g的库都可以正常运行。一旦出现灾难，直接把连接切到原来的主库端去即可。