我参与过一些迁移项目,其中一个关键部分一直是数据协调。
我只能谈谈我们采取的方法,基于可用工具和最大限度地减少停机时间的限制,以及可用空间的限制。
在所有情况下,我都会编写在两个层面上工作的脚本——摘要视图和“深入研究”。我们找不到任何现成的工具可以及时完成我们想要的工作。事实上,即使是我们发现的迁移工具也有局限性(datapump、sqlloader、golden Gate 等),并且需要手动编写脚本来处理我们发现标准工具中缺少或太慢的位。
摘要视图因项目而异。它部分是基于功能的(使交易的会计数据匹配)供用户验证,部分是技术性的。对于较小的表格,我们可以只编写简单的报告,并且差异很直接。
对于较大的表格,我们编写了查看数据带的技术报告(例如,将 PK 分组为 1000 个)收集所有列数据并生成校验和,为每个表格生成报告,如下所示:
PK ID Range Start Checksum
----------------- -----------
100000 22773377829
200000 38938938282
.
.
然后将来自每个数据库的对应表对相互“区分”以突出差异。然后可以更详细地查看发现的任何差异。
脚本的编写方式允许它们在查看离散波段时并行运行。 Te 波段范围也是可调的,以获得最佳吞吐量。这显然加快了速度。
脚本是触发 sqlplus 报告的 shell 脚本,与源数据库类似。
在一个项目中,没有足够的磁盘空间来做这些报告,所以我编写了一个 Java 程序,它并排查询两个数据库,使用块队列来获取和比较行集。在内存中意味着这非常快。
对于“深入研究”,我们查看了关键表或报告校验和差异的表的详细信息。
对于用户报告,用户会指定他们想看到的内容,我们相应地编写报告。
在上一个项目中,发现的唯一差异是由字符集转换问题(未正确处理带重音的人名)引起的。
在整体数据集较小的项目中,我们将数据提取到 XML 文件中,并编写了一个 Java 工具来处理对和报告差异。