数据迁移之后，总是需要进行源库和目标库的核对，来判断本次数据迁移是否成功。以下采用DBLINK方法进行核对，是在工作中总结的，通过对象和数据量来进行判定数据迁移是否成功，如果以下核对内容完全一致，基本上可以判定迁移成功。DBLINK中的用户需要有DBA权限，在目标库中创建DBLINK。

一、核对迁移对象

找出迁移对象差异，如果查出结果，说明迁移过程中漏了对象，查询结果即为漏的对象。

SELECT *

  FROM DBA_OBJECTS@DBLINK_101701622 T

 WHERE T.OWNER = 'U_SJZX_WEB'

   AND T.OBJECT_NAME NOT IN (SELECT OBJECT_NAME FROM USER_OBJECTS T)

   AND T.OBJECT_NAME NOT LIKE '%$$%';

二、核对表的数据量

1.重新分析表的数据量,为了下一步能够获得准确的数据量，源库目标库都需要执行查询结果。

SELECT 'analyze table ' || TABLE_NAME || ' compute statistics;' FROM USER_TABLES;

2.找出数据量差异表对象

SELECT YB_BM  源表表名,

       YB_NUM 源表数据量,

       MB_BM  目标表名,

       MB_NUM 目标数据量,

       BDJG   比对结果

  FROM (SELECT T.TABLE_NAME YB_BM,

               T.NUM_ROWS YB_NUM,

               TT.TABLE_NAME MB_BM,

               TT.NUM_ROWS MB_NUM,

               CASE

                 WHEN T.NUM_ROWS = TT.NUM_ROWS OR T.NUM_ROWS IS NULL THEN

                  '相同'

                 ELSE

                  '不相同'

               END BDJG

          FROM DBA_TABLES@DBLINK_101701622 T, USER_TABLES TT

         WHERE T.OWNER = 'U_SJZX_WEB'

           AND T.TABLE_NAME = TT.TABLE_NAME(+)) A

 ORDER BY BDJG;

1.重新分析表的数据量,为了下一步能够获得准确的数据量，源库目标库都需要执行查询结果。

SELECT 'analyze table ' || TABLE_NAME || ' compute statistics;' FROM USER_TABLES;

2.找出数据量差异表对象

SELECT YB_BM  源表表名,

       YB_NUM 源表数据量,

       MB_BM  目标表名,

       MB_NUM 目标数据量,

       BDJG   比对结果

  FROM (SELECT T.TABLE_NAME YB_BM,

               T.NUM_ROWS YB_NUM,

               TT.TABLE_NAME MB_BM,

               TT.NUM_ROWS MB_NUM,

               CASE

                 WHEN T.NUM_ROWS = TT.NUM_ROWS OR T.NUM_ROWS IS NULL THEN

                  '相同'

                 ELSE

                  '不相同'

               END BDJG

          FROM DBA_TABLES@DBLINK_101701622 T, USER_TABLES TT

         WHERE T.OWNER = 'U_SJZX_WEB'

           AND T.TABLE_NAME = TT.TABLE_NAME(+)) A

 ORDER BY BDJG;

1、基础数据，通常这一类容易迁移，数据格式简单，但是会影响所有的相关业务数据，关注点为数据的主键和唯一键的方式。
2、纯历史数据的导入，仅供参考用的，这一类数据导入容易
 2.1 纯历史数据
 这一类数据处理起来会比较容易，一次性导入即可，后续采用增量数据导入。
 2.2 流程性数据
 这一类数据只有在记录完全关闭后才能结束，需要进行增量导入和数据更新，同时还要进行相关查询界面的开发，以保证旧有数据能够在新系统中查询的到。
3、新老系统表结构变化较大的历史数据
 这一类数据的工作量是最重的，就需要仔细去研究新老业务系统的数据结构了。
 1、尽量通过甲方单位来收集齐全相关原系统的相关设计文档，这一点对数据分析很有帮助，通过人的感觉和对数据的观察来分析毕竟不太靠谱。
 2、在原系统上进行相关数据的观察，了解数据的变化和数据表数据的关系（对于比较难以理解的相关字段很有帮助）
 3、比较新老系统数据的差异，如果实在很不靠谱的话，建议按2.2去处理。

  数据迁移之后，总是需要进行源库和目标库的核对，来判断本次数据迁移是否成功。以下采用DBLINK方法进行核对，是在工作中总结的，通过对象和数据量来进行判定数据迁移是否成功，如果以下核对内容完全一致，基本上可以判定迁移成功。DBLINK中的用户需要有DBA权限，在目标库中创建DBLINK。

 数据迁移之后，总是需要进行源库和目标库的核对，来判断本次数据迁移是否成功。以下采用DBLINK方法进行核对，是在工作中总结的，通过对象和数据量来进行判定数据迁移是否成功，如果以下核对内容完全一致，基本上可以判定迁移成功。DBLINK中的用户需要有DBA权限，在目标库中创建DBLINK。

一、核对迁移对象

找出迁移对象差异，如果查出结果，说明迁移过程中漏了对象，查询结果即为漏的对象。

SELECT *

  FROM DBA_OBJECTS@DBLINK_101701622 T

 WHERE T.OWNER = 'U_SJZX_WEB'

   AND T.OBJECT_NAME NOT IN (SELECT OBJECT_NAME FROM USER_OBJECTS T)

   AND T.OBJECT_NAME NOT LIKE '%$$%';

二、核对表的数据量

1.重新分析表的数据量,为了下一步能够获得准确的数据量，源库目标库都需要执行查询结果。

SELECT 'analyze table ' || TABLE_NAME || ' compute statistics;' FROM USER_TABLES;

2.找出数据量差异表对象

SELECT YB_BM  源表表名,

       YB_NUM 源表数据量,

       MB_BM  目标表名,

       MB_NUM 目标数据量,

       BDJG   比对结果

  FROM (SELECT T.TABLE_NAME YB_BM,

               T.NUM_ROWS YB_NUM,

               TT.TABLE_NAME MB_BM,

               TT.NUM_ROWS MB_NUM,

               CASE

                 WHEN T.NUM_ROWS = TT.NUM_ROWS OR T.NUM_ROWS IS NULL THEN

                  '相同'

                 ELSE

                  '不相同'

               END BDJG

          FROM DBA_TABLES@DBLINK_101701622 T, USER_TABLES TT

         WHERE T.OWNER = 'U_SJZX_WEB'

           AND T.TABLE_NAME = TT.TABLE_NAME(+)) A

 ORDER BY BDJG;

补充说明：PUBLIC类型的DBLINK是迁移不到目标库的，得需要手动创建。

————————————————

版权声明：本文为CSDN博主「zha_sir」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/zha_penfee/article/details/50098587

    数据迁移之后，总是需要进行源库和目标库的核对，来判断本次数据迁移是否成功。以下采用DBLINK方法进行核对，是在工作中总结的，通过对象和数据量来进行判定数据迁移是否成功，如果以下核对内容完全一致，基本上可以判定迁移成功。DBLINK中的用户需要有DBA权限，在目标库中创建DBLINK。

一、核对迁移对象

找出迁移对象差异，如果查出结果，说明迁移过程中漏了对象，查询结果即为漏的对象。

SELECT *

  FROM DBA_OBJECTS@DBLINK_101701622 T

 WHERE T.OWNER = 'U_SJZX_WEB'

   AND T.OBJECT_NAME NOT IN (SELECT OBJECT_NAME FROM USER_OBJECTS T)

   AND T.OBJECT_NAME NOT LIKE '%$$%';

二、核对表的数据量

1.重新分析表的数据量,为了下一步能够获得准确的数据量，源库目标库都需要执行查询结果。

SELECT 'analyze table ' || TABLE_NAME || ' compute statistics;' FROM USER_TABLES;

2.找出数据量差异表对象

SELECT YB_BM  源表表名,

       YB_NUM 源表数据量,

       MB_BM  目标表名,

       MB_NUM 目标数据量,

       BDJG   比对结果

  FROM (SELECT T.TABLE_NAME YB_BM,

               T.NUM_ROWS YB_NUM,

               TT.TABLE_NAME MB_BM,

               TT.NUM_ROWS MB_NUM,

               CASE

                 WHEN T.NUM_ROWS = TT.NUM_ROWS OR T.NUM_ROWS IS NULL THEN

                  '相同'

                 ELSE

                  '不相同'

               END BDJG

          FROM DBA_TABLES@DBLINK_101701622 T, USER_TABLES TT

         WHERE T.OWNER = 'U_SJZX_WEB'

           AND T.TABLE_NAME = TT.TABLE_NAME(+)) A

 ORDER BY BDJG;

补充说明：PUBLIC类型的DBLINK是迁移不到目标库的，得需要手动创建。

———

1、基础数据，通常这一类容易迁移，数据格式简单，但是会影响所有的相关业务数据，关注点为数据的主键和唯一键的方式。
2、纯历史数据的导入，仅供参考用的，这一类数据导入容易
2.1 纯历史数据
这一类数据处理起来会比较容易，一次性导入即可，后续采用增量数据导入。
2.2 流程性数据
这一类数据只有在记录完全关闭后才能结束，需要进行增量导入和数据更新，同时还要进行相关查询界面的开发，以保证旧有数据能够在新系统中查询的到。
3、新老系统表结构变化较大的历史数据
这一类数据的工作量是最重的，就需要仔细去研究新老业务系统的数据结构了。
1、尽量通过甲方单位来收集齐全相关原系统的相关设计文档，这一点对数据分析很有帮助，通过人的感觉和对数据的观察来分析毕竟不太靠谱。
2、在原系统上进行相关数据的观察，了解数据的变化和数据表数据的关系（对于比较难以理解的相关字段很有帮助）
3、比较新老系统数据的差异，如果实在很不靠谱的话，建议按2.2去处理。

1.该迁移方法有几个必须满足的前提条件：原服务器和新服务器都有安装好并且正常可用的 MySQL 和 Percona Xtrabackup 软件环境；网络可以连通，或者可以进行文件传输；
2.实际迁移切换时，需要考虑一下原数据库的状态，或者在进行备份后，停止原数据库或设为只读模式；或者提前进行一次恢复，做成主从同步复制，在切换时，设主库为只读，关闭主从复制。关键是保证切换开始后，原数据库不能有新数据写入，造成数据不同步或丢失；
3.数据库启动、停止过程中都需要及时监控 error.log 日志，确认整个具体启停过程；同时要及时通过进程、端口、日志状态等确认数据库状态。