18. Log buffer space
当log buffer 中没有可用空间来存放新产生的redo log数据时，就会发生log buffer space等待事件。如果数据库中新产生的redo log的数量大于LGWR 写入到磁盘中的redo log 数量，必须等待LGWR 完成写入磁盘的操作，LGWR必须确保redo log写到磁盘成功之后，才能在redo buffer当中重用这部分信息。

如果数据库中出现大量的log buffer space等待事件，可以考虑如下方法：
（1）增加redo buffer的大小。
（2）提升磁盘的I/O性能

19. Log file sequential read
这个等待事件通常发生在对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)
当一个在线日志切换到下一个在线日志时，必须保证要切换到的在线日志上的记录的信息（比如一些脏数据块产生的redo log）被写到磁盘上（checkpoint），这样做的原因是，如果一个在线日志文件的信息被覆盖，而依赖这些redo 信息做恢复的数据块尚未被写到磁盘上（checkpoint），此时系统down掉的话，Oracle将没有办法进行实例恢复。

在v$log 视图里记录了在线日志的状态。通常来说，在线日志有三种状态。
Active: 这个日志上面保护的信息还没有完成checkpoint。
Inactive： 这个日志上面保护的信息已完成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。

24. SQL*Net break/reset to client
当出现这个等待事件时，说明服务器端在给客户端发送一个断开连接或者重置连接的请求，正在等待客户的响应，通常的原因是服务器到客户端的网络不稳定导致的。

这个等待事件包含两个参数：
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: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端接收到的来自客户端消息的字节数。

27． SQL*Net message from dblink
这个等待事件和SQL*Net message from client相同，不过它表示的是数据库通过dblink 访问另一个数据库时，他们之间会建立一个会话，这个等待事件发生在这个会话之间的通信过程中。

这个等待事件也是一个空闲等待事件。

这个事件包含两个参数：
Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端通过dblink 收到的来自另一个服务器端消息的字节数。

28. SQL*Net message to client
这个等待事件发生在服务器端向客户端发送消息的时候。当服务器端向客户端发送消息产生等待时，可能的原因是用户端太繁忙，无法及时接收服务器端送来的消息，也可能是网络问题导致消息无法从服务器端发送到客户端。

这个等待事件有两个参数：
Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端向客户端发送消息的字节数。