wait event监测性能瓶颈

会话等待事件视图：v$system_event、v$session_event、v$session_wait。
会话等待事件是独立于应用的，所以它可以作为很好的性能监测工具的基础依据。任何一个应用具有很高的全表扫描的等待事件都意味着i/o有了问题。

v$system_event
用来查看整个系统级性能情况，对每个事件总计了从系统启动以来在所有会话中发生过的情况，这些信息每次重启后都会被重新计数。
event：列出了所有发生的事件的名称。latch waits、db file scattered read、db file sequential read、enqueue wait 、buffer busy wait、log file parallel write、free buffer waits。
total_waits：从数据库启动到现在等待事件总的等待次数。
total_timeouts：总的等待超时的次数。
time_waited：总的等待时间，以1%秒为单位。数据库启动以来某个等待事件在所有会话中（包括已经结束和正保持 连接的会话）总的等待时间之和。
average_wait：平均等待时间，以1%秒为单位。数据库启动以来某个等待事件在所有会话中平均等待时间。

v$session_event
查看会话级的统计。会话重新建立时信息将被重置为0。

v$session_wait
包含了当前正处于连接状态的会话的等待事件，提供了当前已经发生或正在发生的事件的可用信息。例如：一个正在发生锁存器竞争的会话，此时正在等待那个锁存器。或者，一个会话正在等待对一个数据块的访问。
sid：会话的id。
seq#：会话的内部顺序号。
event：描述事件的名称。
p[1-3]：提供详细信息。
state：提供了wait_time和seconds_in_wait两个字段的解释。

• waiting：会话正在等待这个事件。
• waited unknown time ：由于timed_statistics设置为false，而导致不能得到关于时间的信息。
• waited short time：表示会话发生了等待，但是等待事件非常小，不超过一个时间单位，所以没有记录。
• waited known time：一旦会话等待了资源然后得到了，那么状态将从waiting进驻waited known time。

*记住记录在v$session_event中的等待事件记录在当前等待的资源没有等到之前是不会更新的。所以如果一个等待事件等待的事件非常长，那么将很明显的看到，在v$session_wait中的统计信息将持续增加而相应v$session_event中的信息保持不变。

发现系统变慢时，首先通过v$system_event从系统级进行收集，不仅仅要看累计的系统等待事件信息，更重要的时一段时间内等待的时间增量。然后通过产看v$session_wait视图，可以判断具体问题。例如，如果发生i/o竞争，原因是由于对索引的访问还是大量的全表扫描等等。如果命中率低，不要着急看看有没有相关的等待事件，如果没有就不用担心。相反，如果命中率很高，却存在大量的等待，原因有可能数据高速缓存区过大，超过了物理内存的大小，带来了大量的分页交换。


带有函数或者表达式的where语句，字段上的索引是不会被用到的，会引起全表扫描。

总结：
了解应用的需求，确定为什么要使用to_char函数屏蔽status字段索引的使用。
调整收集到的sql语句书写，减少全表扫描的发生，从而减少相应的i/o操作
考虑在索引上使用nologging，减少表中数据维护相应的索引维护产生的重做日志。
减少重做日志文件所在磁盘上无关紧要的i/o操作，如果必要，将重做日志文件移动到新的磁盘上。
从长远考虑，增加重做日志文件组的个数和组员文件的大小以防止其他重做日志相关的等待事件的发生。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8570952/viewspace-713607/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8570952/viewspace-713607/