ITPub博客

首页 > 数据库 > Oracle > merge语句导致的CPU使用率过高的优化(二)

merge语句导致的CPU使用率过高的优化(二)

原创 Oracle 作者:jeanron100 时间:2015-11-04 23:06:26 0 删除 编辑
之前分享过一篇关于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上线也要评估,进行验收测试。尽可能把问题都解决在沟通层面,不用那么多的邮件来标注,说明。

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

下一篇: Oracle 12c PDB浅析
请登录后发表评论 登录
全部评论
技术文章每天更新,阵地已转移到微信公众号端。 公众号:jianrong-notes

注册时间:2012-05-14

  • 博文量
    1498
  • 访问量
    14396777