原文作者：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#;
我们可以看到是不是会话经历栓的冲突，这个冲突是不是经常发生的
使你的用户轻松下来
因此,你现在要可以告诉那些不安的用户他们执行的语句在等待一些其它的资源。我最终的做法是帮助他们优化那些语句，以使语句不至于执行得太慢使用户不安。
(全文完)
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
