CPU使用率高报警分析

今天凌晨某服务器发来nmon的报警，由于设定的阈值是50%，这次达到了51%，以下是nmon中截取的图：

可以看到，在03:47分的时候，CPU确实非常高，伴随的是IO也非常高

通过AWR分析发现，出现的TOP 10等待事件为“direct path write temp”和“direct path read temp”

这2个等待事件占用了大部分的DB time，出现这2个等待事件的原因通常有以下几种情况：

1. 大量的磁盘排序操作如：order by, group by, union, distinct等无法在PGA中完成排序，就需要利用temp表空间进行排序，当从临时表空间中读写排序结果时就会产生

2. 大量的Hash Join操作，利用temp表空间保存hash区

3. SQL语句的并行处理

4. 大表的全表扫描，从Oracle11g开始，全表扫描的算法有新的变化，根据表的大小、高速缓存的大小等信息，决定是否绕过SGA直接从磁盘读取数据。而10g则是全部通过高速缓存读取数据，称为table scan(large)。11g认为大表全表时使用直接路径读，可能比10g中的数据文件散列读(db file scattered reads)速度更快，使用的latch也更少

在通多对对应时段的ASH分析，发现排在最首的是某个SQL语句，其中就有hash join操作

由于是在3:47分时出现了CPU使用率超过50%达到51%，通过ASH分析得知，可能是由于SQL_ID为"8czhtz9qzh26q"的语句不够优化所致，由于采用了hash join，当PGA内存不够用的情况下，就会放到TEMP表空间去做排序操作，因此会出现以上的2种等待事件

通过查询dba_hist_active_sess_history试图也可以发现，SQL_ID为"8czhtz9qzh26q"的这个语句引起的'direct path read temp'和'direct path write temp'等待事件是最多的，达到2000多次

SQL> select sql_id,count(*) from dba_hist_active_sess_history where event='direct path read temp' group by sql_id order by 2 desc;

SQL_ID          COUNT(*)

------------- ----------

byw58yzu9r2dd       2451

8czhtz9qzh26q       2394

cpyy02b6kx0ku       1398

8afvg51qfcyw2       1133

8wz064sfqmvf2        890

d9kg104nzn2wr        881

f71s48a8q7p25        681

89ppsupjzngfn        477

0pq0u5wuqvd15        386

6hcqqsgn7dc85         73

athtrxf4src9b         69

553uvczus2nwx         59

f70j74a0unxk2         47

5wbywfrv398aw         33

6j27q2vkrnrx4          8

8pnau57dxjqbf          6

0w6b8tpz9kwkg          6

4yzt2j9ukwn64          3

6kuua0mrzd235          3

f8j9cqv0h3ts6          2

4b9vf1vavfcy5          2

3ag9mnj5djzdc          1

22 rows selected.

SQL> select sql_id,count(*) from dba_hist_active_sess_history where event='direct path write temp' group by sql_id order by 2 desc;

SQL_ID          COUNT(*)

------------- ----------

byw58yzu9r2dd       2586

8czhtz9qzh26q       2357

8wz064sfqmvf2        898

cpyy02b6kx0ku        885

d9kg104nzn2wr        767

8afvg51qfcyw2        470

f71s48a8q7p25        295

89ppsupjzngfn        228

0pq0u5wuqvd15        157

6hcqqsgn7dc85        101

athtrxf4src9b         96

5wbywfrv398aw         36

0w6b8tpz9kwkg         11

gqn0ddb70rsu3         11

4yzt2j9ukwn64          8

6j27q2vkrnrx4          7

f70j74a0unxk2          6

f8j9cqv0h3ts6          5

8pnau57dxjqbf          5

6kuua0mrzd235          5

0fhwh07ap0h4j          5

553uvczus2nwx          4

4b9vf1vavfcy5          3

3ag9mnj5djzdc          3

c101zwsz5dbqg          1

25 rows selected.

通过AWR可以直接找出出现以上2种等待时间最多的SQL语句，也可以通过V$SQL_TEXT视图进行查看，找出相关的语句，对SQL进行优化即可

另外，服务器物理内存为16G，SGA仅分配了6G，PGA为1G，没有开启AMM，可以考虑开启AMM并分配给数据库更多一些的内存，增加PGA，以减少'direct path read temp'和'direct path write temp'等待事件的出现，提高数据库的性能。当然，还应以优化相关SQL为主要调优手段。