16.librarycachepin等待事件和librarycachelock一样，都是共享池并发操作引起的。一般来说，Oracle如果要重新编译一些对象，比如PL/SQL或者views，需要把这些对象pin到sharedpool中。如果此时此对象为其他用户所有，则会产生librarycachepinwait。这个等待事件还包含四个参数：--句柄地址：加载对象的地址。--锁地址：锁的地址。--Mode：加载对象的数据片段。--Namespace：加载对象在v$db_object_cache视图中的命名空间名称。17.Logfileparallelwrite后台进程LGWR负责将logbuffer中的数据写入REDO文件，以重用logbuffer中的数据。如果每个REDOLOG组中的成员超过2个，LGWR进程会将REDO信息并行写入这些文件。如果数据库出现等待事件的瓶颈，主要原因可能是磁盘I/O性能不足或者REDO文件分布导致I/O争用，比如同组的REDO成员文件被放置在同一个磁盘上。这个等待事件有三个参数：--Files：操作要写入的文件数。--Blocks：操作需要写入的数据块数。--requests：操作需要执行的I/O次数。18.日志缓冲区空间当日志缓冲区中没有可用空间来存储新生成的重做日志数据时，将发生日志缓冲区空间等待事件。如果数据库中新产生的redolog数量大于LGWR写入磁盘的redolog数量，则必须等待LGWR完成写入磁盘的操作。LGWR必须确保重做日志成功写入磁盘，然后才能在重做缓冲区中重用。部分信息。如果数据库中有大量的logbuffer空间等待事件，可以考虑以下方法：--增加redobuffer的大小。--提高磁盘I/O性能19.日志文件顺序读取这种等待事件通常发生在读取redolog信息时，比如在线重做归档操作，ARCH进程需要读取redolog信息，由于redolog信息是顺序写入的，所以读的时候也是顺序读的。这个等待事件包含三个参数：--Log#：等待发生时读取的重做日志的序号。--Block#：要读取的数据块号。--Blocks：读取的数据块数。20.日志文件单写当重做日志文件的文件头被更新时，就会发生这个等待事件。当日志组中加入新的日志成员或重做日志的序号发生变化时，LGWR会更新重做日志文件的头信息。这个等待事件包含三个参数：--Log#：写入的重做日志组的编号。--Block#：要写入的数据块号。--Blocks：写入的数据块数。21、日志文件切换（需要归档）在归档模式下，当在线日志切换（日志文件切换）时，需要切换的在线日志还没有被归档进程（ARCH）归档，就会发生这个等待事件。当在线日志文件切换到下一个日志时，需要保证下一个日志文件已经被归档进程归档，否则不允许覆盖在线日志信息（否则归档日志信息将不完整).这样的等待事件通常是因为ARCH进程因为某种原因挂掉而发生的。例如，ARCH进程试图向目的地写入一个归档文件，但失败了（介质故障或其他原因），那么ARCH进程就会死亡。如果发生这种情况，可以在数据库的警报日志文件中找到相关的错误消息。此等待事件没有参数。22、日志文件切换(checkpointincomplete)当一个在线日志切换到下一个在线日志时，必须保证要切换到的在线日志上记录的信息（比如一些脏数据块产??生的redolog）写入磁盘（checkpoint），这是因为如果一个在线日志文件的信息被覆盖，依赖redo信息进行恢复的数据块还没有写入磁盘（checkpoint），如果此时系统宕机，Oracle将无法进行实例恢复。联机日志的状态记录在v$log视图中。一般来说，在线日志有三种状态。--Active：此日志上保护的信息还没有完成检查点。--Inactive：此日志上受保护的信息已完成检查点。--Current：当前日志。如果系统中有大量的logfileswitch(checkpointincomplete)等待事件，原因可能是log文件太小或者loggroup数量太少，解决方法是增加size日志文件或增加日志组的数量。此等待事件没有参数。23.Logfilesync这是用户会话行为引起的等待事件。当一个session发出commit命令时，LGWR进程会将这个事务产生的redolog从logbuffer中写入磁盘，以确保用户提交的信息被安全地记录在数据库中。session发出commit命令后，需要等待LGWR将本次事务产生的redo成功写入磁盘，才能进行后续操作。此等待事件称为日志文件同步。以下几种情况可能会导致这种等待：--高提交频率解决方法是简单地消除不必要的提交，事务是一个工作单元。工作单元要么全部成功，要么全部失败。--具有更高IO吞吐量的慢速I/O子系统可以改善日志文件同步和日志文件并行写入事件的平均等待时间。频繁提交搞乱了数据库布局和IO子系统。解决方案是将日志文件放在原始设备上，或者将它们绑定到RAID0或RAID0+1而不是RAID5。--日志缓冲区过大日志缓冲区过大也可能会延长日志文件同步等待时间。一个大的日志缓冲区减少了后台写入的次数，允许LGWR变得懒惰，并导致更多的重做条目在日志缓冲区中积累。同时可以调整参数_LOG_IO_SIZE。默认值为LOG_BUFFER的1/3或1MB，以较小者为准。换句话说，您可以拥有更大的日志缓冲区，但较小的_LOG_IO_SIZE会增加后台写入，从而减少日志文件同步的等待时间。--toosmalllogbuffertoosmalllogbuffer,也会造成logbuffer空间等待--loggroup的个数不适合logsize。这个等待事件包含一个参数：Buffer#：redobuffer中需要写入磁盘的buffer。24.SQL*Netbreak/resettoclient当这个等待事件发生时，表示服务器正在向客户端发送断开或重置连接的请求，正在等待客户端的响应。通常的原因是服务器和客户端之间的连接。网络不稳定造成的。这个等待事件包含两个参数：--Driverid：服务器和客户端连接使用的协议信息。--Breaks：零表示服务器向客户端发送复位消息，非零表示服务器向客户端发送中断消息。25.SQL*Netbreak/resettodblink的等待事件与SQL*Netbreak/resettoclient相同。但是，这意味着当一个数据库通过dblink访问另一个数据库时，它们之间建立了一个会话。此等待事件发生在会话之间的通信期间。同样，如果发生了这个等待事件，则需要检查两个数据库之间的连接。他们之间的沟通问题。这个等待事件有两个参数：--Driverid：服务器和客户端连接使用的协议信息。--Breaks：零表示服务器向客户端发送复位消息，非零表示服务器向客户端发送中断消息。26.来自客户端的SQL*Net消息的等待事件基本上是最常见的等待事件。当会话建立成功后，客户端会向服务器发送请求，服务器处理完客户端的请求后将结果返回给客户端，并继续等待客户端的请求。这时，一个来自客户端等待的SQL*Net消息就会产生事件。很明显，这是一个空闲的等待。如果客户端不再向服务器发送请求，服务器将一直处于这种等待事件状态。这个等待事件包含两个参数：--Driverid：服务器和客户端连接使用的协议信息。--#bytes：服务器从客户端消息中接收到的字节数。27.SQL*Netmessagefromdblink的等待事件和SQL*Netmessagefromclient的等待事件是一样的，但是是指当一个数据库通过dblink访问另一个数据库时，他们之间会建立一个session，这个等待事件发生在本届会议在沟通过程中。这个等待事件也是一个空闲等待事件。该事件包含两个参数：--Driverid：服务器和客户端连接使用的协议信息。--#bytes：服务器通过dblink从另一台服务器接收到的字节数。28.SQL*Net消息给客户端当服务器向客户端发送消息时，这个等待事件发生。当服务器向客户端发送消息并等待时，可能的原因是客户端太忙，无法及时接收到服务器发送的消息，也可能是由于服务器端消息无法发送到客户端到网络问题。这个等待事件有两个参数：--Driverid：服务器和客户端连接使用的协议信息。--#bytes：服务器发送给客户端的消息中的字节数。29、SQL*Net消息到dblink的等待事件和SQL*Net消息到client的等待事件是一样的，只不过是数据库服务器和服务器之间的等待事件。这种等待的原因可能是远程服务器繁忙，无法及时收发。传入消息也可能是由于服务器之间的网络问题导致消息无法发送而引起的。这个等待时间包含两个参数：--Driverid：服务器和客户端连接使用的协议信息。--#bytes：服务器通过dblink发送给另一台服务器的字节数。30.SQL*Netmoredatafromclient服务器等待用户发送更多数据完成操作，比如一个大的SQL文本，导致一个SQL*Net数据包无法完成传输，所以服务器会等待forclienttosend整个SQL文本正在发送和处理，此时会产生一个SQL*Netmoredatafromclientwaiting事件。这个等待时间包含两个参数：--Driverid：服务器和客户端连接使用的协议信息。--#bytes：服务器从客户端接收到的字节数。
