ORACLE 等待事件的分类

等待事件是总个性能调优的入口。

在总体查看ORACLE数据库性能时，总是会先看TOP  N WAIT,比如：

下面我切了一段我的AWR报表内容：

Top Timed Events
     '*' Cnt : count of instances with wait times for the event





Wait Event Wait Time I#ClassEventWaits*
DB CPU





User I/Odb file sequential read203,391*



Commitlog file sync173,402*



NetworkLNS wait on SENDREQ230,029*



OtherLGWR-LNS wait on channel403,571*



System I/Olog file parallel write213,373*
   System I/Odb file parallel write82,579*    System I/Ocontrol file sequential read31,898*    System I/Ocontrol file parallel write6,894
这时可以看出，每一种等待事件的分类，从分类我们很清楚就知道，在哪种等待

消耗了更多的资源。

再成分类细化，对性能优化就有了一个很清晰的方向了。

（1.如果是USER I/O ，那么查看最大消耗的应对的 SQL SCRIPT,

  2.如果是 SYSTEM I/O 查看 是什么等待事件，看是否能在数据库级别进行调优.....）

从我的报表中可以看到，第一位的还是  User I/O，并且等待事件为： db file sequential read，

引起此等待事件的原因大体为：

通常显示与单个数据块相关的读取操作，在大多数情况下，读取一个索引块或者通过索引读取一个数据块时，都会记录这个等待。

如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，可能没有正确的使用驱动表；或者可能索引的使用存在问题，并非索引总是最好的选择。

在大多数情况下，通过索引可以更为快速地获取记录，所以对于一个编码规范、调整良好的数据库，这个等待事件很大通常是正常的。但是在很多情况下，使用索引并不是最佳的选择，比如读取较大表中大量的数据，全表扫描可能会明显快于索引扫描，所以在开发中就应该注意，对于这样的查询应该避免使用索引扫描。

ORACLE 等待事件的分类 

1ADMINISTRATIVEDBA的命令导致的等待，如重建索引2APPLICATION可能是应用的代码导致的等待，比如：行级锁和显式的表锁；3CLUSTERRAC集群相关的等待，全局内存的等待，一个实例等待另一个实例的复制。心跳线带宽不够，实例间内存交换过于频繁。4COMMIT这个类别仅和一个等待事件相关，在发出commit命令后等待redo log write 确认，这个事件是log file sync,5CONCURRENCY内部资源造成的等待，如latches 6CONFIGURATION由于实例或数据库资源配置不当而造成的等待，如不适当的redo log buffer size 和 shared_pool size;7IDLE  Session为非活动的且等待工作，此类事件属于此范畴，典型的如 'SQL*Net message from client'；8NETWORK基于网络的等待，如'SQL*Net more data to dblink'9QUEUE基于队列的一些等待，如 'wait for EMON to spawn'；10SCHEDULER资源管理器相关等待，如'resmgr: become active'；11SYSTEM I/O系统后台产生的I/O等待，比如DBWR写LOG产生的，如DBWR wait for 'db file parallel write'，比如DBWR进程不够时，这时可以添加DBWR进程。12USER I/O用户产生的I/O等待13OTHER通常不会发生的等待，如 'wait for EMON to spawn'；