merge语句导致的CPU使用率过高的优化(二) (r7笔记第9天)

之前分享过一篇关于merge语句导致的CPU使用率过高优化的案例。http://blog.itpub.net/23718752/viewspace-1819471/ 后续的跟进没有补充，也“秀”一张图，红色的火焰是原来的系统负载，右边的部分是最近的逻辑读情况，不过惭愧的是，这个不是优化的效果，因为应用的高峰期 已经处理完了，后面的sql调用频率极低，所以感觉不到任何的压力。所以通过这个图也可以看出，给一张差别巨大的图也不一定是系统优化的效果，也可能是其 它外在因素。

那么既然要说跟进，后面的情节才够真实和现实，开发同学找到语句，修改花了些时间，今天突然联系到我，说已经修改完成了。我也从v$sql中抓取了几条语句，发现执行计划已经改变。 感觉这件事情就要告一段落，但是开发的同事过了一会找到我说，他们在应用端发现日志中出现了ORA-00001的错误。 ### Cause: java.sql.SQLException: ORA-00001: unique constraint (AXXXX.OPENPLATFORM_USER) violated 这个问题着实在意料之外，他们反馈出现问题后，立即回退了代码，但是日志保留了下来，让我看看是什么问题。找开发要绑定变量的值，貌似还比较困难，那就算了，自己分析吧。 比如还是简单模拟这个错误。 CREATE TABLE TEST(ID NUMBER,NAME VARCHAR(100)); ALTER TABLE TEST MODIFY(ID UNIQUE); INSERT INTO TEST VALUES(100,'BB_NOT_MATCHED'); INSERT INTO TEST VALUES(1000,'BBB_NOT_MATCHED'); SQL> select*from test; ID NAME ---------- -------------------- 1000 BB_NOT_MATCHED 100 BBB_NOT_MATCHED 我们已经插入了两条值，这个时候来尝试一下，update是否生效 SQL> MERGE INTO TEST t USING (SELECT ID from TEST where ID=1000 union select -1 id from dual ) tw ON (tw.ID=T.ID) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 1000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(1000,'BBB_NOT_MATCHED') ; MERGE INTO TEST t * ERROR at line 1: ORA-00001: unique constraint (TEST.SYS_C0011234) violated 这个错误还是有些奇怪，本来预计的update变成了insert,结果还违反了唯一性约束。 来看看最初始版本的执行情况。 SQL> MERGE INTO TEST t USING (SELECT count(*) CNT from TEST where ID=1000 ) tw ON (tw.CNT>0) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID=1000 WHEN NOT MATCHED THEN INSERT(ID,NAME) VALUES(1000,'BBB_NOT_MATCHED')； 1 row merged. 发现确实是做了update,把id=1000的行，name列修改成了AAA_MATCHED SQL> select *from test; ID NAME ---------- -------------------- 1000 AAA_MATCHED 100 BBB_NOT_MATCHED 手工把数据改回来，继续测试。 SQL> update test set name='BBB_NOT_MATCHED' where id=1000; 1 row updated. SQL> select *from test; ID NAME ---------- -------------------- 1000 BBB_NOT_MATCHED 100 BBB_NOT_MATCHED 这个时候开发的同学突然给我反馈说，他们看如果把union all的字句取消就不报错了。原来他们也在debug,我告诉他们，不报错不代表没错，还是需要搞明白最根本的原因。 MERGE INTO TEST t USING (SELECT ID from TEST where ID=1000 ) tw ON (tw.ID=T.ID) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 1000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(1000,'BBB_NOT_MATCHED') ; SQL> select *from test; ID NAME ---------- -------------------- 1000 AAA_MATCHED 100 BBB_NOT_MATCHED 这个时候update确实能够正常执行，似乎也是预期的结果，那么做一条insert，看看效果。 MERGE INTO TEST t USING (SELECT ID from TEST where ID=2000 ) tw ON (tw.ID=T.ID) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 2000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(2000,'BBB_NOT_MATCHED') ; 0 rows merged. 可以看到，id=2000的行没有插入数据。这个我觉得也就是为什么开发的同学没有选用这个方法的根本原因。但是似乎他们没有找到更好的方法， 那么继续改进，就是我上次分享的，加入union all的部分。 MERGE INTO TEST t USING (SELECT ID from TEST where ID=2000 union all select -999 from dual ) tw ON (tw.ID=T.ID) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 2000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(2000,'BBB_NOT_MATCHED') ; 1 row merged. SQL> select *from test; ID NAME ---------- -------------------- 1000 AAA_MATCHED 100 BBB_NOT_MATCHED 2000 BBB_NOT_MATCHED 这个时候问题来了，insert可以了，但是update有问题了。 SQL> MERGE INTO TEST t 2 USING (SELECT ID from TEST where ID=2000 union all select -999 from dual ) tw 3 ON (tw.ID=T.ID ) 4 WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' 5 where ID= 2000 6 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(2000,'BBB_NOT_MATCHED') ; MERGE INTO TEST t * ERROR at line 1: ORA-00001: unique constraint (TEST.SYS_C0011234) violated 如果你看晕了，我来整理一下思路。 ###加入union all的方案 不存在id=2000 可以insert 已存在id=2000 update 报ora-00001 ### 去掉union all子句 不存在id=2000 可以插入 已存在id=2000 update无法执行 那么来一个动态的条件，可以不？ SQL> MERGE INTO TEST t USING (SELECT ID from TEST where ID=2000 union all select -999 from dual) tw ON (tw.ID=T.ID or tw.id=-999) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 2000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(2000,'BBB_NOT_MATCHED') ; MERGE INTO TEST t * ERROR at line 1: ORA-30926: unable to get a stable set of rows in the source tables 所以这些思路都不同，但是根据id来决定Inert,update也算一个常规问题，吃完晚饭继续琢磨，总算找到了一个合适的方法。 SQL> MERGE INTO TEST t USING (SELECT 2000 id FROM dual ) tw ON (tw.ID=T.ID ) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 2000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(2000,'BBB_NOT_MATCHED') ; 1 row merged. 这种情况下条件是唯一性匹配的，匹配与否就很清晰了。 当前数据情况如下： SQL> select *from test; ID NAME ---------- -------------------- 1000 AAA_MATCHED 100 BBB_NOT_MATCHED 2000 AAA_MATCHED 插入一条新数据 SQL> MERGE INTO TEST t USING (SELECT 3000 id FROM dual ) tw ON (tw.ID=T.ID ) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 3000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(3000,'BBB_NOT_MATCHED') ; 1 row merged. SQL> select *from test where id=3000; ID NAME ---------- -------------------- 3000 BBB_NOT_MATCHED 更新一条记录 SQL> MERGE INTO TEST t USING (SELECT 3000 id FROM dual ) tw ON (tw.ID=T.ID ) WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED' where ID= 3000 WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(3000,'BBB_NOT_MATCHED') ; SQL> select *from test where id=3000; ID NAME ---------- -------------------- 3000 AAA_MATCHED 改进后的执行计划如下： Execution Plan ---------------------------------------------------------- Plan hash value: 3869333021 ----------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------- | 0 | MERGE STATEMENT | | 1 | 78 | 3 (0)| 00:00:01 | | 1 | MERGE | TEST | | | | | | 2 | VIEW | | | | | | | 3 | NESTED LOOPS OUTER | | 1 | 79 | 3 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL | DUAL | 1 | 2 | 2 (0)| 00:00:01 | | 5 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 77 | 1 (0)| 00:00:01 | |* 6 | INDEX UNIQUE SCAN | SYS_C0011234 | 1 | | 0 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 6 - access("T"."ID"(+)=CASE WHEN (ROWID IS NOT NULL) THEN 3000 ELSE 3000 END ) 1 row merged. 所以正式环境的语句也是类似的思路。 MERGE INTO UC_OPENPLATFORM_USER t USING (SELECT :1 USER_ID,:2 PLATFORM from DUAL ) tw ON (tw.USER_ID=T.USER_ID and tw.PLATFORM=t.PLATFORM) WHEN MATCHED THEN UPDATE SET t.NAME=:3, t.UPDATE_DATE=SYSDATE where USER_ID=:4 and PLATFORM=:5 WHEN NOT MATCHED THEN INSERT(USER_ID, PLATFORM, NAME, CREATE_DATE, UPDATE_DATE) VALUES(:6, :7, :8, SYSDATE, SYSDATE) 改动之后还是需要再部署测试，相信大体就没有问题了。 通过这个案例可以发现，很多优化的时候从执行计划等情况确实有了很大的提升，一些瓶颈也得到了解决，但是还是要更周密的测试，别修复了一个错，引来更多的问题。而且sql上线也要评估，进行验收测试。尽可能把问题都解决在沟通层面，不用那么多的邮件来标注，说明。