v$session_wait 知多少 Part 1

我们都知道v$session_wait 是用来判断等待事件的 ，那么好 ，现在给你来个好玩的

.    SID STATE   EVENT                                          SEQ# SECONS_IN_WAIT P1                 P2                 P3                 P1TRANSL

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

     14 WORKING On CPU / runqueue                              3486         130

 

好啦，大家来告诉我 这个session 到底干啥呢？

好吧 你知道他在执行什么SQL：

给你它的execution plan  ：

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

| Id  | Operation                       | Name | Rows  | Bytes | Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT                |      |       |       |     4 (100)|          |

|   1 |  SORT AGGREGATE                 |      |     1 |    66 |            |          |

|*  2 |   HASH JOIN                     |      |     7 |   462 |     4  (25)| 00:00:01 |

|   3 |    NESTED LOOPS                 |      |       |       |            |          |

|   4 |     NESTED LOOPS                |      |     7 |   329 |     2   (0)| 00:00:01 |

|   5 |      TABLE ACCESS BY INDEX ROWID| T1   |     7 |   196 |     1   (0)| 00:00:01 |

|*  6 |       INDEX RANGE SCAN          | I1   |     7 |       |     1   (0)| 00:00:01 |

|*  7 |      INDEX RANGE SCAN           | I2   |    27 |       |     1   (0)| 00:00:01 |

|*  8 |     TABLE ACCESS BY INDEX ROWID | T2   |     1 |    19 |     1   (0)| 00:00:01 |

|   9 |    TABLE ACCESS BY INDEX ROWID  | T3   |    40 |   760 |     1   (0)| 00:00:01 |

|* 10 |     INDEX RANGE SCAN            | I3   |    40 |       |     1   (0)| 00:00:01 |

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

Predicate Information (identified by operation id):

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

 

2 - access("T2"."OBJECT_ID"="T3"."OBJECT_ID")

6 - access("T1"."OWNER"=:V)

7 - access("T2"."OWNER"=:V)

8 - filter("T1"."OBJECT_ID"="T2"."OBJECT_ID")

10 - access("T3"."OWNER"=:V)

 

好了~~ 告诉我他到底哪错了？

 

You got no idea ,right?

 

I’ll tell you what.

 

其实v$sysstat 是一个很有效的视图，如果你通过监视他 你会发现：

  SID, USERNAME  , TYPE, STATISTIC                               ,         DELTA, HDELTA/SEC,    %TIME, GRAPH

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

   14, SYS       , STAT, session logical reads                   ,         81351,     16.27k,

   14, SYS       , STAT, consistent gets                         ,         81351,     16.27k,

   14, SYS       , STAT, consistent gets from cache              ,         81351,     16.27k,

   14, SYS       , STAT, consistent gets from cache (fastpath)   ,         81352,     16.27k,

   14, SYS       , STAT, no work - consistent read gets          ,         81381,     16.28k,

   14, SYS       , STAT, table fetch by rowid                    ,       2904784,    580.96k,

   14, SYS       , STAT, index scans kdiixs1                     ,            93,       18.6,

   14, SYS       , STAT, buffer is pinned count                  ,       5736560,      1.15M,

   14, SYS       , STAT, buffer is not pinned count              ,         75248,     15.05k,

   14, SYS       , STAT, no buffer to keep pinned count          ,             1,         .2,

   14, SYS       , TIME, DB CPU                                  ,       6050000,      1.21s,   121.0%, |@@@@@@@@@@|

   14, SYS       , TIME, sql execute elapsed time                ,       6059922,      1.21s,   121.2%, |@@@@@@@@@@|

   14, SYS       , TIME, DB time                                 ,       6059922,      1.21s,   121.2%, |@@@@@@@@@@|

You got it?

 

Ok  check it out:

         index scans 并不是很高 甚至说够少的了

    好高的session logical reads ，buffer is pinned count。

Which means you are trying to get some buffer again and again.

 

知道问题在哪里了吗？检查你的nest loop吧  是不是你可爱的绑定变量写的有问题了 否则怎么会循环这么多次拿重复的数据？

 

这个案例我想大家都会经常遇到 无比正常的执行计划，简单的SQL语句 but 却跑不出来结果 或者return的时间不是你想要的。其实你可以考虑一下 在这个简单的等待事件的背后隐藏着多少东西 you haven’t seen.

 

下面是点关于 V$SESSION_WAIT 的简单小测试

.    SID STATE   EVENT                                          SEQ#  SECONS_IN_WAIT P1                 P2                 P3                 P1TRANSL

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

     14 WORKING On CPU / runqueue                              3486         130

SEQ 是什么？SEQ是指你等待的次数  SECONS_IN_WAIT是什么？直译就可以了

 

BEGIN

      FOR c IN 1..100

      LOOP

        Dbms_lock.sleep(5);

      END LOOP;

   

END;

 

如果是这样的话SECONS_IN_WAIT 会从0加到5  然后SEQ +1 代表你等待过一次。一共SEQ会等待101次~~

因为最后一次是你开始等待SQL*Net message from client ^ ^~~

 

时间有限 只发part 1.

 

(Gdb dtrace)

REHL 5.4 Systemtap

AIX Probevue

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

转载于:http://blog.itpub.net/21818314/viewspace-693207/