总结一下昨晚在数据迁移前线奋战碰到的一些问题，虽然总体来说是按照预定的计划完成，并且提前完成，但是哪怕一丁点儿的操作都会导致一些严重的影响。

创新互联公司专注于企业成都营销网站建设、网站重做改版、罗甸网站定制设计、自适应品牌网站建设、H5场景定制、商城网站开发、集团公司官网建设、成都外贸网站建设公司、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为罗甸等各大城市提供网站开发制作服务。

   总体来说，需要做的事情就是把核心业务服务器从一个机房迁移到另外一个机房，这个过程中因为环境的重要性和硬件软件的情况，大体分为了下面三个方向的技术方案。

1. 迁移部分核心业务从Solaris到X86平台，同时需要升级数据库版本

2. 迁移x86平台的部分核心业务，这个方向操作相对简单，基本就是主备切换

3. 整合部分X86平台的环境，比如数据库a,b整合后就是一个数据库a

这些工作需要在几个小时内全部完成，而且保证不能出现数据类问题。

   技术方案1，是跨平台的数据库迁移式升级，我们采用了混合式的技术组合，比如对于小表，数据类不大使用Datapump来全量同步，对于中型表使用物化视图的prebuilt来达到增量刷新的目的，对于大型表，则使用OGG的复制方式，当然为什么中性型表和大型表要分开对待，都使用OGG行吗，可以的，这个主要还是考虑团队等的因素，而不单单技术可行。

  技术方案2，这个部分相对来说比较常规，就是主备切换。主备切换的过程其实没有更多可谈的了，完全没有理由切到一半切不动了。只要配置没问题，在DG Broker里面就一个命令即可。

   技术方案3，这个部分涉及数据整合，而且在这个基础上需要做一次数据库的升级,如果数据量不大，其实Datapump足矣，如果数据量在TB级别，要实现这类数据整合和升级的需求就有一些难度了，至少目前我看到的绝大多数情况是通过增量或者逻辑复制的方式。

   迁移的需求大体如上所述，维护时间是限定的，需要不到3个小时的时间内搞定，要么成功要么回退。

   我拿出几个迁移中碰到的问题，很多还是很有代表性，也是我们做技术方案的时候需要不断改进和完善的地方。

问题1：

在使用prebuilt的物化视图增量刷新的时候，在最后的数据确认阶段，再次尝试一次增量刷新，竟然抛出了下面的错误。

SQL> exec dbms_mview.refresh('GAMEUSER.PEAK_LOGINLOG','F');
BEGIN dbms_mview.refresh('GAMEUSER.PEAK_LOGINLOG','F'); END;
*
ERROR at line 1:
ORA-04062: timestamp of package "SYS.DBMS_SNAPSHOT_UTL" has been changed
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2809
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 3025
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2994
ORA-06512: at line 1
问题2：

还有一部分的物化视图增量刷新的时候会出现hang的情况，尽管主库的物化视图日志数据不多，但是这个刷新的过程就很慢。

 exec dbms_mview.refresh('TLBB.PURSE_RESERVE_RECORD','F');

上面的两类问题在时间不等人的数据迁移中，是很敏感的，所以如果这种一下，表数据量不是太大，就干脆直接全量同步或者Datapump来重新做。

还有一个技巧就是如果刷新的表极大，先优先查看物化视图日志，如果没有数据，心里就会踏实很多，哪怕刷新时出点小问题，心里还是亮堂的。

问题3：

在从源库使用DAtapump导出数据的时候，竟然抛出了错误，这对于依赖Datapump的迁移项目来说，不能很好的使用Datapump会困难重重，下面是一个基本的导出方式，当然在10g版本里面可能有点问题，比如使用了并行，导出的时候就可能提示溢出而失败。

expdp xx/xxx dumpfile=gameuser.dmp directory=dp_dir parfile=gameuser.par parallel=4

问题4：

这个问题是在数据库做了主备切换之后碰到的，看日志可以得知是归档的问题，但是实际上闪回区也足够，归档路径也是有效的。

Mon Jul 24 04:10:13 2017
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_1
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance acccomdb - Archival Error
ORA-16014: log 1 sequence# 31829 not archived, no available destinations
ORA-00312: online log 1 thread 1: '/U01/app/oracle/oradata/acccomdb/redo01.log'
Mon Jul 24 04:13:11 2017
Starting background process SMCO
Mon Jul 24 04:13:11 2017
SMCO started with pid=39, OS id=51303

初步分析发现是归档路径的不规范，比如设置的归档路径参数有多个，像log_archive_dest1,log_archive_dest2其实有不同的含义和用法，解决问题的方法就是把这些路径参数清空，重置DG Broker来初始化。见效快还一步到位。

问题5：

DB link的问题，说实话DB link在多个数据库间查取数据库，有点蜘蛛网的感觉。我们可以使用tnsping的方式来验证tnsnames.ora的配置。但是如果端口通了，不一定证明tns的配置没有问题。

比如下面的报错信息，都是DB link的问题，但是报错信息不同

  java.sql.SQLException: ORA-04053: error occurred when validating remote object GAMECARD.USECARDMAIN@DB_SWORD_TEST0

ORA-00604: error occurred at recursive SQL level 1
ORA-02019: connection description for remote database not found

java.sql.SQLException: ORA-04045: errors during recompilation/revalidation of APP_TL_SDE_128.CHONG_KAMI_RECHARGE_NEW?
ORA-04052: error occurred when looking up remote object TLBB.USER_POINT@GCDB?
ORA-00604: error occurred at recursive SQL level 3?
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

我们需要花一些时间来修复这类问题，排查的过程会因为信息提供的误差而偏离问题的方向。我们需要冷静一点，再细心一些。

本文题目：数据迁移中的几个问题总结
当前路径：http://lswzjz.com/article/gdeehp.html