1:数据平台层级之间的数据迁移报错:字段类型不匹配
解决办法:改变目标表的相应的字段类型和字段长度即可(可以对表实行删表重建的处理,提前复制好表结构即可)
2:主键冲突:目标表里有主键,要迁移的数据表里也是对应字段有主键
解决办法:
insert into 库名.表名1
(
各个字段(包含主键字段)
)
select
各个字段
from 库名.表名2 T1
where not exists
(
seleect 1 from 库名.表名1 T2 where T1.主键字段 = T2.主键字段
);
注:可以通过Oracle库表直接查看插入表和目标表的主键有没有冲突,再去存储过程里添加相应的语句,也可以全部的存储过程都加上上述的语句。
2022年8月8日更新
最近项目进入二期,但是因为一期数据正确性的验证出现了比较大的问题,所以一直在拖累整个项目的进度,致使人员无法抽离,下一期的项目模块也无法如期的正常的运转起来。数据的验证迟迟无法结束,特此记录下来。
一期的时候在本地数据库,依据我们自己的开发的脚本,配合测试部门做了大量的数据和脚本取数逻辑的验证,期间有修改测试造的数据,也有修改脚本的取数逻辑部分的代码,进行了大量的优化之后,在本地数据库的测试基本没有了问题。
上线之后,接入了上游的数据库,大量数据迁移导入数据中台和本地的Oracle数据库,在大量数据的考验下,经过本地测试的大数据脚本也是正常的运行,但是最后的结果和预期 总有些字段存在着或多或少的差异,我们第一时间组织了大量的人手,进行专门的数据的验证,也一直在优化代码,上游的数据库也是一样,也是一直在优化代码,致使得到的数据进行比对,总是存在一定量的数据的差异。所以就出现了一种奇怪的现象,就是上游一直在改代码逻辑进行代码的优化,下游以上游的数据结果相应的做代码的更改优化操作,但是我们下游在经过研讨验证之后,有结论给出,我们自己的代码取数逻辑没有问题,就是说我们不能一直跟着上游的数据去走,上游的取数逻辑有问题,那么我们下游得到的数据 肯定会有不同,但是上游一直也不承认这个事情,就是一直闷头优化代码的逻辑,致使整个数据验证的工作迟迟无法解决,遇到了瓶颈。
通过这件事情可以得出结论:数据出现不正常的 差异,第一时间是应该去寻找自己大数据脚本的逻辑问题,但是也不能忽略掉上游取数逻辑的正确性,不然就会出现 上游数据和下游数据永远对不上,上下游都去修改代码逻辑的循环怪圈之中。