今天有一个数据库有点反常，早上的时候报出了CPU使用率的警告。
警告内容如下：
ZABBIX-监控系统:
------------------------------------
报警内容: CPU utilization is too high
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: CPU idle time：44.61 %
------------------------------------
报警时间:2015.10.30-06:51:00
但是问题持续的时间较短，过了会就自动恢复了，早上忙着排查其它的问题，就没有特别注意。结果到了下午的时候，开始频繁报出警告。
首先查看了CPU的使用情况
查看了DB time的情况，发现在早晨和下午的时候都开始有大的波动。
至于初步原因，自己查看分析图发现在这段时间内产生了大量的日志切换。
所以这个问题查看了sar的结果得到了基本的确认。
07:40:01 AM CPU %user %nice %system %iowait %steal %idle
03:40:01 AM all 40.46 0.00 42.52 0.09 0.00 16.92
03:50:01 AM all 42.85 0.00 46.63 0.06 0.00 10.45
04:00:01 AM all 44.83 0.03 50.16 0.05 0.00 4.92
04:10:01 AM all 38.23 0.00 50.79 0.11 0.00 10.87
04:20:02 AM all 45.22 0.00 52.64 0.04 0.00 2.10
04:30:01 AM all 39.96 0.00 51.98 0.21 0.00 7.85
04:40:01 AM all 40.59 0.00 52.29 0.12 0.00 6.99
04:50:01 AM all 36.73 0.00 48.04 0.17 0.00 15.06
查看了awr中的sql占用DB time的情况，发现有一条语句的占用情况实在是太高了。从执行情况来看似乎也不是很慢，但是DB time就是很高。
SNAP_ID SQL_ID EXECUTIONS_DELTA ELAPSED_TI PER_TOTAL
---------- ------------------------------- ---------- ----------
12952 04twf1qr6hbxb 77421 12231s 94%
12952 14qykh7dc3gts 52014 4s 0%
12952 4v43gna7jcpwd 51975 6s 0%
12952 9fz0usaqnsubf 2 0s 0%
12952 c831ks00zc8c2 16676 2s 0%
对于这个问题查看了下执行计划，发现
Execution Plan
--------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------------
| 0 | MERGE STATEMENT | | | | 3 (100)|
| 1 | MERGE | UC_OPENPLATFORM_USER | | | |
| 2 | VIEW | | | | |
| 3 | NESTED LOOPS OUTER | | 6 | 5634 | 3 (0)|
| 4 | VIEW | | 1 | 13 | 0 (0)|
| 5 | SORT AGGREGATE | | 1 | 115 | |
| 6 | INDEX UNIQUE SCAN| OPNE_USER_ID_IDX | 1 | 115 | 0 (0)|
| 7 | VIEW | | 6 | 5556 | 3 (0)|
| 8 | FILTER | | | | |
| 9 | TABLE ACCESS FULL| UC_OPENPLATFORM_USER | 6 | 5556 | 3 (0)|
--------------------------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement (level=2)
发现一个特别之处在于使用了动态采样，意味着相关的表没有收集统计信息。从动态采样的结果来看，资源消耗似乎不高。
我们通过awr sql report来抓取一个执行时的执行计划的报告。
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
---------------------------------------------------------------------------------------
| 0 | MERGE STATEMENT | | 802K| 129M| 1891 (1)|
| 1 | MERGE | UC_OPENPLATFORM_USER | | | |
| 2 | VIEW | | | | |
| 3 | NESTED LOOPS OUTER | | 802K| 718M| 1891 (1)|
| 4 | VIEW | | 1 | 13 | 2 (0)|
| 5 | SORT AGGREGATE | | 1 | 20 | |
|* 6 | INDEX UNIQUE SCAN| OPNE_USER_ID_IDX | 1 | 20 | 2 (0)|
| 7 | VIEW | | 802K| 708M| 1889 (1)|
|* 8 | FILTER | | | | |
| 9 | TABLE ACCESS FULL| UC_OPENPLATFORM_USER | 802K| 41M| 1889 (1)|
---------------------------------------------------------------------------------------
发现差距还是要大的多，而且瓶颈还是在于全表扫描。
这个时候查看等待事件，发现还有buffer busy waits，查看了sga的设置情况，竟然还真是有问题。
SQL> show parameter sga
NAME TYPE VALUE
------------- ------------ --------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 24G
sga_target big integer 12032M
这个sga占用了近24G，但是实际使用了才一半，所以使用不够充分，所以简单评估之后调整到了20G，以备不时之需。
SQL> alter system set sga_target=20G;
System altered.
但是调整之后，除去系统级的影响，发现性能提升并不是很大。那么注意力还是到了这条sql语句上。而且通过addm,sql tuning advisor也给不出建议来，看来还得自己分析分析了。
来仔细回顾一下这条语句，为什么走了全表扫描。结合执行计划，其实谓词信息就很明显了。
6 - access("USER_ID"=:1 AND "PLATFORM"=:2)
8 - filter("TW"."CNT">0)
主要问题就在于filter的部分。
那么来回顾一下这条语句。为什么需要设定CNT>0这么个条件。
MERGE INTO UC_OPENPLATFORM_USER t
USING (SELECT count(*) CNT from UC_OPENPLATFORM_USER where
USER_ID=:1 and PLATFORM=:2) tw
ON (tw.CNT>0)
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)
自己琢磨了下原因，子表tw输出的是表中数据的返回结果，因为user_id是唯一性约束，所以如果匹配则值返回一条结果，如果不匹配则则返回0
根据下面的match条件进行update或者insert操作。整个语句的意思其实就是一句话，根据user_id来匹配，如果找到相关的记录就修改，如果没有就增加一条。
那么为什么需要加CNT呢，我觉得开发同学还是考虑到如果没有匹配的值，那么如果tw根据user_id来和t关联，就没法匹配了。 因为tw就是空值，肯定执行不了insert的部分。
我们来做个简单的例子，可能就会更容易理解。
首先创建一个表test含有id和name字段。插入一条记录id=100
CREATE TABLE TEST(ID NUMBER,NAME VARCHAR(100));
INSERT INTO TEST VALUES(100,'TEST');
如果使用id=100有匹配的数据，那么可能会执行update
MERGE INTO TEST t
USING (SELECT ID from TEST where ID=100 ) tw
ON (tw.ID=T.ID)
WHEN MATCHED THEN UPDATE SET t.NAME='AAA_MATCHED'
where ID= 100
WHEN NOT MATCHED THEN INSERT(ID, NAME) VALUES(100,'BBB_NOT_MATCHED') ;
1 row merged.
SQL> select *from test;
ID NAME
---------- --------------------
100 AAA_MATCHED
那么如果不匹配呢，我们给一个id为1000，肯定匹配不到。
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(100,'BBB_NOT_MATCHED') ;
0 rows merged.
这个时候问题来了，压根不会insert
所以根据这个情况，开发可能会有这种顾虑所以才会考虑通过CNT>0来得到这种匹配，可能他们也觉得没有办法。
其实可以动个小脑筋，我们直接使用一个union all来给出一个dummy的数据，保证是不会匹配的id
比如id根据业务是需要为证书或者字符，那么给一个负数肯定是不糊匹配的。
MERGE INTO TEST t
USING (SELECT ID from TEST where ID=1000 union all 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(100,'BBB_NOT_MATCHED') ;
1 rows merged.
这个时候就达到了预期的结果，而且是按照id来关联的，避免了全表扫描。
那么真实环境中的sql语句级可以简单调整一下
MERGE INTO UC_OPENPLATFORM_USER t
USING (SELECT USER_ID from UC_OPENPLATFORM_USER where
USER_ID=:1 and PLATFORM=:2 union all select '-999' from dual) tw
ON (tw.USER_ID=T.USER_ID)
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)
这样就可以满足需求了，而且全表扫描也没有了。
----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------------------
| 0 | MERGE STATEMENT | | 2 | 338 | 8 (0)|
| 1 | MERGE | UC_OPENPLATFORM_USER | | | |
| 2 | VIEW | | | | |
| 3 | NESTED LOOPS OUTER | | 2 | 312 | 8 (0)|
| 4 | VIEW | | 2 | 204 | 4 (0)|
| 5 | UNION-ALL | | | | |
|* 6 | INDEX UNIQUE SCAN | OPNE_USER_ID_IDX | 1 | 20 | 2 (0)|
| 7 | FAST DUAL | | 1 | | 2 (0)|
| 8 | TABLE ACCESS BY INDEX ROWID| UC_OPENPLATFORM_USER | 1 | 54 | 2 (0)|
|* 9 | INDEX UNIQUE SCAN | OPENPLATFORM_USER | 1 | | 1 (0)|
----------------------------------------------------------------------------------------------
这样就达到了初步效果，所以下一步就是建议开发同学来这么修改了。因为还不能动态修改，所以这个问题就是万事俱备只欠东风了。
通过这个案例可以发现，其实很多问题还是需要去分析原因，为什么要写成那样，是出于什么样的考虑，可能出发点是好的，但是结果把问题从一个极端逮到了另外一个极端。