|
|
讨论话题：
谈一谈你对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
|
|
IP卡
狗仔卡
发表于 2013-9-10 09:59
收藏
提升卡
置顶卡
变色卡
显身卡
楼主
多谢波波给力支持
