ITPub博客

首页 > Linux操作系统 > Linux操作系统 > Oracle Wait Interface解释

Oracle Wait Interface解释

Linux操作系统 作者:531968912 时间:2016-02-26 10:16:48 0 删除 编辑

Oracle Wait Interface

       Oracle等待事件的种类包括:I/O, locks, latches, enqueues, background process activities, network latencies, memory,等。可以通过V$SYSTEM_WAIT_CLASS查询到。

       使用之前必须设置TIMED_STATISTICS=TRUE。

 

OWI的关键组件

视图

·V$EVENT_NAME:包含定义的所有等待事件;

·V$SESSION_WAIT:显示每个会话当前正在等待的时间和资源的详细信息,这是一个实时视图;

在10G中,v$session_wait已经合并到了v$session 视图中,虽然仍包含v$session_wait。

·V$SESSION_EVENT:显示当前连接的会话的等待事件的聚集;

·V$SYSTEM_EVENT:显示所有会话遇到的所有等待事件的聚集;

       Oracle 10G新增的关键组件包括:

•          V$SESTEM_WAIT_CLASS

•          V$SESSION_WAIT_CLASS

•          V$SESSION_WAIT_HISTORY

•          V$EVENT_HISTOGRAM

•          V$ACTIVE_SESSION_HISTORY

跟踪

       ·Trace event 10046—扩充的SQL跟踪;

       ·如果无法交互性的监控事件,可以通过纪录等待事件到跟踪文件进行诊断性能问题;

       ·可以在实例(Event=“10046 tace name contex forever, level 8”, 永远不要这么做)/会话级别(Alter session set events ‘10046 trace name context forever, level 8’)启用。

       ·运行要跟踪的SQL;

       ·Alter session set events ‘10046 trace name context off’;

 

       ???以下过程在可能没有。

       ·也可以使用dbms_support.start_trace进行跟踪;

       ·跟踪其他会话:Exec dbms_support.start_trace_in_session(sid=>xxx, serial#=>xxx, waits=>true, binds=>true);

       ·结束跟踪:stop_trace_in_session;

 

       ·跟踪文件的位置在user_dump_dest 目录下;

·可以使用tracefile_identifer命名跟踪文件名,Alter session set tracefile_identifier= ‘Tracefilesql1’;

·然后使用tkprof工具进行格式化输出,最近Metalink上有一个新的工具TRCA,更加适合分析跟踪文件。

     

OWI的限制

       ·没有CPU 统计;

       ·非端到端的可见性;

       ·没有历史数据;

       ·由于当前计算机速度的飞增,一些计算可能不精确;

 

常见的等待事件

       ·Buffer busy waits:10g中更改为read by other session;参数中P1代表块所在的文件号,P2代表实际的块号,P3在9i中代表reason for the wait,10g中代表v$waitstat中的CLASS列;等待时间为1s或100cs。

       ·Control file parallel write:参数中P1代表块驻留的绝对文件号,P2代表总块数,P3代表I/O请求数量;等待时间为完成所有I/O请求的实际延迟。

       ·Db file parallel read:当一个进程从一个/多个数据文件读取多个不连续的块,或数据库恢复时有些数据库块需要恢复时会发生这种事件;参数P1代表需要读取的文件数,P2读取的总块数,P3代表I/O请求的总数量;等待时间为完成所有I/O请求的实际延迟。

       ·Db file parallel write:当DBWR以批模式些藏块到数据文件时会发生;参数中P1代表需要写入的文件数,P2代表要写的总块数,P3(9.2+)以百分之一秒为单位代表超时的值;等待时间:无超时。

       ·Db file scattered read:通常在全表扫描时发生;参数P1代表开始读取的块的文件号,P2代表开始读取的块号,P3代表读取的块数;等待时间:无超时。

       ·Db file sequential read:当从索引,回滚段,表(ROWID),数据文件头,一些临时段读取时会发生该事件;参数P1代表开始读取的块的文件号,P2代表开始读取的块号,P3通常为1,但是临时段则大于1;等待时间:无超时。

       ·Db file single write:当Oracle更新数据文件头时发生该事件,通常在检查点期间。如果数据库有大量数据文件可能会注意到这种情况;参数P1代表写入的文件号,P2代表开始写入的块,P3通常为1;等待时间:无超时。

       ·Direct path read:当oracle直接读取数据库块到会话PGA而不是SGA的缓冲缓存时时发生,直接路径读取通常在访问临时段时使用;参数P1读取的所在的绝对文件号,P2代表开始读取的块号,P3则为读取的块数;等待时间:无超时。

       ·Direct path write:与Direct path read相反,Oracle从PGA写缓冲到数据文件,通常用来写到临时段,直接数据加载或并行DML操作。

       ·Enqueue:是一种Oracle用来串行化访问数据库资源的共享内存结构,进程为了得到该enqueue锁必须等待在队列中。用来串行访问资源的各种enqueue包括:ST,空间管理;SQ,序列号;TX,事务;参数P1代表正在等待的进程请求的enqueue名和模式,P2代表请求的锁的资源标识符ID1,P3代表请求的锁的资源标识符ID2;等待时间:依赖于enqueue名,Oracle最多可以等待三秒,或直到enqueue资源可用。

       ·Free buffer waits:当会话无法在数据库缓冲缓存中找到空闲缓冲读入块或者建立一致性读时将发生该事件。这会唤醒DBWR释放脏缓冲;参数中P1代表文件号,P2代表需要读入到缓存中的块号,P3(9i未使用),10G显示缓冲缓存中LRU列表的id;等待时间:Oracle最多等待1s,然后重试。

       ·Latch free:当进程等待一个当前被其他进程占用的latch时会发生这种事件。进程要得到latch不必等待在队列中。最常见的latch包括:cache buffer chains, library cache和shared pool;参数P1代表latch的地址,P2代表latch号(v$latchname.latch#),P3代表尝试的次数;等待时间:指数增长,10G中latch由其自身的等待事件。

       ·Library cache pin / library cache lock:当会话试图将一个对象“钉“在库缓存中以更改或测试它时会发生该事件,必须得到一个钉确保对象不会被改变;P1代表库对象地址,P2代表加载锁的地址,P3为模式+名字空间(来自v$db_object_cache);等待时间:PMON为1S,其他进程为3S。

       ·Log buffer space:当进程必须等待日志缓冲中的空间可用时发生;未使用参数;等待时间:1S,如果必须等待日志切换则为5S。

       ·Log file parallel write:会话等待LGWR写日志缓冲块到重做组成员时发生;参数P1代表要写入的日志文件数,P2代表要写入的OS块数,P3代表I/O请求数量;等待时间:实际的延迟。

       ·Log file sequential read:当进程等待块从在线重做日志文件读取时会发生该事件;参数P1代表重做日志文件的相对序列号,P2代表开始读取的块号,P3代表读取的OS块数;等待时间:实际的延迟。

       ·Log file switch (archiving needed):指示ARCH 跟不上LGWR。

       ·Log file switch (checkpoint incomplete):文件归档前检查点必须完成,指示重做日志文件可能太小。

       ·Log file sync:参数P1代表需要同步的日志缓冲中的缓冲的数量;等待时间:1S。

       ·SQL*Net message from/to client:如果很大,可能指示网络有问题;P1:显示网络驱动器的类型,P2代表字节数,P3未使用。等待时间:实际的延迟。

       ·跟踪CPU和其他统计:V$SESSTAT / V$SYSSTAT,其中包含了

–         CPU used by this session

–         CPU used when call started

–         Recursive CPU usage

–         Parse time CPU

–         Session logical reads

–         Physical reads

–         Physical writes

 

等待事件:根本原因分析

       ·需要收集等待事件统计历史;

       ·Trace 10046,会有很大的负载但是可以得到最小粒度的性能数据;

       ·Statspack,不能得到会话级别的数据;

       ·使用BEFORE LOGOFF TRIGGER收集历史数据—低负载(如果会话被KILL或挂起则没有任何数据)。建立表并保持大约7天的数据,可以归档这些数据进行长期比较。将等待事件和产生该事件的SQL语句(V$SQLTEXT)保存起来。

文章出处:DIY部落(http://www.diybl.com/course/7_databases/oracle/oraclexl/20090304/158003.html)

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

请登录后发表评论 登录
全部评论

注册时间:2014-09-24

  • 博文量
    574
  • 访问量
    835702