当一个在线日志切换到下一个在线日志时，必须保证要切换到的在线日志上的记录的信息（比如一些脏数据块产生的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: 服务器端向客户端发送消息的字节数。
?
29. SQL*Net message to dblink
这个等待事件和SQL*Net message to client 相同，不过是发生在数据库服务器和服务器之间的等待事件，产生这个等待的原因可能是远程服务器繁忙，而无法及时接收发送过来的消息，也可能是服务器之间网络问题导致消息无法发送过来。
?这个等待时间包含两个参数：
Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端通过dblink发送给另一个服务器消息的字节数。
?
30. SQL*Net more data from client
服务器端等待用户发出更多的数据以便完成操作，比如一个大的SQL文本，导致一个SQL*Net 数据包无法完成传输，这样服务器端会等待客户端把整个SQL 文本发过来在做处理，这时候就会产生一个SQL*Net more data from client 等待事件。
?这个等待时间包含两个参数：
Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端从客户端接收到消息的字节数。
?
31. SQL*Net more data from dblink
在一个分布式事务中，SQL 分布在不同的数据库中执行，远程数据库执行完毕后将结果通过dblink返给发出SQL的数据库，在等待数据从其他数据库中通过dblink传回的过程中，如果数据在远程数据库上处理时间很久，或者有大量的结果集需要返回，或者网络性能问题都会产生SQL*Net more data from dblink 等待事件，它的意思是本地数据库需要等到所有的数据从远程处理完毕通过dblink传回后，才可以在本机继续执行操作。
?这个等待时间包含两个参数：
Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端通过dblink发送给另一个服务器消息的字节数。
?
32. SQL*Net more data to client
当服务器端有太多的数据需要发给客户端时，可能会产生SQL*Net more data to client等待事件，也可能由于网络问题导致服务器无法及时地将信息或者处理结果发送给客户端，同样会产生这个等待。
?这个等待时间包含两个参数：
Driver id: 服务器端和客户端连接使用的协议信息。
#bytes: 服务器端向客户端发送消息的字节数。
?
33. SQL*Net more data to dblink
这个等待事件和SQL*Net more data to client 等待时间基本相同，只不过等待发生在分布式事务中，即本地数据库需要将更多的数据通过dblink发送给远程数据库。由于发送的数