67.业务反应数据库执行慢

1.业务反应数据库执行慢
(1)收集AWR报告，查看慢SQL 

SQL_ID=bgm0vwvbq0rf0    
SQL_TEXT=MERGE INTO prplrprepare t1 USING...;
该SQL运行好几个小时没有结束。

(2)查询前台正在发出的 sql 语句 

--查询前台发出的 sql 语句 :  
col USER_NAME for a20
col SQL_TEXT for a10000
SELECT SID,USER_NAME,SQL_TEXT FROM V$OPEN_CURSOR 
WHERE SID IN (SELECT SID FROM (SELECT SID,SERIAL# FROM V$SESSION WHERE STATUS= 'ACTIVE' ))
and SQL_TEXT like 'MERGE INTO prplrprepare t1%'; 

       SID USER_NAME SQL_TEXT
---------- --------------------
      7241 ACTUARY MERGE INTO prplrprepare t1		USING		   (
      3792 ACTUARY MERGE INTO prplrprepare t1		USING		   (
     12108 ACTUARY MERGE INTO prplrprepare t1		USING		   (
     14312 ACTUARY MERGE INTO prplrprepare t1		USING		   (
      9910 ACTUARY MERGE INTO prplrprepare t1		USING		   (
      8333 ACTUARY MERGE INTO prplrprepare t1		USING		   (
      1577 ACTUARY MERGE INTO prplrprepare t1		USING		   (
      3471 ACTUARY MERGE INTO prplrprepare t1		USING		   (
       653 ACTUARY MERGE INTO prplrprepare t1		USING		   (

发现有9个会话发起 这个语句。

(3)查看这些SID(会话ID对应的 会话和SQL_ID)

select SID, SERIAL#,USERNAME,SQL_ID from v$session where SID in(7241,3792,12108
,14312,9910,8333,1577,3471,653);

        SID    SERIAL# USERNAME		    SQL_ID
---------- ---------- -------------------------------
       653	56471 ACTUARY			bgm0vwvbq0rf0
      1577	26801 ACTUARY			bgm0vwvbq0rf0
      3471	45308 ACTUARY			bgm0vwvbq0rf0
      3792	47101 ACTUARY			bgm0vwvbq0rf0
      7241	16120 ACTUARY			bgm0vwvbq0rf0
      8333	61306 ACTUARY			bgm0vwvbq0rf0
      9910	33348 ACTUARY			bgm0vwvbq0rf0
     12108	16036 ACTUARY			bgm0vwvbq0rf0
     14312	12481 ACTUARY			bgm0vwvbq0rf0

(4)杀掉会话重新执行。

alter system kill session  '653,56471';
alter system kill session  '1577,26801'; 
alter system kill session  '3471,45308'; 
alter system kill session  '3792,47101'; 
alter system kill session  '7241,16120'; 
alter system kill session  '8333,61306'; 
alter system kill session  '9910,33348'; 
alter system kill session  '12108,16036';
alter system kill session  '14312,12481';

2.总结

当数据库比较慢的时候，有以下几种可能:

(1)SQL语句没有优化。

(2)产生锁，夯住了。

(3)临时表空间不足或表空间不足。

(4)磁盘损坏。

上面的问题是多个会话执行同一个SQL夯死了。同时我们还发现该SQL的逻辑读居然达到32T.

逻辑读达到了31.56T: 4236170089*8K/1024/1024/1024=31.56T,消耗时间:20551/60/60=5.7小时。

和业务人员交流，该SQL实际执行2个小时。但是我们看到的是5.7小时，同时SQL有4个并发，由此我们断定该执行时间是多个CPU并行执行的总时间。平均每个CPU的执行时间大约1.425小时。

因此这里的Elapsed Time(s),并不是SQL在单个CPU里面的执行时间，而是多个CPU执行时间综合。