1.问题发生时间和处理过程
环境信息：
源端：oracle 11g
目标端：OcceanBase 3.2.3.3
oms：3.3.1-bp2
问题发生时间点：
2023年02月14日 18：04
问题故障处理过程:
2023年02月15日 10点，某核心系统oracle迁移OB，进行第四轮校验，发现有条链路store异常退出，重拉失败，新拉store覆盖问题位点仍然在该时间点异常退出。
2.问题故障分析过程
1. 因为环境最初设置过乱码数据的跳过，非法时间的ora报错也有设置跳过，所以一开始思路没有考虑这块
###设置乱码数据跳过 oms_cm: insert into config_template(task_type,db_type,task_version,`key`,value,scope,file_name,file_path,gmt_created,gmt_modified,dest_db_type) values('checker',null,'1.0','image.insert.error.ignore','true','datasource','checker.conf','/home/ds/run/{taskname}/conf/',now(),now(),null); |
2.查看报错日志
最终的报错显示oracle日志convert failed怀疑是归档日志有问题
3. 检查源端adg的归档日志没有断档，其他的store还没有问题，怀疑logmnr解析有问题，手动解析问题时间点的归档日志，也都正常
4.再次查看日志，找最初的报错时间点PS: CC.TEST1为脱敏后表名
[2023-02-15 10:43:46.764] [WARN] [pool-10-thread-2] [caused exception value:2007-03-05 254:00:00] [2023-02-15 10:43:46.764] [ERROR] [pool-10-thread-2] [Can not convert Column: name = CC.TEST1 column meta:36/CERTSTARTDATE/null/DATE/7/0/0/true/false/false/null/null; value = 786b0305ff0101] [2023-02-15 10:43:46.765] [ERROR] [pool-10-thread-2] [convert LogRecord: {id: 2661281 scn: 18280675722733 rowid: AA05+FAAUAAAtQKAAA timestamp: 1676369320000 type: INCREMENT_UPDATE table: 4992581 transaction: 1.0x11f3a3.000c1b45.00e0 fileid: 0 blockid: 1 |
发现问题原因是入了不合法的时间2007-03-05 254:00:00 导致store异常，将该表在链路暂时屏蔽，拉起正常，位点推进之后重新添加回来，对于该表屏蔽时间段的数据差异，单独校验进行数据订正。
因为之前writer修改过跳过非法日期的报错的代码，所以一开始store异常没有考虑到这块，一般非法数据都是类似2月30日之类的不符合规范的数据，这次出现了超过位数的小时单位，在logmnr解析数据之后oms无法convert成符合规范的数据，所以没有办法跳过。
结论：‘
国产化过程中的数据同步一直都是重中之重，如何保证数据不丢失数据的一致性，是客户最关心的问题之一，所以可以在迁移前期引导客户做好数据治理，好的数据质量也会让迁移变得顺利。
沉舟侧畔千帆过，病树前头万木春。仅记录该问题及原因为后续同仁提供参考。
行之所向，莫问远方。
