ITPub博客

首页 > Linux操作系统 > Linux操作系统 > logical standby apply sql with full scan

logical standby apply sql with full scan

原创 Linux操作系统 作者:g644516804 时间:2012-05-17 15:30:58 0 删除 编辑
最近logical standby 总是出问题
在update wip_runcard_backup时出现full scan
但是该操作在主库上肯定不可能出现full scan,到底是哪出问题了
猜想是sql从主库同步到备库时sql发生了转变,这可能是logical standby内部转换出现了问题
在standby上执行的sql十分 复杂 截取一部分看看:
update /*+ streams or_expand(p "PRODUCT_SN"
)restrict_all_ref_cons */ "SMP"."WIP_RUNCARD_BACKUP" p set
"AK_CHECK"=decode(:1,'N',"AK_CHECK",:2),
"ATTRIBUTE01"=decode(:3,'N',"ATTRIBUTE01",:4),
"ATTRIBUTE02"=decode(:5,'N',"ATTRIBUTE02",:6),
"ATTRIBUTE03"=decode(:7,'N',"ATTRIBUTE03",:8),
"ATTRIBUTE04"=decode(:9,'N',"ATTRIBUTE04",:10)where (:247="AK_CHECK"
or(:247 is null and "AK_CHECK" is null)) and(:248="ATTRIBUTE01"
or(:248 is null and "ATTRIBUTE01" is null))
and(:249="ATTRIBUTE02" or(:249 is null and "ATTRIBUTE02" is
null)) and(:250="ATTRIBUTE03" or(:250 is null and "ATTRIBUTE03"
is null)) and(:251="ATTRIBUTE04" or(:251 is null and
"ATTRIBUTE04" is null)) and(:252="ATTRIBUTE05" or(:252 is null
and "ATTRIBUTE05" is null)) and(:253="ATTRIBUTE06" or(:253 is
null and "ATTRIBUTE06" is null)) and(:254="ATTRIBUTE07" or(:254
is null and "ATTRIBUTE07" is null)) and(:255="ATTRIBUTE08"
or(:255 is null and "ATTRIBUTE08" is null))
and(:256="ATTRIBUTE09" or(:256 is null and "ATTRIBUTE09" is
null)) and(:257="ATTRIBUTE10" or(:257 is null and "ATTRIBUTE10"
is null)) and(:258="BATCH_KEY" or(:258 is null and "BATCH_KEY"
is null)) and(:259="BIOS" or(:259 is null and "BIOS" is null))
and(:260="BOARD_NAME" or(:260 is null and "BOARD_NAME" is null))
and(:261="BOX_NO" or(:261 is null and "BOX_NO" is null))
and(:262="BOX_TYPE" or(:262 is null and "BOX_TYPE" is null))
and(:263="COA" or(:263 is null and "COA" is null))
很多null的操作,而其他update的操作很多都是
decode(:482,'N','Y',decode(:483,"TLEVEL",'Y'))='Y' and
         decode(:484,'N','Y',decode(:485,"TRACKING_NO",'Y'))='Y' and
         decode(:486,'N','Y',decode(:487,"TURNIN_PRINT_TIME",'Y'))='Y' and
         decode(:488,'N','Y',decode(:489,"TURNIN_TIME",'Y'))='Y' and
         decode(:490,'N','Y',decode(:491,"TURN_IN_ORD_NO",'Y'))='Y' and
         decode(:492,'N','Y',decode(:493,"UPDATE_BY",'Y'))='Y' and
 
并无null的
查看表的结构
发现wip_runcard_backup中列都允许为null,可该表有primary key啊?
查找原因 是因为之前improt时遇到bug,在create index的时候终止了,之后我们手动create index,但是相关的 constraint并没有建立,所以导致了很多constrain丢失
,而这可能就是使sql 转变的时候出问题了
将standby中wip_runcard_backup中增加了相关了constraint之后,继续apply
sql发现改变了不再有null
而且执行也利用了index
至于栏位为null or not null对logical standby sql apply为何会有这个影响还是不得而知了。。。
 
后续:
之后在主库上重新加了丢失的constrains,问题又出现了,logical standby 出现ora-1403 no data find
 通过数据查找,需要update的数据不存在,于是想利用insert 方式先插入,可是insert 的时候出现
SQL> insert into smp.wip_runcard  select * from wip_runcard@temp where "SN_KEY" = 185019265 and "WO_KEY" = 116679884;                  insert into smp.wip_runcard  select * from wip_runcard@temp where "SN_KEY" = 185019265 and "WO_KEY" = 116679884
*
ERROR at line 1:
ORA-00001: unique constraint (SMP.WIP_RUNCARD_UN1) violated
 
原来wip_runcard.sn_unique 已经在备库中使用,但其他栏位的信息不对,而sn_unique是unique key,所以也不能insert 了
数据已经完全错乱了。。
 
猜想:
之后加入的constrain 包括加入了
ALTER TABLE SMP.WIP_RUNCARD ADD  CONSTRAINT WIP_RUNCARD_UN1
 UNIQUE (SN_UNIQUE)
    USING INDEX ;
会不会是因为增加了constrain 原因造成的???
 
至于原因也不再追究了,重建是最快的方法了。。。

 

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24849178/viewspace-730033/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-03-04

  • 博文量
    104
  • 访问量
    237102