原文作者：John Weeg

當一個使用者坐在的終端前的提交了一個查詢卻等不出結果,這很是讓人恢心的。他們很希望語句執行正常,但他們卻不知道實際上是怎麼樣的。因些讓我們找出一個辦法來消除他們的擔心。

你是誰？

第一個問題當然指的是我們正在提及的是哪個會話？使用者可以在做其它事情前用如下的語句得它：

Select sid from v$mystat where rownum=1;

實際上，直到你提交的語句執行很正常時這個問題才不會被提出，如果使用者有一個唯一的使用者名稱,那麼你可以用如下語句得到那個SID,比如查使用者JOHN的SID.

select sid,machine,osuser,module from v$session where username='JOHN';

   SID MACHINE              OSUSER                         MODULE
----- -------------------- ------------------------------ ----------
150 MSHOME\JOHN-LAPTOP   John?Weeg                      SQL*Plus

我用其它的一些資訊校驗這恰恰是我的會話

糟糕一點的是共享使用者名稱被使用的狀況，因些我們將需要看一下哪些會話正在執行：

break on sid skip 1
column sid format 99999
column sql_text form a64

select a.sid, a.last_call_et ,b.sql_text
from v$session a
    ,v$sqltext b
where a.username is not null
and   a.status = 'ACTIVE'
and   a.sql_address = b.address
order by a.last_call_et,a.sid,b.piece;

這給出了我們正在目前正在執行的語句和多長時間，你應該就能能夠看出哪一個會話你需要檢查一下。

因些，接著應做什麼？

我們知道通常在語句執行這段時間伴隨著等待,正在執行CPU操作，或正在執行IO操作。透過v$sessstat,v$sessio,v$session_wait這三張表我們可以得到我們想知道的一些資訊，可以透過SID去單查我們觀注的一個表，但我發現很被容易把這些資訊結合在一起。

Column event format a30
Column sid format 9999
Column session_cpu heading "CPU|used"
Column physical_reads heading "physical|reads"
Column consistent_gets heading "logical|reads"
Column seconds_in_wait heading "seconds|waiting"

select a.sid, a.value session_cpu, c.physical_reads,
c.consistent_gets,d.event,d.seconds_in_wait
from v$sesstat a,v$statname b, v$sess_io c, v$session_wait d
where a.sid=150
and b.name = 'CPU used by this session'
and a.statistic# = b.statistic#
and a.sid=c.sid
and a.sid=d.sid;

我執行這個語句幾次，因為我們需要找出哪些項在變化。

      CPU physical logical                                   seconds
SID used     reads    reads EVENT                             waiting
--- ----- --------- -------- ------------------------------ ----------
150 1159         0   117476 SQL*Net message from client             5

/

      CPU physical logical                                   seconds
SID used     reads    reads EVENT                             waiting
--- ----- --------- -------- ------------------------------ ----------
150 1970         0   204484 SQL*Net message from client             4

因些我們可以看到這個會話在我們檢查時正在等待客戶端的資訊。在我們兩次檢查的期間它執行了邏輯讀的操作並消耗了CPU資源，這說明會話執行是正常的。

什麼情況下我們需要進一步檢查?

通常有這麼幾個事件(event)標識潛在存在問題:'buffer busy waits','db file sequential read','db file scattered read','free buffer waits','latch free',對於前4上事件，我們可以找出相關的是哪個物件，如下語句：

select owner,segment_name,segment_type
from (select p1 file#, p2 block# from v$session_wait
      where sid = 150
      and event in ('buffer busy waits'
                   ,'db file sequential read'
                   ,'db file scattered read'
                   ,'free buffer waits')) b
,dba_extents a
where a.file_id = b.file#
and   b.block# between a.block_id and (a.block_id+blocks-1);

這裡我們能夠發現IO等待是由於大量的資料訪問引起的，還是由有些東西不對比如索引丟失引起的，我們也可以去掉SID子句那行找出那些正在經歷等待的物件。

對於最後一個潛在的問題我們可以查正在等待什麼栓(latch):

select name
from (select p2 latch# from v$session_wait
      where sid = 150
      and event in ('latch free')) b
,v$latchname a
where a.latch# = b.latch#;

我們可以看到是不是會話經歷栓的衝突，這個衝突是不是經常發生的

使你的使用者輕鬆下來

因此,你現在要可以告訴那些不安的使用者他們執行的語句在等待一些其它的資源。我最終的做法是幫助他們最佳化那些語句，以使語句不至於執行得太慢使使用者不安。

我的會話(session)在做什麼？

相關文章