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

2014-12-18 Created By
BaoXinjian

Oracle 1一、摘要


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

等候事件的概念是当Oracle7.0.1.2中引入的,大致有100只待事件。

当Oracle
8.0面临之数额增加至了大约150单,在Oracle8i中大约发生200只事件,在Oracle9i中约产生360个待事件。

 

Oracle 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

 

Oracle 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来记录数据库从启动以来所有等待事件之集中信息。通过之视图,用户可以快捷获得数据库运行的总体概况。

 

Oracle 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 的写照来速度快,或者是当日志Oracle切换(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

Oracle 5

相关文章