之前分享过一篇关于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上线也要评估，进行验收测试。尽可能把问题都解决在沟通层面，不用那么多的邮件来标注，说明。