sql批量update多条_逻辑复制中的UPDATE语句

面对逻辑复制延时问题,文章探讨了如何处理UPDATE语句,以减少数据库复制的延迟。通过实例展示了原UPDATE语句与经过LOGMINER处理后的区别,如将简单的更新条件扩展为包含ROWID的复杂条件,以确保数据一致性。
摘要由CSDN通过智能技术生成

逻辑复制延时是让数据库复制运维中十分头痛的问题。有个朋友问老白,他发现LOGMINER出来的UPDATE语句与生产端的原语句差别比较大,比如下面的语句,原语句是:

UPDATE F_XXX_BACKUP SET TALLY_REMARK = 'WIAO' 

WHERE ACCT_ID = :B1

而目标端从从归档日志中解析出来sql_redo的语句变成了,源语句中的ACCT_ID条件没有了,反而多了BACKUP_ID等条件:
 update "XXPAY"."F_XXX_BACKUP" set"TALLY_REMARK" = 'WIAO' where "BACKUP_ID" = '000000154720'and "TALLY_REMARK" = 'WIAO' and ROWID = 'AAAL8YAAKAAA9y2AAe';
为什么会出现这样的情况呢?要理解逻辑复制在源端与目标端的SQL语句的不同,需要首先理解逻辑复制是如何实现的。在源端,一条UPDATE语句可能是通过某个过滤条件进行的,修改数据的过程被以重做记录的方式写入重做日志或者其他复制日志中,对于Oracle来说,这种日志就是REDO LOG(对于MYSQL的BINLOG我们在本文的后面分析)。Oracle的重做日志记录记录的是记录数据块的物理变化,为了还原成逻辑复制的
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值