[转载]---Oracle 常见的33个等待事件

1、本文说明：

      操做系统：rhel 5.4 x32

      数据库：oracle 11g r2 x32

2、等待事件的相关知识：

1.一、等待事件主要能够分为两类，即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件。

    1)、空闲等待事件指ORACLE正等待某种工做，在诊断和优化数据库的时候，不用过多注意这部分事件。

    2)、非空闲等待事件专门针对ORACLE的活动，指数据库任务或应用运行过程当中发生的等待，这些等待是在调整数据库的时候须要关注与研究的。

    在Oracle 10g中的等待事件有874个，11g中等待事件有1118个。咱们能够经过v$event_name视图来查看等待事件的相关信息。

1.二、查看v$event_name视图的字段结构：

 1 SQL> desc v$event_name;
 2  Name                  Null?      Type
 3  ------------------- -------- ----------------------------
 4  EVENT#                          NUMBER
 5  EVENT_ID                        NUMBER
 6  NAME                            VARCHAR2(64)
 7  PARAMETER1                      VARCHAR2(64)
 8  PARAMETER2                      VARCHAR2(64)
 9  PARAMETER3                      VARCHAR2(64)
10  WAIT_CLASS_ID                   NUMBER
11  WAIT_CLASS#                     NUMBER
12  WAIT_CLASS                      VARCHAR2(64)

1.三、查看等待事件总数：

1 SQL> select count(*) from v$event_name;
2 
3   COUNT(*)
4 ----------
5       1118

1.四、查看等待事件分类状况：

 1 SQL> col wait_class for a30;
 2 SQL> select wait_class#,wait_class_id,wait_class,count(*) as "count"
 3   2    from v$event_name
 4   3      group by wait_class#,wait_class_id,wait_class
 5   4  order by wait_class#;
 6 
 7 WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS                  count
 8 ----------- ------------- ------------------------------ ----------
 9       0    1893977003 Other                 719
10       1    4217450380 Application                 17
11       2    3290255840 Configuration              24
12       3    4166625743 Administrative             54
13       4    3875070507 Concurrency                 32
14       5    3386400367 Commit                  2
15       6    2723168908 Idle                     94
16       7    2000153315 Network                 35
17       8    1740759767 User I/O                 45
18       9    4108307767 System I/O                 30
19      10    2396326234 Scheduler                  7
20 
21 WAIT_CLASS# WAIT_CLASS_ID WAIT_CLASS                  count
22 ----------- ------------- ------------------------------ ----------
23      11    3871361733 Cluster                 50
24      12    644977587 Queueing                  9
25 
26 13 rows selected.

1.五、相关的几个视图：

    V$SESSION：表明数据库活动的开始，视为源起。

    V$SESSION_WAIT：视图用以实时记录活动SESSION的等待状况，是当前信息。

    V$SESSION_WAIT_HISTORY：是对V$SESSION_WAIT的简单加强，记录活动SESSION的最近10次等待。

    V$SQLTEXT：当数据库出现瓶颈时，一般能够从V$SESSION_WAIT找到那些正在等待资源的SESSION，经过SESSION的SID，联合V$SESSION和      V$SQLTEXT视图就能够捕获这些SESSION正在执行的SQL语句。

    V$ACTIVE_SESSION_HISTORY：是ASH的核心，用以记录活动SESSION的历史等待信息，每秒采样一次，这部份内容记录在内存中，指望值是记录一个小时的内容。

    WRH#_ACTIVE_SESSION_HISTORY：是V$ACTIVE_SESSION_HISTORY在AWR的存储地。

    V$ACTIVE_SESSION_HISTORY：中的信息被按期(每小时一次)的刷新到负载库中，并缺省保留一个星期用于分析。

    DBA_HIST_ACTIVE_SESS_HISTORY：视图是WRH#_ACTIVE_SESSION_HISTORY视图和其余几个视图的联合展示，一般经过这个视图进行历史数据的访问。

    V$SYSTEM_EVENT：因为V$SESSION记录的是动态信息，和SESSION的生命周期相关，而并不记录历史信息，因此ORACLE提供视图V$SYSTEM_EVENT来记录数据库自启动以来全部等待事件的汇总信息。经过这个视图，用户能够迅速得到数据库运行的整体概况。

3、33个常见的等待事件

一、Buffer busy waits

    从本质上讲，这个等待事件的产生仅说明了一个会话在等待一个Buffer(数据块)，可是致使这个现象的缘由却有不少种。常见的两种是：

        当一个会话试图修改一个数据块，但这个数据块正在被另外一个会话修改时。

        当一个会话须要读取一个数据块，但这个数据块正在被另外一个会话读取到内存中时。

     Oracle操做的最小单位是块(Block)，即便你要修改一条记录，也须要对这条记录所在的这个数据块作操做。当你对这个数据块作修改时，其余的会话将被阻止对这个数据块上的数据作修改(即便其余用户修改的不是当前用户修改的数据)，可是能够以一致性的方式读取这个数据块(from undo)。当前的用户修改完这个数据块后，将会当即释放掉加在这个数据块上的排他锁，这样另外一个会话就能够继续修改它。修改操做是一个很是短暂的时间，这种加锁的机制咱们叫Latch。

    当一个会话修改一个数据块时，是按照如下步骤来完成的：

        a.以排他的方式得到这个数据块(Latch)；

        b.修改这个数据块；

        c.释放Latch。

    Buffer busy waits等待事件常见于数据库中存在的热块的时候，当多个用户频繁地读取或者修改一样的数据块时，这个等待事件就会产生。若是等待的时间很长，咱们在AWR或者statspack报告中就能够看到。

    这个等待事件有三个参数。查看有一个参数咱们能够用如下SQL：

1 SQL> col parameter1 for a10;
2 SQL> col parameter2 for a10;
3 SQL> col parameter3 for a10;
4 SQL> col name for a20;
5 SQL> select name,parameter1,parameter2,parameter3 from v$event_name where name='buffer busy waits';
6 
7 NAME             PARAMETER1 PARAMETER2 PARAMETER3
8 -------------------- ---------- ---------- ----------
9 buffer busy waits    file#    block#       class#
File#：等待访问数据块所在的文件id号。
Blocks：等待访问的数据块号。
ID：在10g以前，这个值表示一个等待事件的缘由，10g以后则表示等待事件的类别。

在下面的示例中，查询的方法和这个同样，因此其余事件对参数的查询将不作过多的说明。

 

二、Buffer latch
    内存中数据块的存放位置是记录在一个hash列表(cache buffer chains)当中的。当一个会话须要访问某个数据块时，它首先要搜索这个hash列表，从列表中得到数据块的地址，而后经过这个地址去访问须要的数据块，这个列表Oracle会使用一个latch来保护它的完整性。当一个会话须要访问这个列表时，须要获取一个latch，只有这样，才能保证这个列表在这个会话的浏览当中不会发生变化。

    产生buffer latch的等待事件的主要缘由是：

        Buffer chains太长，致使会话搜索这个列表花费的时间太长，使其余的会话处于等待状态。

        一样的数据块被频繁访问，就是咱们一般说的热块问题。

    产生buffer chains太长，咱们可使用多个buffer pool的方式来建立更多的buffer chains，或者使用参数DB_BLOCK_LRU_LATCHES来增长Latch的数量，以便于更多的会话能够得到latch，这两种方法能够同时使用。

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

        Latch addr：会话申请的latch在SGA的虚拟地址，经过如下的SQL语句能够根据这个地址找到它对应的Latch名称：

1 SQL> select * from v$latch a,v$latchname b where addr=latch adrr and a.latch#=b.latch#;
备注：这里的latch addr是你从等待事件中看到的值

        chain#：buffer chains hash列表中的索引值，当这个参数的值等于s 0xfffffff时，说明当前的会话正在等待一个LRU latch。

 

3.Control file parallel write

    当数据库中有多个控制文件的拷贝时，Oracle须要保证信息同步地写到各个控制文件当中，这是一个并行的物理操做过程，由于称为控制文件并行写，当发生这样的操做时，就会产生control file parallel write等待事件。

    控制文件频繁写入的缘由不少，好比：

        日志切换太过频繁，致使控制文件信息相应地须要频繁更新。

        系统I/O出现瓶颈，致使全部I/O出现等待。

        当系统出现日志切换过于频繁的情形时，能够考虑适当地增大日志文件的大小来下降日志切换频率。

    当系统出现大量的control file parallel write等待事件时，能够经过好比下降控制文件的拷贝数量，将控制文件的拷贝存放在不一样的物理磁盘上的方式来缓解I/O争用。

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

        Files：Oracle要写入的控制文件个数。

        Blocks：写入控制文件的数据块数目。

        Requests：写入控制请求的I/O次数。

 

四、Control file sequential read

    当数据库须要读取控制文件上的信息时，会出现这个等待事件，由于控制文件的信息是顺序写的，因此读取的时候也是顺序的，所以称为控制文件顺序读，它常常发生在如下状况：

        备份控制文件；

        RAC 环境下不一样实例之间控制文件的信息共享；

        读取控制文件的文件头信息；

        读取控制文件其余信息。

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

        File#：要读取信息的控制文件的文件号。

        Block#：读取控制文件信息的起始数据块号。

        Blocks：须要读取的控制文件数据块数目。

 

五、DB file parallel read

    这是一个很容易引发误导的等待事件，实际上这个等待事件和并行操做(好比并行查询，并行DML)没有关系。这个事件发生在数据库恢复的时候，当有一些数据块须要恢复的时候，Oracle会以并行的方式把他们从数据文件中读入到内存中进行恢复操做。

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

        Files：操做须要读取的文件个数。

        Blocks：操做须要读取的数据块个数。

        Requests：操做须要执行的I/O次数。

 

六、DB file parallel write

    这是一个后台等待事件，它一样和用户的并行操做没有关系，它是由后台进程DBWR产生的，当后台进程DBWR想磁盘上写入脏数据时，会发生这个等待。

    DBWR会批量地将脏数据并行地写入到磁盘上相应的数据文件中，在这个批次做业完成以前，DBWR将出现这个等待事件。若是仅仅是这一个等待事件，对用户的操做并无太大的影响，当伴随着出现free buffer waits等待事件时，说明此时内存中可用的空间不足，这时候会影响到用户的操做，好比影响到用户将脏数据块读入到内存中。

    当出现db file parallel write等待事件时，能够经过启用操做系统的异步I/O的方式来缓解这个等待。当使用异步I/O时，DBWR不在须要一直等到全部数据块所有写入到磁盘上，它只须要等到这个数据写入到一个百分比以后，就能够继续进行后续的操做。

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

        Requests：操做须要执行的I/O次数。

        Timeouts：等待的超时时间。

 

七、DB file scattered read

    这个等待事件在实际生产库中常常能够看到，这是一个用户操做引发的等待事件，当用户发出每次I/O须要读取多个数据块这样的SQL，操做时，会产生这个等待事件，最多见的两种状况是全表扫描(FTS：Full Table Scan)和索引快速扫描(IFFS：index fast full scan)。

    这个名称中的scattered(发散)，可能会致使不少人认为它是以scattered的方式来读取数据块的，其实偏偏相反，当发生这种等待事件时，SQL的操做都是顺序地读取数据块的，好比FTS或者IFFS方式(若是忽略须要读取的数据块已经存在内存中的状况)。

    这里的scattered指的是读取的数据块在内存中的存放方式，他们被读取到内存中后，是以分散的方式存在在内存中，而不是连续的。

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

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

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

        Blocks：须要读取的数据块数目。

 

八、DB file sequential read

     这个等待事件在实际生产库也很常见，当Oracle须要每次I/O只读取当个数据块这样的操做时，会产生这个等待事件。最多见的状况是索引的访问(除IFFS外的方式)，回滚操做，以ROWID的方式访问表中的数据，重建控制文件，对文件头作DUMP等。

     这里的sequential也并不是指的是Oracle按顺序的方式来访问数据，和db file scattered read同样，它指的是读取的数据块在内存中是以连续的方式存放的。

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

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

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

        Blocks：要读取的数据块数目(这里应该等于1)。

 

九、DB file single write

    这个等待事件一般只发生在一种状况下，就是Oracle更新数据文件头信息时(好比发生Checkpoint)。

    当这个等待事件很明显时，须要考虑是否是数据库中的数据文件数量太大，致使Oracle，须要花较长的时间来作全部文件头的更新操做(checkpoint)。

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

        File#：须要更新的数据块所在的数据文件的文件号。

        Block#：须要更新的数据块号。

        Blocks：须要更新的数据块数目(一般来讲应该等于1)。

 

十、Direct path read

    这个等待事件发生在会话将数据块直接读取到PGA当中而不是SGA中的状况，这些被读取的数据一般是这个会话私有的数据，因此不须要放到SGA做为共享数据，由于这样作没有意义。这些数据一般是来自与临时段上的数据，好比一个会话中SQL的排序数据，并行执行过程当中间产生的数据，以及Hash Join，merge join产生的排序数据，由于这些数据只对当前的会话的SQL操做有意义，因此不须要放到SGA当中。

    当发生direct path read等待事件时，意味着磁盘上有大量的临时数据产生，好比排序，并行执行等操做。或者意味着PGA中空闲空间不足。

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

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

        First dba：descriptor addres中最旧的一个I/O数据块地址。

        Block cnt：descriptor address上下文中涉及的有效的buffer数量。

 

十一、Direct path write

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

    这种状况一般发生在：

        a.使用临时表空间排序(内存不足)；

        b.数据的直接加载(使用append方式加载数据)；

        c.并行DML操做。

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

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

        First dba：descriptor address中最旧的一个I/O数据块地址。

        Block cnt：descriptor address上下文中涉及的有效地buffer数量。

 

十二、Enqueue

    Enqueue这个词实际上是lock的另外一种描述语。

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

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

        Name：enqueue的名称和类型。

        Mode：enqueue的模式。

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

1 SQL> select chr (to_char (bitand (p1,-1677216)) / 1677215) || chr (to_char (bitand (p1,16711680)) / 65535) "Lock",
2   2    to_char (bitand (p1,65535)) "Mode"
3   3   from v$session_wait
4   4  where event = 'enqueue';

    Oracle的enqueue包含如下模式：

    关于enqueue的详细内容能够查看以前写的： 《Oracle Lock(Enqueues)》

 

1三、Free buffer waits

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

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

        (1)、data buffer过小，致使空闲空间不够；

        (2)、内存中的脏数据太多，DBWR没法及时将这些脏数据写到磁盘中以释放空间。

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

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

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

 

1四、Latch free

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

 1 SQL> col name for a60;
 2 SQL> select name from v$event_name where name like 'latch%' order by 1;
 3 
 4 NAME
 5 ------------------------------------------------------------
 6 latch activity
 7 latch free
 8 latch: Change Notification Hash table latch
 9 latch: In memory undo latch
10 latch: MQL Tracking Latch
11 latch: PX hash array latch
12 latch: Undo Hint Latch
13 latch: WCR: processes HT
14 latch: WCR: sync
15 latch: cache buffer handles
16 latch: cache buffers chains
17 
18 NAME
19 ------------------------------------------------------------
20 latch: cache buffers lru chain
21 latch: call allocation
22 latch: change notification client cache latch
23 latch: checkpoint queue latch
24 latch: enqueue hash chains
25 latch: gc element
26 latch: gcs resource hash
27 latch: ges resource hash list
28 latch: lob segment dispenser latch
29 latch: lob segment hash table latch
30 latch: lob segment query latch
31 
32 NAME
33 ------------------------------------------------------------
34 latch: messages
35 latch: object queue header operation
36 latch: parallel query alloc buffer
37 latch: redo allocation
38 latch: redo copy
39 latch: redo writing
40 latch: row cache objects
41 latch: session allocation
42 latch: shared pool
43 latch: undo global data
44 latch: virtual circuit queues
45 
46 33 rows selected.

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

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

        Address：会话等待的latch地址。

        Number：latch号，经过这个号，能够从v$latchname视图中找到这个latch的相关的信息。

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

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

 

1五、Library cache lock

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

    这个事件包含四个参数：

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

        Lock address：锁的地址。

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

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

 

1六、Library cache pin

    这个等待事件和library cache lock同样是发生在共享池中并发操做引发的事件。一般来说，若是Oracle要对一些PL/SQL或者视图这样的对象作从新编译，须要将这些对象pin到共享池中。若是此时这个对象被其余的用户特有，就会产生一个library cache pin的等待。

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

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

        Lock address：锁的地址。

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

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

 

1七、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次数。

 

1八、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性能。

 

1九、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：写入的数据块个数。

 

2一、Log file switch（archiving needed）

    在归档模式下，这个等待事件发生在在线日志切换(log file switch)时，须要切换的在线日志尚未被归档进程(ARCH)归档完毕的时候。当在线日志文件切换到下一个日志时，须要确保下一个日志文件已经被归档进程归档完毕，不然不容许覆盖那个在线日志信息(不然会致使归档日志信息不完整)。

    出现这样的等待事件一般是因为某种缘由致使ARCH进程死掉，好比ARCH进程尝试向目的地写入一个归档文件，可是没有成功(介质失效或者其余缘由)，这时ARCH进程就会死掉。若是发生这种状况，在数据库的alert log文件中能够找到相关的错误信息。

    这个等待事件没有参数。

 

2二、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)等待事件，缘由多是日志文件过小或者日志组太少，因此解决的方法是，增长日志文件的大小或者增长日志组的数量。

    这个等待事件没有参数。

 

2三、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。

 

2四、SQL*Net break/reset to client

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

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

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

        Break?：零表示服务端向客户端发送一个重置(reset)信息，非零表示服务器端向客户端发送一个断开(break)消息。

 

2五、SQL*Net break/reset to dblink

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

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

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

        Break?：零表示服务端向客户端发送一个重置(reset)信息，非零表示服务端向客户端发送一个断开(break)消息。

 

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

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

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

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