今天在更新一个参数表 执行update之后发现少更新了一个字段 在修改了条件之后接着又执行了一次
结果在检查的时候发现 出现了问题
name字段下出现了类似"摊分发生费发生费"这样的名称
这是由于执行了两次以下update语句造成的
update p_acct_call_type_ms set name=name||'发生费',
operation_type=2,type_name='实际消费',data_source='MONTH_AGGR',operation_type1=21
where substr(acct_type_id,-1)=1 and operation_type=2 ;
commit;
由于没有备份,加上事务已经commit,因此无法rollback,
当时第一时间想到的是for update 但是like '%发生费发生费%'之后发现有400多条
一条一条的修改将非常的耗费时间
select distinct LENGTH(name)
from p_acct_call_type_ms where name like '%发生费发生费%'
检查发现name字段的不同长度有50多条,写update语句更新显然相比for update
手工修改效率会快很多.因此补救语句如下
update p_acct_call_type_ms set name=substr(name,1,5) where LENGTH(name)=8 and name like '%发生费发生费%';
update p_acct_call_type_ms set name=substr(name,1,6) where LENGTH(name)=9 and name like '%发生费发生费%';
......
update p_acct_call_type_ms set name=substr(name,1,55) where LENGTH(name)=58 and name like '%发生费发生费%';
执行只用了几秒钟时间便完成了.这里主要用到了substr函数,根据返回字符串的长度来判断截取的长度来达到补救的目的.
记录下来,作为经验教训.
结果在检查的时候发现 出现了问题
name字段下出现了类似"摊分发生费发生费"这样的名称
这是由于执行了两次以下update语句造成的
update p_acct_call_type_ms set name=name||'发生费',
operation_type=2,type_name='实际消费',data_source='MONTH_AGGR',operation_type1=21
where substr(acct_type_id,-1)=1 and operation_type=2 ;
commit;
由于没有备份,加上事务已经commit,因此无法rollback,
当时第一时间想到的是for update 但是like '%发生费发生费%'之后发现有400多条
一条一条的修改将非常的耗费时间
select distinct LENGTH(name)
from p_acct_call_type_ms where name like '%发生费发生费%'
检查发现name字段的不同长度有50多条,写update语句更新显然相比for update
手工修改效率会快很多.因此补救语句如下
update p_acct_call_type_ms set name=substr(name,1,5) where LENGTH(name)=8 and name like '%发生费发生费%';
update p_acct_call_type_ms set name=substr(name,1,6) where LENGTH(name)=9 and name like '%发生费发生费%';
......
update p_acct_call_type_ms set name=substr(name,1,55) where LENGTH(name)=58 and name like '%发生费发生费%';
执行只用了几秒钟时间便完成了.这里主要用到了substr函数,根据返回字符串的长度来判断截取的长度来达到补救的目的.
记录下来,作为经验教训.
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/12216142/viewspace-498108/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
