最近在分析一个迁移案例的时候，突然多了一些额外的想法，也算是对原有方案的一个补充。
比如存在两个数据库 peak和esales,彼此是独立的业务，所幸两者也没有用户的冲突等，都在10g版本，如果需要把他们整合到11g的环境中，迁移的方案就是一个重中之重。
因为这两个库的数据量不大，都不到200G,所以迁移的时间估算下来在2个小时还是可行的。
初步的想法就是常规的逻辑导出导入，比如使用数据泵来做。按照以往的经验，每个数据库大概会在40分钟左右完成。两个加起来就是80分钟左右。
如果碰到点意料之外的情况，两个小时的时间还算是宽裕的。
而这个过程中涉及到的一个重要风险点就是备份的传输，导出和传输的时间是忽略了的，这样一来，在网络带宽邮箱的情况下，很可能出现瓶颈，就在于网络上，这一点上如果过度依赖于一些平台环境，就很可能出现不可控的情况，说实话整个迁移的过程中大半的时间都在传输和导入的过程中。
如果把这个过程优化一番，能优化到多少时间呢，对此一个直接的方案就是把数据预处理的工作提前做好，如果能够避免重复的数据导入工作，那么我们就可以考虑其他的方案，所以我想了如下的一种方案，相对来说对于硬件和平台的限制会大大降低，那就是通过Data Guard和传输数据库结合的方式来满足需求。
注意上面的图中，两个备库都是在10g，他们的唯一差别其实就是在于这个系统表空间的部分，单纯说数据字典的信息，其实导入数据字典的工作要简单许多。
如果简单估算一下，切换主备库角色5分钟，导入数据字典串行来做，每个大概是10分钟，数据文件路径不变，直接使用传输数据库的方式来做，这样在迁移的时候就能够避免拷贝数据文件，直接把数据的工作都提前准备好，无论是路径还是参数配置，在维护的时候就会很平滑的完成。
整个方案预估是30分钟内完成，不受网络的限制，不受数据量的直接影响，相对来说提前需要准备的工作量会大一些，但是对于业务的可持续性来说，算是一个福音。
