本身这两个其实没有关联性
- 事情的起因是由于一个误操作，本来update where id=xxxx，结果where没带变成了全表更新，且提交了。
- 但凡出现这种情况，操作人员一旦意识到了，不慌是不可能的。
- 得知数据库是Oracle，那么还有机会。
- create table bak as select * from of timestamp to_timestamp (‘2015040216’,‘yyyymmddhh24’);（时间结合实际）
- 然后需要技术和业务人员分析具体数据进行关联回写数据，后面的工作不是数据库抢救的范围。只要关注回写的SQL质量就可以。
执行闪回影响到了OGG同步
- 在执行类似create table bak as select * from of timestamp to_timestamp (‘2015040216’,‘yyyymmddhh24’);的命令时候，其实已经考虑过很多因素包括OGG。
- 因为OGG是逻辑复制，那么上游数据库执行CTS命令，那么下游数据库也执行同样的SQL。如果上游成功那么下游数据库也一定成功。
- 在那么短的时间，而且又紧张的环境中，判断到这种程度也不算失误。
OGG出错报警
- 监控显示OGG同步数据状态异常。
- 相关人第一个要问的（不是原因），而是要多久能恢复，以及是否要重建整个同步链路来恢复。
- 查看ogg错误日志
-2025-06-03T14:41:43.207+0800 ERROR OGG-00519 Oracle GoldenGate Delivery for Oracle, refss.prm: Fatal error executing DDL replication: error [Error code [1555], ORA-01555: snapshot too old: rollback segment number 17 with name “_SYSSMU17_4119394354$” too small
], no error handler present. - 出错的原因竟然是ORA-01555: snapshot too old: 快照过旧。这是查询SQL才出现的报错。那么联想到刚才的动作就想通了。
问题分析
- 上游执行CTS的命令，从闪回查询中进行了数据恢复。那么OGG把这个DDL传送到下游同样实现这个功能。但是下游失败因为快照过旧。
- 这样的话就只有一个可能下游undo中设置的闪回查询参数过小。经过对比上游的是43200也就是说可以查询12个小时（如果undo空间够的话），而下游是默认1800，也就是说只能查询到30分钟的数据（如果undo空间够的话）
- 再看了一下执行的时间和数据量。几百万行数据。以及执行时候距离闪回时间戳是40分钟的间隔。
- 这就解释了为什么ORA-01555: snapshot too old: 快照过旧
解决问题
- 等到数据回写完成后可以采用
- 1.上游drop这个BAK表。
- 2.或者OGG同步时候跳过这个表。
- 无需重建整个同步链路
总结
- 如果因为上游数据库都用了很多年了，而下游数据库是后续追加的。下游数据库还承担了多个数据库的数据汇聚，确实后来的没有考虑到各个数据库的闪回要求。这也是很难去事先规划的。
