Oralce 等待事件小结(下)

11>Direct path write

这个等待事件和direct path read 正好相反，是会话将一些数据从PGA中直接写入到磁盘文件上，而不经过SGA。

 

这种情况通常发生在：

使用临时表空间排序（内存不足）

数据的直接加载（使用append方式加载数据）

并行DML操作。

 

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

Descriptor address: 一个指针，指向当前会话正在等待的一个direct I/O.

First dba: descriptor address 中最旧的一个I/O数据块地址。Block cnt: descriptor address 上下文中涉及的有效地 buffer 数量。

 

12>Enqueue

Enqueue 这个词其实是lock 的另一种描述语。

当我们在AWR 报告中发现长时间的enqueue 等待事件时，说明数据库中出现了阻塞和等待，可以关联AWR报告中的enqueue activity部分来确定是哪一种锁定出现了长时间等待。

 

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

Name： enqueue 的名称和类型。

Mode： enqueue的模式。

 

可以使用如下SQL 查看当前会话等待的enqueue名称和类型：

/* Formatted on 2010/8/12 11:00:56 (QP5 v5.115.810.9015) */

SELECT   CHR (TO_CHAR (BITAND (p1, -16777216)) / 16777215)

         || CHR (TO_CHAR (BITAND (p1, 16711680)) / 65535)

            "Lock",

         TO_CHAR (BITAND (p1, 65535)) "Mode"

  FROM   v$session_wait

 WHERE   event = 'enqueue'

 

关于enqueue 可以参考如下的连接：

                Wait Events - Enqueue Waits

                

13>Free buffer waits

当一个会话将数据块从磁盘读到内存中时，它需要到内存中找到空闲的内存空间来存放这些数据块，当内存中没有空闲的空间时，就会产生这个等待；除此之外，还有一种情况就是会话在做一致性读时，需要构造数据块在某个时刻的前映像（image），此时需要申请内存来存放这些新构造的数据块，如果内存中无法找到这样的内存块，也会发生这个等待事件。

 

当数据库中出现比较严重的free buffer waits等待事件时，可能的原因是：

（1）data buffer 太小，导致空闲空间不够

（2）内存中的脏数据太多，DBWR无法及时将这些脏数据写到磁盘中以释放空间

 

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

File#： 需要读取的数据块所在的数据文件的文件号。

Block#： 需要读取的数据块块号。

14>Latch free

在10g之前的版本里，latch free 等待事件代表了所有的latch等待，在10g以后，一些常用的latch事件已经被独立了出来：

SQL> select name from v$event_name where name like 'latch%' order by 1;

所以latch free 等待事件在10g以后的版本中并不常见，而是以具体的Latch 等待事件出现。

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

Address: 会话等待的latch 地址。

Number： latch号，通过这个号，可以从v$latchname 视图中找到这个latch 的相关的信息。

         SQL> select * from v$latchname where latch#=number;

Tries: 会话尝试获取Latch 的次数。

15>Library cache lock

这个等待时间发生在不同用户在共享中由于并发操作同一个数据库对象导致的资源争用的时候，比如当一个用户正在对一个表做DDL 操作时，其他的用户如果要访问这张表，就会发生library cache lock等待事件，它要一直等到DDL操作完成后，才能继续操作。

 

这个事件包含四个参数：

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

Lock address： 锁的地址。

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

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

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等待事件，可以考虑如下方法：

（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文件中可以找到相关的错误信息。

这个等待事件没有参数。

解决办法：

可以考虑增大日志文件和增加日志组

移动归档文件到快速磁盘

调整log_archive_max_processess参数

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。

解决办法

一．提高LGWR性能，尽量使用快速磁盘，不要把redo log file放在RAID5的磁盘上，RAID5对于频繁写入的系统会带来较大的性能损失，可以考虑使用文件系统直接输入/输出，或者使用raw device，使写入性能提高

二．使用批量提交

三．使用nologging/unrecoverable等选项

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 访问另一个数据库时，他们之间会建立一个会话，这个等待事件发生在这个会话之间的通信过程中。

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

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发送给远程数据库。由于发送的数据太多或者网络性能问题，就会出现SQL*Net more data to dblink等待事件。

 

这个等待时间包含两个参数：

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

#bytes: 服务器端通过dblink发送给另一个服务器消息的字节数

 

 

--整理来着网络 转