如不雅数据库中出现这个等待事宜的瓶颈，重要的原因可能是磁盘I/O机能不敷或者REDO 文件的分布导致了I/O争用，比如同一个组的REDO 成员文件放在雷同的磁盘上。

这个等待事宜有三个参数：

这个等待事宜有三个参数。查看竽暌剐几个参数我们可以用以下SQL:

Blocks： 操作须要写入的数据块个数。

Requests：操作须要履行的I/O次数。

18. Log buffer space

当log buffer 中没有可用空间来存放新产生的redo log数据时，就会产生log buffer space等待事宜。如不雅数据库中新产生的redo log的数量大年夜于LGWR 写入稻磁逄中的redo log 数量，必须等待LGWR 完成写入磁盘的操作，LGWR必须确保redo log写稻磁逄成功之后，才能在redo buffer傍边重用这部分信息。

(1)增长redo buffer的大年夜小。

(2)晋升磁盘的I/O机能

这个等待事宜平日产生在对redo log信息进行攫取时，比如在线redo 的归档操作，ARCH过程须要攫取redo log的信息，因为redo log的信息是次序写入的，所以在攫取时也是按照次序的方法来攫取的。

这个等待事宜包含三个参数：

Log#： 产生等待时攫取的redo log的sequence号。

Block#： 攫取的数据块号。

Blocks： 攫取的数据块个数。

20. Log file single write

这个等待事宜产生在更新redo log文件的文件头时，当为日记组增长新的日记成员时或者redo log的sequence号改变时，LGWR 都邑更新redo log文件头信息。

这个等待事宜包含三个参数：

Log#： 写入的redo log组的编号。

Block#：写入的数据块号。

Blocks：写入的数据块个数。

21. Log file switch(archiving needed)

在归档模式下，这个等待事宜产生在在线日记切换(log file switch)时，须要切换的在线日记还没有被归档过程(ARCH)归档完毕的时刻。 当在线日记文件切换到下一?日记时，须要确保下一?日记文件已经被归档过程归档完毕，不然不许可覆盖那个在线日记信息(不然会导致归档日记信息不完全)。

出现如许的等待事宜平日是因为某种原因导致ARCH 过程逝世掉落，比如ARCH过程测验测验向目标地写入一个归档文件，然则没有成功(介质掉效或者其他原因)，这时ARCH过程就会逝世掉落。 如不雅产生这种情况，在数据库的alert log文件中可以找到相干的缺点信息。

这个等待事宜没有参数。

22. Log file switch(checkpoint incomplete)

在v$log 视图里记录了在线日记的状况。平日来说，在线日记有三种状况。

Active: 这个日记膳绫擎保护的信息还没有完成checkpoint。

Current： 当前的日记。

Oracle 在做实例恢复时，会应用状况为current和Active的日记进行实例恢复。

如不雅体系中出现大年夜量的log file switch(checkpoint incomplete)等待事宜，原因可能是日记文件太小或者日记组太少，所以解决的办法是，增长日记文件的大年夜小或者增长日记组的数量。

这个等待事宜没有参数。

23. Log file sync

这是一个用户会话行动导致的等待事宜，当一个会话发出一个commit敕令时，LGWR过程会将这个事务产生的redo log大年夜log buffer琅绫擎写稻磁逄上，以确保用户提交的信息被安然地记录到数据库中。

会话发出的commit指令后，须要等待LGWR将这个事务产生的redo 成功写入稻磁逄之后，才可以持续进行后续的操作，这个等待事宜就叫作log file sync。

当体系中出现大年夜量的log file sync等待事宜时，应当检查数据库中是否有效户在做频繁的提交操作。

这种等待事宜平日产生在OLTP体系上。OLTP 体系中存在很多小的事务，如不雅这些事务频繁被提交，可能引起大年夜量的log file sync的等待事宜。

这个等待事宜包含一个参数：

Buffer#: redo buffer 中须要被写入稻磁逄中的buffer。

这个等待事宜平日只产生在一种情况下，就是Oracle 更新数据文件头信息时(比如产生Checkpoint)。

chain#： buffer chains hash 列表中的索引值，当这个参数的值等于s 0xfffffff时，解释当前的会话正在等待一个LRU latch。

24. SQL*Net break/reset to client

当出现这个等待事宜时，解释办事器端在给客户端发送一个断开连接或者重置连接的请求，正在等待客户的响应，平日的原因是办事器到客户端的收集不稳定导致的。

Mode： enqueue的模式。

这个等待事宜包含两个参数：Driver id: 办事器和客户端连接应用的协定信息。

Break?：零表示办事端向客户端发送一个重置(reset)信息，非零表示办事器端向客户端发送一个断开(break)消息。

25. SQL*Net break/reset to dblink

这个等待事宜和SQL*Net break/reset to client 雷同。不过它表示的是数据库经由过程dblink拜访另一台数据库时，他们之间建立起一个会话，这个等待事宜产生在这个会话之间的通信过程中，同样如不雅出现这个等待事宜，须要检查两台数据库之间的通信问题。

这个等待事宜有两个参数：

Driver id: 办事器和客户端连接应用的协定信息。

Break?：零表示办事端向客户端发送一个重置(reset)信息，非零表示办事器端向客户端发送一个断开(break)消息。

26. SQL*Net message from client

这个等待事宜根本上是最常见的一个等待事宜。当一个会话建立成功后，客户端会向办事器端发送请求，办事器端处理完客户端请求后，将结不雅返回给客户端，并持续等待客户端的请求，这时刻会产生SQL*Net message from client 等待事宜。

很显然，这是一个余暇等待，如不雅客户端不再向办事器端发送请求，办事器端将一向处于这个等待事宜状况。

Driver id: 办事器端和客户端连接应用的协定信息。

27. SQL*Net message from dblink

这个等待事宜和SQL*Net message from client雷同，不过它表示的是数据库经由过程dblink 拜访另一个数据库时，他们之间会建立一个会话，这个等待事宜产生在这个会话之间的通信过程中。

　　推荐阅读

　　芯片开源成功难 谁来挑战ARM架构？

沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！ 这场开源活动大年夜软件而起，>>>详细阅读

本文标题：Oracle中常见的33个等待事件小结

地址：http://www.17bianji.com/lsqh/38167.html

 1/2    1