等待事件是总个性能调优的入口。
在总体查看ORACLE数据库性能时,总是会先看TOP N WAIT,比如:
下面我切了一段我的AWR报表内容:
Top Timed Events | |||
'*' Cnt : count of instances with wait times for the event | |||
Wait | Event | Wait Time | |
I# | Class | Event | Waits |
* | DB CPU | ||
User I/O | db file sequential read | 203,391 | |
* | |||
Commit | log file sync | 173,402 | |
* | |||
Network | LNS wait on SENDREQ | 230,029 | |
* | |||
Other | LGWR-LNS wait on channel | 403,571 | |
* | |||
System I/O | log file parallel write | 213,373 | |
* | |||
System I/O | db file parallel write | 82,579 | |
* | |||
System I/O | control file sequential read | 31,898 | |
* | |||
System I/O | control file parallel write | 6,894 |
这时可以看出,每一种等待事件的分类,从分类我们很清楚就知道,在哪种等待
消耗了更多的资源。
再成分类细化,对性能优化就有了一个很清晰的方向了。
(1.如果是USER I/O ,那么查看最大消耗的应对的 SQL SCRIPT,
2.如果是 SYSTEM I/O 查看 是什么等待事件,看是否能在数据库级别进行调优.....)
从我的报表中可以看到,第一位的还是 User I/O,并且等待事件为: db file sequential read,
引起此等待事件的原因大体为:
通常显示与单个数据块相关的读取操作,在大多数情况下,读取一个索引块或者通过索引读取一个数据块时,都会记录这个等待。
如果这个等待事件比较显著,可能表示在多表连接中,表的连接顺序存在问题,可能没有正确的使用驱动表;或者可能索引的使用存在问题,并非索引总是最好的选择。
在大多数情况下,通过索引可以更为快速地获取记录,所以对于一个编码规范、调整良好的数据库,这个等待事件很大通常是正常的。但是在很多情况下,使用索引并不是最佳的选择,比如读取较大表中大量的数据,全表扫描可能会明显快于索引扫描,所以在开发中就应该注意,对于这样的查询应该避免使用索引扫描。
ORACLE 等待事件的分类
1 | ADMINISTRATIVE | DBA的命令导致的等待,如重建索引 |
2 | APPLICATION | 可能是应用的代码导致的等待,比如:行级锁和显式的表锁; |
3 | CLUSTER | RAC集群相关的等待,全局内存的等待,一个实例等待另一个实例的复制。心跳线带宽不够,实例间内存交换过于频繁。 |
4 | COMMIT | 这个类别仅和一个等待事件相关,在发出commit命令后等待redo log write 确认,这个事件是log file sync, |
5 | CONCURRENCY | 内部资源造成的等待,如latches |
6 | CONFIGURATION | 由于实例或数据库资源配置不当而造成的等待,如不适当的redo log buffer size 和 shared_pool size; |
7 | IDLE | Session为非活动的且等待工作,此类事件属于此范畴,典型的如 'SQL*Net message from client'; |
8 | NETWORK | 基于网络的等待,如'SQL*Net more data to dblink' |
9 | QUEUE | 基于队列的一些等待,如 'wait for EMON to spawn'; |
10 | SCHEDULER | 资源管理器相关等待,如'resmgr: become active'; |
11 | SYSTEM I/O | 系统后台产生的I/O等待,比如DBWR写LOG产生的,如DBWR wait for 'db file parallel write',比如DBWR进程不够时,这时可以添加DBWR进程。 |
12 | USER I/O | 用户产生的I/O等待 |
13 | OTHER | 通常不会发生的等待,如 'wait for EMON to spawn'; |