必看干货 | Oracle常见的等待事件说明（下）

[[212099]]

16.Library cache pin

这个等待事件和 library cache lock 一样是发生在共享池中并发操作引起的事件。通常来讲，如果 Oracle 要对一些 PL/SQL 或者视图这样的对象做重新编译，需要将这些对象 pin 到共享池中。如果此时这个对象被其他的用户特有，就会产生一个 library cache pin 的等待。

这个等待事件也包含四个参数：

–Handle address: 被加载的对象的地址。

–Lock address：锁的地址。

–Mode：被加载对象的数据片段。

–Namespace：被加载对象在 v$db_object_cache 视图中 namespace 名称。

17.Log file parallel write

后台进程 LGWR 负责将 log buffer 当中的数据写到 REDO 文件中，以重用 log buffer 的数据。如果每个 REDO LOG 组里面有 2 个以上的成员，那么 LGWR 进程会并行地将 REDO 信息写入这些文件中。

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

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

–Files：操作需要写入的文件个数。

–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 当中重用这部分信息。

如果数据库中出现大量的 log buffer space 等待事件，可以考虑如下方法：

— 增加 redo buffer 的大小。

— 提升磁盘的 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：当前的日志。

如果系统中出现大量的 log file switch（checkpoint incomplete）等待事件，原因可能是日志文件太小或者日志组太少，所以解决的方法是，增加日志文件的大小或者增加日志组的数量。

这个等待事件没有参数。

23.Log file sync

这是一个用户会话行为导致的等待事件，当一个会话发出一个 commit 命令时，LGWR 进程会将这个事务产生的 redo log 从 log buffer 里面写到磁盘上，以确保用户提交的信息被安全地记录到数据库中。会话发出的 commit 指令后，需要等待 LGWR 将这个事务产生的 redo 成功写入到磁盘之后，才可以继续进行后续的操作，这个等待事件就叫作 log file sync。

以下几种情况，可能产生这个等待：

— 高提交频率

解决方法是简单的消除不必要的提交，事务是工作单元。工作单元应该是全部成功或全部失败。

— 缓慢的 I/O 子系统

较高的 IO 吞吐良可以改善 log file sync 和 log file parallel write 事件的平均等待时间。频繁的提交会弄乱数据库布局和 IO 子系统。解决办法是将日志文件放裸设备上或绑定在 RAID 0 或 RAID 0+1 中，而不是绑定在 RAID 5 中。

— 过大的日志缓冲区

过大的日志缓冲区也可能延长 log file sync 等待。大型的日志缓冲区减少后台写入的数量，允许 LGWR 变得懒惰，并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE 参数，其默认值是 LOG_BUFFER 的 1/3 或 1MB，取两者之中较小的值。换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE 将增加后台写入，从而减少 log file sync 的等待时间.

— 过小的日志缓冲区

过小的日志缓冲区，还会导致 log buffer space 等待

— 日志组多少与日志大小不合适

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

Buffer#: redo buffer 中需要被写入到磁盘中的 buffer。

24.SQL*Net break/reset to client

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

这个等待事件包含两个参数：

–Driver id: 服务器和客户端连接使用的协议信息。

–Breaks：零表示服务端向客户端发送一个重置（reset）信息，非零表示服务器端向客户端发送一个断开（break）消息。

25.SQL*Net break/reset to dblink

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

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

–Driver id: 服务器和客户端连接使用的协议信息。

–Breaks：零表示服务端向客户端发送一个重置（reset）信息，非零表示服务器端向客户端发送一个断开（break）消息。

26.SQL*Net message from client

这个等待事件基本上是最常见的一个等待事件。当一个会话建立成功后，客户端会向服务器端发送请求，服务器端处理完客户端请求后，将结果返回给客户端，并继续等待客户端的请求，这时候会产生 SQL*Net message from client 等待事件。很显然，这是一个空闲等待，如果客户端不再向服务器端发送请求，服务器端将一直处于这个等待事件状态。

这个等待事件包含两个参数：