DBA_Oracle Event等待事件分析(概念)

2014-12-18 Created By
BaoXinjian

图片 1一、摘要


Oracle的等候事件是衡量Oracle运行状况的重要依据及指标。

等候事件的定义是以Oracle7.0.1.2中引入的,大致有100单待事件。

在Oracle
8.0中是数量增加到了约150个,在Oracle8i中约产生200只事件,在Oracle9i中盖发生360独待事件。

 

图片 2次、等待事件分类


重在出三三两两种植档次的等事件,即空闲(idle)等待事件及非空闲(non-idle)等待事件。

1.
悠闲事件指Oracle正等待某种工作,在诊断及优化数据库的时刻,我们无用了多小心及时片轩然大波。

  •  dispatcher timer
  •  lock element cleanup
  •  Null event
  •  parallel query dequeue wait
  •  parallel query idle wait –
    Slaves
  •  pipe get
  •  PL/SQL lock timer
  •  pmon timer- pmon
  •  rdbms ipc message
  •  slave wait
  •  smon timer
  •  SQL*Net break/reset to
    client
  •  SQL*Net message from client
  •  SQL*Net message to client
  •  SQL*Net more data to client
  •  virtual circuit status
  •  client message

2.
非空闲等待事件特别针对Oracle的移位,指数据库任务还是以运行过程遭到发出的等,这些等待事件是咱当调数据库的时候理应关爱同研究之。

  •  db file scattered read
  •  db file sequential read
  •  buffer busy waits
  •  free buffer waits
  •  enqueue
  •  latch free
  •  log file parallel write
  •  log file sync

 

图片 3老三、查询视图


1.
查看v$event_name视图的字段结构:

SQL> desc v$event_name;

名称                   是否为空? 类型
 ----------------------------------------- -----------------------
 EVENT#                NUMBER
 EVENT_ID              NUMBER
 NAME                 VARCHAR2(64)
 PARAMETER1          VARCHAR2(64)
 PARAMETER2          VARCHAR2(64)
 PARAMETER3          VARCHAR2(64)
 WAIT_CLASS_ID        NUMBER
 WAIT_CLASS#          NUMBER
 WAIT_CLASS           VARCHAR2(64)

 

2.  查等待事件总数:

SQL> select count(*) from v$event_name;
  COUNT(*)
----------
      1116

3.  翻等待事件分类情况

SELECT   wait_class#,
           wait_class_id,
           wait_class,
           COUNT ( * ) AS "count"
    FROM   v$event_name
GROUP BY   wait_class#, wait_class_id, wait_class
ORDER BY   wait_class#;

WAIT_CLASS# WAIT_CLASS_IDWAIT_CLASS                count
----------- ------------- -------------------- ----------
          0    1893977003 Other                       717
          1    4217450380 Application                  17
          2    3290255840 Configuration                24
          3    4166625743 Administrative               54
          4    3875070507 Concurrency                  32
          5    3386400367 Commit                        2
          6    2723168908 Idle                         94
          7    2000153315 Network                      35
          8    1740759767 UserI/O                      45
          9    4108307767 SystemI/O                    30
         10    2396326234 Scheduler                     7
         11    3871361733 Cluster                      50
         12     644977587 Queueing                      9

 

4.  有关的几乎单视图:

V$SESSION:
代表数据库活动的起来,视为源起。

V$SESSION_WAIT:
视图用以实时记录活动SESSION的等候情况,是时下信息。

V$SESSION_WAIT_HISTORY:
是对V$SESSION_WAIT的简增强,记录活动SESSION的近期10糟等待。

V$SQLTEXT: 
当数据库出现瓶颈时,通常可以自V$SESSION_WAIT找到那些在候资源的SESSION,通过SESSION的SID,联合V$SESSION和V$SQLTEXT视图就可捕获这些SESSION正在实践的SQL语句。

V$ACTIVE_SESSION_HISTORY:
是ASH的为主,用以记录活动SESSION的史等消息,每秒采样一不成,这一部分情记录在内存中,期望值是记录一个小时之情节。

WRH#_ACTIVE_SESSION_HISTORY:
是V$ACTIVE_SESSION_HISTORY于AWR的存储地。

V$ACTIVE_SESSION_HISTORY:
中的信会被限期(每时一破)的刷新到负载库中,并缺省保留一个星期用于分析。

DBA_HIST_ACTIVE_SESS_HISTORY:
视图是WRH#_ACTIVE_SESSION_HISTORY视图和其余几单视图的合展现,通常经过之视图进行历史数据的顾。

V$SYSTEM_EVENT:
由于V$SESSION记录之是动态信息,和SESSION的生命周期相关,而连无记录历史信息,所以ORACLE提供视图V$SYSTEM_EVENT来记录数据库从启动以来有等待事件的集中信息。通过这视图,用户可快得到数据库运行的圆概况。

 

图片 4季、等待事件


  1. db file scattered read-DB
    文件分散读取

这种场面一般显示和全表扫描相关的等候。当数据库进行全表扫时,基于性的设想,数据会分散(scattered)读入Buffer
Cache。如果这等待事件比较显著,可能说明对于一些全表扫描的说明,没有创造索引或者尚未创造合适的目录,我们或需要检讨这些数据表已规定是否进行了对的安装。

然这等待事件非肯定代表性能低下,在好几原则下Oracle
会主动采取全表扫描来给换索引围观以加强性,这同走访的数据量有关,在CBO
下Oracle 会进行更进一步智能的精选,在RBO 下Oracle 更赞成被采用索引。

盖全表扫描给安放LRU(Least Recently
Used,最近至少适用)列表的冷端(cold
end),对于频繁造访的比较小的数据表,可以选择将她们Cache
到外存中,以避免频繁读取。

当以此等待事件比较显著时,可以结合v$session_longops
动态性视图来展开确诊,该视图中记录了丰富日子(运行时刻过6
秒底)运行的东西,可能多凡是全表扫描操作(不管怎样,这有些信息都是值得我们注意的)。

 

  1. db file sequential read-DB
    文件相继读取。

及时同波屡见不鲜显示与单个数据块相关的读取操作(如索引读取)。如果这等待事件比较显著,可能代表于多表连接着,表底连各个是问题,可能无正确的使让表;或者可能说明非加选择地展开索引。

每当大多数状态下我们说,通过索引可以更加迅猛的抱记录,所以对于一个编码规范、调整好的数据库,这个等待很酷是甚正规的。但是在重重情况下,使用索引并无是极品的挑选,比如读取较充分申中大量的数码,全表扫描或会见肯定快给找引围观,所以在付出被我们便应有小心,对于这么的询问相应进行避免用索引围观。

 

  1. Free Buffer-释放缓冲区

这个等待事件表明系统正守候内存中的可用空间,这证明当前Buffer
中早已远非Free 的内存空间。如果采用设计漂亮,SQL
书写规范,充分绑定变量,那这种等待或说明Buffer Cache
设置的偏小,你可能用增大DB_BUFFER_CACHE。

Free Buffer 等待或说明DBWR
的勾起速度不够,或者磁盘存在严重的竞争,可以得考虑增加检查点、使用更多之DBWR
进程,或者多物理磁盘的数目,分散负载,平衡IO。

 

  1. Buffer Busy-缓冲区忙

拖欠等事件表示正在等候一个盖unshareable方式采取的缓冲区,或者表示即着给读入buffer
cache。一般的话Buffer Busy
Wait不承诺超出1%。检查缓冲等待统计有(或V$WAITSTAT),看一下候是否在段头(Segment
Header)。如果是,可以设想多自由列表(freelist,对于Oracle8i
DMT)或者增加freelist
groups(在群时光这调整是立竿见影的,在8.1.6前,这个freelists参数不能够动态修改;在8.1.6与随后版本,动态修改feelists需要装COMPATIBLE至少为8.1.6).

假定这同等候在undo
header,可以由此长回滚段(rollback
segment)来缓解缓冲区底题材。如果等待在undo
block上,我们恐怕需要检讨有关应用,适当压缩大规模的一致性读取,或者下降一致性读取(consistent
read)的表中的数据密度要增大DB_CACHE_SIZE。

而等待处于data
block,可以考虑将反复并作访问的申或数易到其它一样数据块或者进行再次老范围之分布(可以加pctfree值
,扩大数据分布,减少竞争),以逃避这”热点”数据块,或者好设想增加表中的妄动列表或采取本地化管理之表空间(Locally
Managed Tablespaces)。

假如等待处于寻找引块,应该考虑重建索引、分割索引或用反往键索引。为了以防和数据块相关的休养冲忙等待,也得采用比较小的片:在这种场面下,单个块被之记录就是较少,所以这片就未是那”繁忙”;或者可以装更充分之pctfree,使数据扩大物理分布,减少记录里的看好竞争。

于履DML (insert/update/
delete)时,Oracle向数块被形容副信息,对于多工作并发访问的数据表,关于ITL的竞争及等或出现,为了削减是等待,可以长initrans,使用多单ITL槽。在Oracle9i
中,引入了一个初定义:ASSM(Segment Space Management
Auto)。通过之新特性Oracle 使用各图来治本空间利用。

ASSM 结合LMT 彻底改变了Oracle
的积存机制,位图freelist 能够减轻缓冲区忙等待(buffer busy
wait),这个题材在Oracle9i 以前的版本里既是一个重的问题。

Oracle 宣称ASSM 显著地增强了DML
并发操作的性能,因为(同一个)位图的不等部分足吃同时以,这样尽管排了查找剩余空间的差行化。根据Oracle
的测试结果,使用各类图freelist
会消除所有支行头部(对资源)的斗争,还会得到超快的起插入操作。在Oracle9i
之中,Buffer Busy wait 不再常见!

 

  1. latch free-latch 释放

latch是均等种低级排队机制,用于保障SGA中共享内存结构。latch就像是同样种植高效地被获取与假释的外存锁。用于防止共享内存结构于多独用户以做客。如果latch不可用,就见面记录latch释放失败(latch
free miss )。有少数种与闩有关的花色:

  • 立刻
  • 得等

若是一个过程试图以当时模式下取闩,而该闩已经给另外一个经过所所有,如果该闩不可知即刻可用的话,那么该过程就非会见呢得到该闩而待。它将继续执行另一个操作。

大多数latch问题还跟以下操作相关:

无很好的是为此绑定变量(library cache
latch)、重作生成问题(redo allocation latch)、缓冲存储竞争问题(cache
buffers LRU chain),以及buffer cache中之是”热点”块(cache buffers
chain)。

平凡我们说,如果想设计一个未果的体系,不考虑绑定变量,这一个尺码就是足足了,对于异构性强的系统,不采取绑定变量的名堂是最严重的。

除此以外也来局部latch等待与bug有关,应当关注Metalink相关bug的揭示与补丁的披露。当latch
miss ratios大于0.5%时时,就当研究就同题材。

Oracle的latch机制是竞争,其拍卖接近于网络里之CSMA/CD,所有用户进程争夺latch,
对于甘愿等类型(willing-to-wait)的latch,如果一个历程在率先差尝试被从不到手latch,那么她会等以又品尝同软,如果经过_spin_count次战斗不克博得latch,
然后该过程转入睡眠状态,持续一截指定长度的流年,然后再醒来,按梯次重复以前的步骤.在8i/9i中默认值是_spin_count=2000。

假定SQL语句不克调,在8.1.6版以上,Oracle提供了一个新的初始化参数:
CURSOR_SHARING可以经过设置CURSOR_SHARING = force
在劳动器端强制绑定变量。设置该参数可能会见带来一定之副作用,对于Java的先后,有连带的bug,具体以该关爱Metalink的bug公告。

 

  1. Log Buffer Space-日志缓冲空间

当你以日志缓冲(log
buffer)产生重复做日志的进度较LGWR 的刻画来速度快,或者是当日志切换(log
switch)太慢时,就会见来这种等待。这个等待出现不时,通常表明redo log buffer
过些微,为缓解这题目,可以考虑外加日志文件的分寸,或者多日志缓冲器的尺寸。

另外一个或的缘故是磁盘I/O
存在瓶颈,可以设想下写副速度还快之磁盘。在允许的规格下设置好考虑使用裸设备来存放日志文件,提高写副效率。在形似的系统被,最低的正经是,不要将日记文件及数据文件存放于一齐,因为一般而言日志文件才写不读,分离存放可以取得属性提升。

 

  1. Log File Switch-日志文件切换

当以此等待出现经常,表示拥有的付(commit)的求都用等”日志文件切换”的得

Log file Switch
主要含有两单子事件:

log file switch (archiving needed)

log file switch (checkpoint
incomplete)

log file switch (archiving
needed)

以此等待事件出现不时通常是以日志组循环写满后,第一单日志归档尚未到位,出现该待。出现该等,可能代表io
存在问题。解决办法:

得考虑外加日志文件和增日志组

挪动归档文件到便捷磁盘

调整log_archive_max_processes .

log file switch (checkpoint
incomplete)-日志切换(检查点未成功)

当您的日志组都写了后,LGWR
试图写第一个log file,如果此刻数据库没有水到渠成写起记录在率先只log file
中的dirty 块时(例如第一个检查点未到位),该待事件出现。

拖欠待事件便表示你的DBWR
写有速度太慢或者IO 存在问题。

呢化解该问题,你或许得考虑增加额外的DBWR
或者增加而的日志组或日志文件大小。

 

  1. log file sync-日志文件并

当一个用户提交或回滚数据常常,LGWR
将会晤话期的重做由日志缓冲器写副到还做日志中。日志文件并过程要待这无异历程成功做到。为了减小这种等待事件,可以品尝同糟提交更多之笔录(频繁之提交会带来双重多的体系出)。将还做日志置于较快的磁盘上,或者轮岗使用不同物理磁盘上的重做日志,以降低归档对LGWR的熏陶。

对软RAID,一般的话不要用RAID 5,RAID5
于频繁写副得系统会带动比较充分的性质损失,可以考虑下文件系统直接输入/输出,或者使用裸设备(raw
device),这样可收获写入的属性提高。

 

  1. log file single
    write该事件只是及写日记文件头块相关,通常发生在加码新的组成员和增进序列号时。

头块写单个进行,因为头块的一些信息是文件号,每个文件不同。更新日志文件头是操作以后台就,一般生少出现等待,无需太多关心。

 

  1. log file parallel write

自log buffer 写redo 记录及redo log
文件,主要指常规写操作(相对于log file sync)。如果你的Log group
存在多个组成员,当flush log buffer
时,写操作是互的,这时候此等待事件或者出现。

尽管这个写操作并行处理,直到所有I/O
操作就该写操作才见面形成(如果你的磁盘支持异步IO或者采用IO
SLAVE,那么就是单纯发一个redo log file member,也闹或出现是等候)。

其一参数与log file sync
时间相较可用来衡量log file 的写照副基金。通常号称同步成本率。

 

  1. control file parallel
    write-控制文件并行写

当server
进程更新具有控制文件时,这个事件可能出现。如果等待很短缺,可以不用考虑。如果等待时比较丰富,检查存放控制文件之大体磁盘I/O
是否是瓶颈。

大抵独控制文件是完全相同的正片,用于镜像以增进安全性。对于工作系统,多单操文件应当存放于不同的磁盘上,一般的话三个是够的,如果就出三三两两单大体硬盘,那么零星只操文件也是可以接受的。在与一个磁盘上保留多单控制文件是勿备实际意义的。减少是等待,可以设想如下方法:

调减控制文件的个数(在保管安全之前提下)

倘系统支持,使用异步IO

易控制文件及IO 负担轻的物理磁盘

 

  1. control file sequential read/ control
    file single write

控制文件连续读/控制文件单个写对单个控制文件I/O
存在问题时常,这半只事件会冒出。如果等待于强烈,检查单个控制文件,看存放位置是不是是I/O
瓶颈。

 

  1. direct path
    write-直接途径写该待发生在,系统等确认有非得的异步I/O
    都曾写副磁盘。

对此这同一写副等,我们当找到I/O
操作最为频繁之数据文件(如果出过多的排序操作,很有或就是临时文件),分散负载,加快其描绘副操作。

倘系统是了多的磁盘排序,会造成临时表空间操作频繁,对于这种场面,可以设想用Local管理表空间,分成多独小文件,写副不同磁盘或者裸设备。

 

  1. Idle Event-空闲事件

末我们来拘禁几个空等待事件。一般的话,空闲等待是因系为任从业可做的等候,或者等待用户之请或响应等,通常我们得以忽略这些等待事件。空闲事件可以经stats$idle_event
表查询得到。

我们看一下系的重点空闲等待事件,对这些事件大家应发个盖的记忆,如果你的Top
5
等候事件受到,主要都是这些事件,那么一般的话你的网是比价清闲的。

 

Thanks and Regards

参考:RuleV5 –
http://blog.csdn.net/rulev5/article/details/7075401

图片 5

相关文章