ITPUB论坛－专业的IT技术社区

标题: 【有奖讨论】谈一谈你认为的数据库最重要的TOP 10等待事件 [打印本页]
作者: wei-xh    时间: 2013-9-10 09:59
标题: 【有奖讨论】谈一谈你认为的数据库最重要的TOP 10等待事件
讨论话题：
谈一谈你对OWI等待事件的理解，等待事件诊断方法是非常重要的性能诊断方法，大家讨论讨论在你运维过程中，觉得哪些等待事件最常见，最应该掌握，并且发表一下你对等待事件的一些自己的看法和理解。

讨论时间：
2013年9月10日-2013年10月1日

讨论奖品：活动结束后将会抽取5名会员赠送ITPUB12周年精美礼物一份。


8楼vage的回复：还有Mutex类等待。
Latch相关的还有Cache buffers chain latch、Shared Pool Latch也很重要，一个对应逻辑读，一个对应共享池内存的分配、释放。


15楼cyxtemp的回复
library cache lock
buffer busy waits
row cache lock
log file sync
log file switch completion
db file scattered read
enq:TX-row lock contention
db file sequential read
cachee buffer LRU chain latch

23楼www_xylove的回复
我平时在运维中出现的等待事件主要有
1.log file sync
2.global cache cr request
3.buffer busy waits
4.enqueue
5.latch free(主要是cache buffer chains latch)
6.library cache lock
7.library cache pin
8.log file switch (archiving needed)
9.log file switch (checkpoint incomplete)
10.db file scattered read
11.db file sequential read

上面的11种等待事件是我平时运维工作中碰到的比较多的影响数据库性能的等待事件，数据库版本有9.2.0.5、10.2.0.5

第一个等待事件 log file sync，
魏哥的《漫谈log file sync》已经说够详细的了，见链接：
http://www.itpub.net/thread-1807437-1-1.html

出现这个问题，必须引起重视，这个等待事件严重的话会造成数据库hang住的，我自己的解决方法是：
1.数据库层面进行调优
  如果出现log file sync平均时间很高，我见到过平均时间98ms，而log file parallel write平均等待事件很低的话，
  就要从数据库层面进行调优，不要找人家存储工程师的麻烦了。
  在数据库层面可以从以下几个方面进行调优：
   1.1 在log file sync发生时间段，生成一个statspack或awr报告，找出相应sql，需要开发配合，是否应用程序
       在做一些频繁提交的动作，如果有，则减少提交次数。
   1.2 如果你的logfile容量过小，比方说300M，是否可用加大logfile容量到1G（加大logfile容量调优log file sync有待商榷）
   1.3 减少log buffer的容量 比方说你的log buffer 200M,是否减少到30M，比较好，这个可以现场进行调优的时候，尝试修改一下。
   1.4 开启异步提交，参数是commit_write(10g以后才有)，几种组合都可以尝试一下。
2.存储层面进行调优
   2.1 如果你确定是存储上面有问题，这个就交给存储工程师吧。

第二个等待事件global cache cr request

  出现这个等待事件，造成的原因是应用没有进行分割，在多个节点穿插业务数据，节点间来回进行数据块的交互。
  从根本上解决这个问题的话，就是一个应用系统就连接到一个节点上。但是如果一个节点无法承担一个应用的时候，
  怎么办？
  我看过老白的一篇文档，链接不记得了，就是不需要进行应用分割，也能解决global cache cr request，就是在发生
  该等待事件的时候，抓取SQL,需要开发配合，是哪一张或多张表需要在节点间来回数据块的传递，找出来之后，修改
  这个几个表的结构，增加一个inst_id字段（插入数据之前，连接到的实例），再给这个字段赋予一个常量.这样的话，
  如果我在节点1操作，数据只会插入节点1，如果我在节点2操作的话，数据只能插入到节点2.

第三个等待时间buffer busy waits
  这个等待事件没什么好说的了，一般是SQL引起的。
  如果严重影响的数据库的性能，先kill掉这些个进程，
  然后交由开发部门处理。

第四个等待事件enqueue
  这个也是常见的等待事件，这个对业务影响很大，如果DBA不立刻处理，将会使业务模块进行不下去。
  处理办法也是kill持有的进程。
  SQL然后交由开发部门处理

第五个等待事件5.latch free(主要是cache buffer chains latch)
  这个等待事件没什么好说的了，一般是SQL引起的。
  如果严重影响的数据库的性能，先kill掉这些个进程，
  然后交由开发部门处理。

第六个等待事件和第七个等待事件基本上是一起出现的
  解决方法我最后会附上我前几次处理的一次这样的等待事件。

第八个等待事件log file switch (archiving needed)-日志切换(检查点未完成)
和第九个等待事件log file switch (checkpoint incomplete)

解决这两个问题，可能需要增加你的日志组或日志文件大小。
当然，也可以从存储上找原因。

第十个等待事件db file scattered read
这个还需要说吗？呵呵

第十个等待事件db file sequential read

这个也可以说说：索引创建不恰当，检查一下索引的情况或检查聚簇因子。

下面是我前几天处理的一个library cache lock/pin等待事件的案例，
分享如下：
数据库版本:9.2.0.5

也可链接到http://space.itpub.net/21266384/viewspace-772409
生产环境library cache lock/pin解决方案

   前几天巡检数据库的时候发现数据库出现近55个session在library cache lock、library cache bin上等待。经过分析，发现有8个

session在对数据库对象进行编译或重编译，从9月7日(从周末开始)就开始对数据库对象进行编译或重编译，导致相关的依赖对象的数据库操

作被阻塞，相关依赖对象的数据库操作具体有select ,dml等操作，均被阻塞进程，以至于出现上述等待事件，被阻塞的session为47个。

下面的这个过程是解决的具体操作：

首先看到55个session在等待library cache lock、library cache bin


上面的sql就在shared pool共享池检索出哪些session占用了被依赖资源的句柄，需要做的就是kill掉这些持有对象句柄的进程。

  下面这个sql就至找出持有锁的进程：


就是上面的8个进程占用了句柄，103856、170336、257234、83658、203856、155564、192620、83046

kill 掉这些进程：

oracle@DBHIS02>kill -9 103856




kill掉之后，阻塞的8个session释放了锁资源，被阻塞的47个session获得了资源，进行正常的资源请求。
至此，问题解决。



29楼diashad的回复
1.      Buffer busy waits
从本质上讲，这个等待事件的产生仅说明了一个会话在等待一个Buffer（数据块），但是导致这个现象的原因却有很多种。常见的两种是：
当一个会话视图修改一个数据块，但这个数据块正在被另一个会话修改时。
当一个会话需要读取一个数据块，但这个数据块正在被另一个会话读取到内存中时。

Oracle 操作的最小单位是块（Block），即使你要修改一条记录，也需要对这条记录所在的这个数据块做操作。 当你对这个数据块做修改时，其他的会话将被阻止对这个数据块上的数据做修改（即使其他用户修改的不是当前用户修改的数据），但是可以以一致性的方式读取这个数据块（from undo）。当前的用户修改完这个数据块后，将会立即释放掉加在这个数据块上的排他锁，这样另一个会话就可以继续修改它。 修改操作是一个非常短暂的时间，这种加锁的机制我们叫Latch。

当一个会话修改一个数据块时，是按照以下步骤来完成的：
以排他的方式获得这个数据块（Latch）
修改这个数据块。
释放Latch。

Buffer busy waits等待事件常见于数据库中存在的热快的时候，当多个用户频繁地读取或者修改同样的数据块时，这个等待事件就会产生。 如果等待的时间很长，我们在AWR或者statspack 报告中就可以看到。


36楼guoyJoe的回复
监听连接时间过长如何解决
http://www.itpub.net/thread-1784287-1-1.html

被误读的buffer busy waits系列问题讨论
http://www.itpub.net/thread-1779349-1-1.html

完全揭秘log file sync等待事件
http://www.itpub.net/thread-1777234-1-1.html


逻辑读产生Cache Buffer Chain(简称CBC) Latch的解析
http://www.itpub.net/thread-1764511-1-1.html
作者: wei-xh    时间: 2013-9-10 10:00
本帖最后由 wei-xh 于 2013-9-10 10:40 编辑

我个人认为比较重要的等待事件有：

IO相关：
db file scattered read
db file sequential read
direct path read
direct path writeread by other session

redo相关：
log file sync
log buffer space
log file switch completion

buffer busy waits

latch相关：
cachee buffer LRU chain latch
redo allocation latch
redo copy latch
redo writing latch

锁相关：
enq:TX-row lock contention
enq:TX-allocate ITL entry
enq:TX-index contention



我自己对于等待事件的一些看法：
buffer busy waits：
http://www.itpub.net/thread-1801066-1-1.html

redo allocation latch:
http://www.itpub.net/thread-1803010-1-1.html

log file sync:
http://www.itpub.net/thread-1807437-1-1.html

direct path read:
http://www.itpub.net/thread-1815281-1-1.html


作者: 贪婪的猪    时间: 2013-9-10 10:32
db file scattered read
db file sequential read
direct path read
read by other session
log file sync
log file switch completion
buffer busy waits
redo allocation latch
enq:TX-row lock contention
enq:TX-index contention
作者: wei-xh    时间: 2013-9-10 10:34
贪婪的猪 发表于 2013-9-10 10:32
db file scattered read
db file sequential read
direct path read

不错，可以说的更细点，方便大家学习。
作者: arron刘    时间: 2013-9-10 10:38
不错不错，支持一下楼主。大家多多关注哦
作者: XKGLOB刀    时间: 2013-9-10 13:48
library cache lock
row cache lock
作者: wei-xh    时间: 2013-9-10 13:53
XKGLOB刀 发表于 2013-9-10 13:48
library cache lock
row cache lock

可以简单介绍下这些等待事件发生的原因，解决办法。
作者: vage    时间: 2013-9-10 15:10
还有Mutex类等待。
Latch相关的还有Cache buffers chain latch、Shared Pool Latch也很重要，一个对应逻辑读，一个对应共享池内存的分配、释放。
作者: wei-xh    时间: 2013-9-10 15:15
vage 发表于 2013-9-10 15:10
还有Mutex类等待。
Latch相关的还有Cache buffers chain latch、Shared Pool Latch也很重要，一个对应逻辑 ...

多谢波波给力支持
作者: 2009532140    时间: 2013-9-10 15:17
good~
作者: jie_321    时间: 2013-9-10 15:18
top1 等待楼主寄奖品
作者: wei-xh    时间: 2013-9-10 15:18
jie_321 发表于 2013-9-10 15:18
top1 等待楼主寄奖品

也不说几个等待事件，太不给面子了
作者: wailon    时间: 2013-9-10 15:30
楼主把大部分常见的都说了，log file switch(checkpoint incomplete),可能的原因，频繁提交，REDO日志过小，或日志组不够，日志写IO过慢等
作者: wei-xh    时间: 2013-9-10 15:36
wailon 发表于 2013-9-10 15:30
楼主把大部分常见的都说了，log file switch(checkpoint incomplete),可能的原因，频繁提交，REDO日志过小， ...

可以说说你对哪个等待事件理解的比较深入。奖品丰厚哦。
作者: cyxtemp    时间: 2013-9-10 16:56
library cache lock
buffer busy waits
row cache lock
log file sync
log file switch completion
db file scattered read
enq:TX-row lock contention
db file sequential read
cachee buffer LRU chain latch

作者: wei-xh    时间: 2013-9-10 17:05
cyxtemp 发表于 2013-9-10 16:56
library cache lock
buffer busy waits
row cache lock

如果能说出他们的特性来就好了
作者: oralin_deng    时间: 2013-9-10 17:14
wei-xh 发表于 2013-9-10 10:00
我个人认为比较重要的等待事件有：

IO相关：

比较全面。
作者: wei-xh    时间: 2013-9-10 17:28
oralin_deng 发表于 2013-9-10 17:14
比较全面。

你可以从你的角度发表发表看法嘛
作者: hellodatabase    时间: 2013-9-10 17:41
row cache lock
作者: 4224657    时间: 2013-9-11 09:43
顶下，学习了
作者: wei-xh    时间: 2013-9-11 10:04
hellodatabase 发表于 2013-9-10 17:41
row cache lock

什么场景下会遇到row cache lock？
作者: wei-xh    时间: 2013-9-11 10:04
4224657 发表于 2013-9-11 09:43
顶下，学习了

可以发表下你自己的一些看法嘛
作者: www_xylove    时间: 2013-9-11 11:57
魏哥的帖子，一定要顶啊。
我平时在运维中出现的等待事件主要有
1.log file sync
2.global cache cr request
3.buffer busy waits
4.enqueue
5.latch free(主要是cache buffer chains latch)
6.library cache lock
7.library cache pin
8.log file switch (archiving needed)
9.log file switch (checkpoint incomplete)
10.db file scattered read
11.db file sequential read

上面的11种等待事件是我平时运维工作中碰到的比较多的影响数据库性能的等待事件，数据库版本有9.2.0.5、10.2.0.5

第一个等待事件 log file sync，
魏哥的《漫谈log file sync》已经说够详细的了，见链接：
http://www.itpub.net/thread-1807437-1-1.html

出现这个问题，必须引起重视，这个等待事件严重的话会造成数据库hang住的，我自己的解决方法是：
1.数据库层面进行调优
  如果出现log file sync平均时间很高，我见到过平均时间98ms，而log file parallel write平均等待事件很低的话，
  就要从数据库层面进行调优，不要找人家存储工程师的麻烦了。
  在数据库层面可以从以下几个方面进行调优：
   1.1 在log file sync发生时间段，生成一个statspack或awr报告，找出相应sql，需要开发配合，是否应用程序
       在做一些频繁提交的动作，如果有，则减少提交次数。
   1.2 如果你的logfile容量过小，比方说300M，是否可用加大logfile容量到1G（加大logfile容量调优log file sync有待商榷）
   1.3 减少log buffer的容量 比方说你的log buffer 200M,是否减少到30M，比较好，这个可以现场进行调优的时候，尝试修改一下。
   1.4 开启异步提交，参数是commit_write(10g以后才有)，几种组合都可以尝试一下。
2.存储层面进行调优
   2.1 如果你确定是存储上面有问题，这个就交给存储工程师吧。

第二个等待事件global cache cr request

  出现这个等待事件，造成的原因是应用没有进行分割，在多个节点穿插业务数据，节点间来回进行数据块的交互。
  从根本上解决这个问题的话，就是一个应用系统就连接到一个节点上。但是如果一个节点无法承担一个应用的时候，
  怎么办？
  我看过老白的一篇文档，链接不记得了，就是不需要进行应用分割，也能解决global cache cr request，就是在发生
  该等待事件的时候，抓取SQL,需要开发配合，是哪一张或多张表需要在节点间来回数据块的传递，找出来之后，修改
  这个几个表的结构，增加一个inst_id字段（插入数据之前，连接到的实例），再给这个字段赋予一个常量.这样的话，
  如果我在节点1操作，数据只会插入节点1，如果我在节点2操作的话，数据只能插入到节点2.

第三个等待时间buffer busy waits
  这个等待事件没什么好说的了，一般是SQL引起的。
  如果严重影响的数据库的性能，先kill掉这些个进程，
  然后交由开发部门处理。

第四个等待事件enqueue
  这个也是常见的等待事件，这个对业务影响很大，如果DBA不立刻处理，将会使业务模块进行不下去。
  处理办法也是kill持有的进程。
  SQL然后交由开发部门处理

第五个等待事件5.latch free(主要是cache buffer chains latch)
  这个等待事件没什么好说的了，一般是SQL引起的。
  如果严重影响的数据库的性能，先kill掉这些个进程，
  然后交由开发部门处理。

第六个等待事件和第七个等待事件基本上是一起出现的
  解决方法我最后会附上我前几次处理的一次这样的等待事件。

第八个等待事件log file switch (archiving needed)-日志切换(检查点未完成)
和第九个等待事件log file switch (checkpoint incomplete)

解决这两个问题，可能需要增加你的日志组或日志文件大小。
当然，也可以从存储上找原因。

第十个等待事件db file scattered read
这个还需要说吗？呵呵

第十个等待事件db file sequential read

这个也可以说说：索引创建不恰当，检查一下索引的情况或检查聚簇因子。

下面是我前几天处理的一个library cache lock/pin等待事件的案例，
分享如下：
数据库版本:9.2.0.5

也可链接到http://space.itpub.net/21266384/viewspace-772409
生产环境library cache lock/pin解决方案

   前几天巡检数据库的时候发现数据库出现近55个session在library cache lock、library cache bin上等待。经过分析，发现有8个

session在对数据库对象进行编译或重编译，从9月7日(从周末开始)就开始对数据库对象进行编译或重编译，导致相关的依赖对象的数据库操

作被阻塞，相关依赖对象的数据库操作具体有select ,dml等操作，均被阻塞进程，以至于出现上述等待事件，被阻塞的session为47个。

下面的这个过程是解决的具体操作：

首先看到55个session在等待library cache lock、library cache bin

SQL> SELECTdistinct s.sid, kglpnmod"Mode", kglpnreq "Req", SPID "OS Process"

  FROM v$session_wait w, x$kglpn p, v$session s, v$process o

  WHERE p.kglpnuse = s.saddr

  AND p.kglpnhdl = w.p1raw

  and w.event like '%library cache%'

  and s.paddr = o.addr;  2    3    4    5    6  



       SID       Mode        Req OS Process

---------- ---------- ---------- ------------

       834          3          0 103856

       225          0          2 198538

       894          0          2 132230

       739          3          0 257234

        98          0          2 219290

        88          0          2 270956

       483          0          2 248826

       236          0          2 80360

       728          0          2 57178

       789          0          2 83764

       889          3          0 83658

       142          0          2 32746

       789          0          2 83764

       709          0          2 133414

       770          0          2 119300

       497          0          2 174704

        76          0          2 100064

       688          0          2 193496

       199          0          2 270842

       130          0          2 222368

       421          0          2 256196

       402          0          2 199614

       110          3          0 155564

       356          0          2 245854



       758          3          0 203856

       722          0          2 124620

       457          0          2 221432

       709          0          2 133414

       449          0          2 168288

       117          0          2 217924

       550          3          0 192620

       590          0          2 150370

       582          3          0 83046

       429          0          2 64810

       910          0          2 168536

       29          0          2 277628

       321          0          2 196554

       497          0          2 174704

       709          0          2 133414

       142          0          2 32746

       789          0          2 83764

       889          3          0 83658

       236          0          2 80360

       728          0          2 57178

       98           0          2 219290

       268          0          2 118170

       894          0          2 132230

       505          3          0 170336

       616          0          2 223686

      

上面的sql就在shared pool共享池检索出哪些session占用了被依赖资源的句柄，需要做的就是kill掉这些持有对象句柄的进程。

  下面这个sql就至找出持有锁的进程：

SQL> SELECT distinct s.sid, kglpnmod"Mode", kglpnreq "Req", SPID "OS Process"

  FROM v$session_wait w, x$kglpn p, v$session s, v$process o

  WHERE p.kglpnuse = s.saddr

  AND p.kglpnhdl = w.p1raw

  and w.event like '%library cache%'

  and s.paddr = o.addr

  and kglpnmod =3;



  2    3    4    5    6    7  

       SID       Mode        Req OS Process

---------- ---------- ---------- ------------

       834          3          0 103856

       505          3          0 170336

       739          3          0 257234

       889          3          0 83658

       758          3          0 203856

       110          3          0 155564

       550          3          0 192620

       582          3          0 83046



就是上面的8个进程占用了句柄，103856、170336、257234、83658、203856、155564、192620、83046

kill 掉这些进程：

oracle@DBHIS02>kill -9 103856

oracle@ DBHIS02>kill -9 170336

oracle@ DBHIS02>kill -9 257234

oracle@ DBHIS02>kill -9 83658

oracle@ DBHIS02>kill -9 203856

oracle@ DBHIS02>kill -9 155564

oracle@ DBHIS02>kill -9 192620

oracle@ DBHIS02>kill -9 83046



kill掉之后，阻塞的8个session释放了锁资源，被阻塞的47个session获得了资源，进行正常的资源请求。
至此，问题解决。

如果我写的不对的地方，请指出来，对我也是一个提高，希望大家一起进步。
谢谢。
作者: wei-xh    时间: 2013-9-11 12:00
www_xylove 发表于 2013-9-11 11:57
魏哥的帖子，一定要顶啊。
我平时在运维中出现的等待事件主要有
1.log file sync

总结的非常不错啊，加油加油！！
作者: hellodatabase    时间: 2013-9-11 12:01
www_xylove 发表于 2013-9-11 11:57
魏哥的帖子，一定要顶啊。
我平时在运维中出现的等待事件主要有
1.log file sync

有大师的风范！！等我周末也来好好总结总结！
作者: wei-xh    时间: 2013-9-11 12:02
hellodatabase 发表于 2013-9-11 12:01
有大师的风范！！等我周末也来好好总结总结！

加油加油！
作者: Power08    时间: 2013-9-11 12:05
新手，学习了
作者: wei-xh    时间: 2013-9-11 12:11
Power08 发表于 2013-9-11 12:05
新手，学习了

对哪些等待事件有自己的想法和认识都可以谈一谈，有奖品哦
作者: wei-xh    时间: 2013-9-11 13:58
diashad 发表于 2013-9-11 13:53
33个常见的等待事件

来源与：dave的，学习下。

非常全面，如果可以针对其中一到两个做深入分析就更好了
作者: myskyisverybig    时间: 2013-9-11 14:23
顶一下
作者: wei-xh    时间: 2013-9-11 14:25
myskyisverybig 发表于 2013-9-11 14:23
顶一下

可以简单谈谈你对于等待事件的理解
作者: 开心老爸    时间: 2013-9-11 15:30
catch:buffer_chain
db file scattered read
db file sequential read
作者: sylvanzzy    时间: 2013-9-11 16:51
众人拾柴火焰高.支持这类型讨论，但是还需要一个比较完整的总结性结论
作者: wei-xh    时间: 2013-9-11 16:52
sylvanzzy 发表于 2013-9-11 16:51
众人拾柴火焰高.支持这类型讨论，但是还需要一个比较完整的总结性结论

大家先发表看法，结贴时，我会发表结论性的结论，多谢支持！！
作者: guoyJoe    时间: 2013-9-11 20:12
本帖最后由 guoyJoe 于 2013-9-11 20:14 编辑

不错的话题，顶兴华大师!之前也讨论过几个待等!

监听连接时间过长如何解决
http://www.itpub.net/thread-1784287-1-1.html

被误读的buffer busy waits系列问题讨论
http://www.itpub.net/thread-1779349-1-1.html

完全揭秘log file sync等待事件
http://www.itpub.net/thread-1777234-1-1.html


逻辑读产生Cache Buffer Chain(简称CBC) Latch的解析
http://www.itpub.net/thread-1764511-1-1.html
作者: wei-xh    时间: 2013-9-11 21:29
guoyJoe 发表于 2013-9-11 20:12
不错的话题，顶兴华大师!之前也讨论过几个待等!

监听连接时间过长如何解决

多谢郭大给力支持！
作者: yyp2009    时间: 2013-9-13 10:47
本帖最后由 yyp2009 于 2013-9-13 10:52 编辑
wei-xh 发表于 2013-9-10 10:34
不错，可以说的更细点，方便大家学习。

local_write_wait
enq：cf_contention

作者: _aiq黄舒文_hx    时间: 2013-9-16 15:25
不错，此问题继续发扬
作者: wll1017    时间: 2013-9-16 20:10
除了上述大家所的，cursor: pin S wait on X  也算吧
作者: last_day_1983    时间: 2013-9-17 08:49
遇到最多的为cache buffer chains latch
作者: tolilong    时间: 2013-9-17 11:49
本帖最后由 tolilong 于 2013-9-17 11:49 编辑

网络等待时间也算吧
客户端和数据库之间有网络问题的时候，容易出现如下两个事件。
sql*net message from/to client
sql*net more data from/to client

数据库和数据库之间容易出现如下两个等待事件。
sql*net message from/to dblink
sql*net more data from/to dblink
作者: _aiq黄舒文_hx    时间: 2013-9-19 21:14
不错不错
作者: jstjk021    时间: 2013-9-24 22:40
学习中！



欢迎光临 ITPUB论坛－专业的IT技术社区 (http://www.itpub.net/) Powered by Discuz! X3.2