调优实践01–Oracle常见的等待事件及解决方案

Posted on by
Oracle常见的等待事件及解决方案
  1. 等待事件的相关知识:
    1. 等待事件主要可以分为两类,即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件;
      1. 空闲等待事件指ORACLE正等待某种工作,在诊断和优化数据库的时候,不用过多注意这部分事件;
      2. 非空闲等待事件专门针对ORACLE的活动,指数据库任务或应用运行过程中发生的等待,这些等待事件是在调整数据库的时候需要关注与研究的;
      3. 在Oracle 10g中的等待事件有872个,11gR2中等待事件1152个;可以通过v$event_name视图来查看等待事件的相关信息;
    2. 查看等待事件的总个数:SELECT COUNT(*) FROM v$event_name;
    3. 查看等待事件每个分类的分布:SELECT wait_class#, wait_class_id, wait_class, COUNT(*) FROM v$event_name GROUP BY wait_class#, wait_class_id, wait_class ORDER BY wait_class#;                                                                                                        
    4. 相关的视图:
      1. V$SESSION:连接到数据库的会话信息;
      2. V$SESSION_WAIT:当前会话正在等待的资源,此视图已经与v$session视图合并了;
      3. V$SESSION_WAIT_HISTORY:是对V$SESSION_WAIT的简单增强,记录活动SESSION的最近10次等待;
      4. V$SYSTEM_EVENT:由于V$SESSION记录的是动态信息,和SESSION的生命周期相关,而并不记录历史信息,所以ORACLE提供视图V$SYSTEM_EVENT来记录数据库自启动以来所有等待事件的汇总信息;通过这个视图,用户可以迅速获得数据库运行的总体概况;
      5. V$SQL:查看某个session正在执行的sql语句(SELECT t1.sid, t2.sql_text FROM v$session t1 INNER JOIN v$sql t2 ON t1.sql_id = t2.sql_id;SELECT t1.sid, t2.sql_text FROM v$session t1 INNER JOIN v$sql t2 ON t1.sql_address = t2.address;);
      6. V$ACTIVE_SESSION_HISTORY:是ASH的核心,用以记录活动SESSION的历史等待信息,每秒采样一次,这部分内容记录在内存中,记录一个小时的内容;
      7. DBA_HIST_ACTIVE_SESS_HISTORY:通过这个视图进行ASH历史数据的访问;
    5. 可以从v$event_name视图中查看等待事件的类型(SELECT NAME, parameter1, parameter2, parameter3 FROM v$event_name;),v$session中P1-3表示等待的资源是什么;
  2. buffer busy waits:
    1. 从本质上讲,这个等待事件的产生仅说明了一个会话在等待一个Buffer(数据块),但是导致这个现象的原因却有很多种,常见的两种是:
      1. 当一个会话试图修改一个数据块,但这个数据块正在被另一个会话修改时;
      2. 当一个会话需要读取一个数据块,但这个数据块正在被另一个会话读取到内存中时;
    2. Oracle操作的最小单位是块(Block),即使你要修改一条记录,也需要对这条记录所在的这个数据块做操作;当你对这个数据块做修改时,其他的会话将被阻止对这个数据块上的数据做修改(即使其他用户修改的不是当前用户修改的数据),但是可以以一致性的方式读取这个数据块(使用UNDO构建CR块);当前的用户修改完这个数据块后,将会立即释放掉加在这个数据块上的排他锁,这样另一个会话就可以继续修改它;修改操作是一个非常短暂的时间,这种加锁的机制我们叫Latch;
    3. 当一个会话修改一个数据块时,是按照以下步骤来完成的:
      1. 以排他的方式获得这个数据块(Latch);
      2. 修改这个数据块;
      3. 释放Latch;
    4. Buffer busy waits等待事件常见于数据库中存在的热快的时候,当多个用户频繁地读取或者修改同样的数据块时,这个等待事件就会产生;如果等待的时间很长,我们在AWR或者statspack报告中就可以看到;
    5. 解决办法:
      1. 如果等待处于字段头部,应增加自由列(freelist)的组数,或者增加pctused到pctfree之间的距离;
      2. 如果等待处于回退段(undo)头部块,可以通过增加回滚段(rollback segment)来解决缓冲区的问题;
      3. 如果等待处于回退段(undo)非头部块上,就需要降低驱动一致读取的表中的数据密度,或者增大DB_CACHE_SIZE;
      4. 如果等待处于数据块,可以将数据移到另一数据块以避开这个”热”数据块,增加表中的自由列表或使用LMT表空间;
      5. 如果等待处于索引块,应该重建索引,分割索引或使用反向键索引;
    6. 等待事件的参数:
      1. File#:等待访问数据块所在的文件id号;
      2. Blocks:等待访问的数据块号;
  3. db file scattered read:
    1. 这是一个用户操作引起的等待事件,当用户发出每次I/O需要读取多个数据块这样的SQL操作时,会产生这个等待事件,最常见的两种情况是:
      1. 全表扫描(FTS: Full Table Scan);
      2. 索引快速扫描(IFFS: index fast full scan);
    2. 这个名称中的scattered(离散),可能会导致很多人认为它是以scattered的方式来读取数据块的,其实恰恰相反,当发生这种等待事件时,SQL的操作都是顺序地读取数据块的,比如FTS或者IFFS方式(如果忽略需要读取的数据块已经存在内存中的情况);
    3. 这里的scattered指的是读取的数据块在内存中的存放方式,它们被读取到内存中后,是以分散的方式存在在内存中,而不是连续的;
    4. 等待事件的参数:
      1. File#: 要读取的数据块所在数据文件的文件号;
      2. Block#: 要读取的起始数据块号;
      3. Blocks:需要读取的数据块数目;
  4. db file sequential read:
    1. 当Oracle需要每次I/O只读取单个数据块这样的操作时,会产生这个等待事件,最常见的情况:
      1. 索引的访问(除IFFS外的方式);
      2. 回滚操作;
      3. 以ROWID的方式访问表中的数据;
      4. 重建控制文件;
      5. 对文件头做DUMP等;
    2. 这里的sequential也并非指的是Oracle按顺序的方式来访问数据,和db file scattered read一样,它指的是读取的数据块在内存中是以连续的方式存放的;
    3. 等待事件的参数:
      1. File#:要读取的数据块锁在数据文件的文件号;
      2. Block#:要读取的起始数据块号;
      3. Blocks:要读取的数据块数目(这里应该等于1);
    4. 查找热点快的方法:SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id = &file_id AND &block_id BETWEEN block_id AND block_id + &blocks – 1;
  5. buffer latch:
    1. 内存中数据块的存放位置是记录在一个hash列表(cache buffer chains)当中的;当一个会话需要访问某个数据块时,它首先要搜索这个hash列表,从列表中获得数据块的地址,然后通过这个地址去访问需要的数据块,这个列表Oracle会使用一个latch来保护它的完整性;当一个会话需要访问这个列表时,需要获取一个Latch,只有这样,才能保证这个列表在这个会话的浏览当中不会发生变化;
    2. 产生buffer latch的等待事件的主要原因是:
      1. Buffer chains太长,导致会话搜索这个列表花费的时间太长,使其他的会话处于等待状态;
      2. 同样的数据块被频繁访问,就是我们通常说的热快问题;
    3. 解决办法:产生buffer chains太长,我们可以使用多个buffer pool的方式来创建更多的buffer chains,或者使用参数DB_BLOCK_LRU_LATCHES来增加latch的数量,以便于更多的会话可以获得latch,这两种方法可以同时使用;
    4. 等待事件的参数:
      1. Latch addr:会话申请的latch在SGA中的虚拟地址,通过以下的SQL语句可以根据这个地址找到它对应的Latch名称(SELECT * FROM v$latch a, v$latchname b WHERE a.addr = <latch addr> AND a.latch# = b.latch#;);
      2. chain#:buffer chains hash列表中的索引值,当这个参数的值等于0xfffffff时,说明当前的会话正在等待一个LRU latch;
  6. control file parallel write:
    1. 当数据库中有多个控制文件的拷贝时,Oracle需要保证信息同步地写到各个控制文件当中,这是一个并行的物理操作过程,因为称为控制文件并行写,当发生这样的操作时,就会产生control file parallel write等待事件;
    2. 控制文件频繁写入的主要原因:
      1. 日志切换太过频繁,导致控制文件信息相应地需要频繁更新;
      2. 系统I/O出现瓶颈,导致所有I/O出现等待;
    3. 解决办法:
      1. 当系统出现日志切换过于频繁的情形时,可以考虑适当地增大日志文件的大小来降低日志切换频率;
      2. 当系统出现大量的control file parallel write 等待事件时,可以通过比如降低控制文件的拷贝数量,将控制文件的拷贝存放在不同的物理磁盘上的方式来缓解I/O争用;
    4. 等待事件的参数:
      1. Files:Oracle要写入的控制文件个数;
      2. Blocks:写入控制文件的数据块数目;
      3. Requests:写入控制请求的I/O次数;
  7. control file sequential read:
    1. 当数据库需要读取控制文件上的信息时,会出现这个等待事件,因为控制文件的信息是顺序写的,所以读取的时候也是顺序的,因此称为控制文件顺序读;
    2. 控制文件频繁读取的主要原因:
      1. 备份控制文件;
      2. RAC环境下不同实例之间控制文件的信息共享;
      3. 读取控制文件的文件头信息;
      4. 读取控制文件其他信息;
    3. 等待事件的参数:
      1. File#:要读取信息的控制文件的文件号;
      2. Block#:读取控制文件信息的起始数据块号;
      3. Blocks:需要读取的控制文件数据块数目;
  8. db file parallel read:
    1. 这是一个很容易引起误导的等待事件,实际上这个等待事件和并行操作(比如并行查询,并行DML)没有关系;这个事件发生在数据库恢复的时候,当有一些数据块需要恢复的时候,Oracle会以并行的方式把他们从数据文件中读入到内存中进行恢复操作;
    2. 等待事件的参数:
      1. Files:操作需要读取的文件个数;
      2. Blocks:操作需要读取的数据块个数;
      3. Requests:操作需要执行的I/O次数;
  9. db file parallel write:
    1. 这是一个后台等待事件,它同样和用户的并行操作没有关系,它是由后台进程DBWR产生的,当后台进程DBWR想磁盘上写入脏数据时,会发生这个等待;
    2. DBWR会批量地将脏数据并行地写入到磁盘上相应的数据文件中,在这个批次作业完成之前,DBWR将出现这个等待事件;如果仅仅是这一个等待事件,对用户的操作并没有太大的影响,当伴随着出现free buffer waits等待事件时,说明此时内存中可用的空间不足,这时候会影响到用户的操作,比如影响到用户将脏数据块读入到内存中;
    3. 当出现db file parallel write等待事件时,可以通过启用操作系统的异步I/O的方式来缓解这个等待;当使用异步I/O时,DBWR不在需要一直等到所有数据块全部写入到磁盘上,它只需要等到这个数据写入到一个百分比之后,就可以继续进行后续的操作;
    4. 等待事件的参数:
      1. Requests:操作需要执行的I/O次数;
      2. Timeouts:等待的超时时间;
  10. Db file single write:
    1. 这个等待事件通常只发生在一种情况下,就是Oracle更新数据文件头信息时(比如发生Checkpoint);
    2. 当这个等待事件很明显时,需要考虑是不是数据库中的数据文件数量太大,导致Oracle需要花较长的时间来做所有文件头的更新操作(checkpoint);
    3. 等待事件的参数:
      1. File#:需要更新的数据块所在的数据文件的文件号;
      2. Block#:需要更新的数据块号;
      3. Blocks:需要更新的数据块数目(通常来说应该等于1);
  11. direct path read:
    1. 这个等待事件发生在会话将数据块直接读取到PGA当中而不是SGA中的情况,这些被读取的数据通常是这个会话私有的数据,所以不需要放到SGA作为共享数据,因为这样做没有意义;这些数据通常是来自与临时段上的数据,比如一个会话中SQL的排序数据,并行执行过程中间产生的数据,以及Hash Join,merge join产生的排序数据,因为这些数据只对当前的会话的SQL操作有意义,所以不需要放到SGA当中;
    2. 当发生direct path read等待事件时,意味着磁盘上有大量的临时数据产生,比如排序,并行执行等操作;或者意味着PGA中空闲空间不足;
    3. 等待事件的参数:
      1. Descriptor address:一个指针,指向当前会话正在等待的一个direct read I/O;
      2. First dba:descriptor address中最旧的一个I/O数据块地址;
      3. Block cnt:descriptor address上下文中涉及的有效的buffer数量;
  12. direct path write:
    1. 这个等待事件和direct path read正好相反,是会话将一些数据从PGA中直接写入到磁盘文件上,而不经过SGA;
      1. 使用临时表空间排序(内存不足);
      2. 数据的直接加载(使用append方式加载数据);
      3. 并行DML操作;
    2. 等待事件的参数:
      1. Descriptor address:一个指针,指向当前会话正在等待的一个direct read I/O;
      2. First dba:descriptor address中最旧的一个I/O数据块地址;
      3. Block cnt:descriptor address上下文中涉及的有效的buffer数量;
  13. enqueue:
    1. Enqueue这个词其实是lock的另一种描述语;
    2. 当我们在AWR报告中发现长时间的enqueue等待事件时,说明数据库中出现了阻塞和等待,可以关联AWR报告中的enqueue activity部分来确定是哪一种锁定出现了长时间等待;
    3. 等待事件的参数:
      1. Name:enqueue的名称和类型;
      2. Mode:enqueue的模式;
    4. 查看当前会话等待的enqueue名称和类型: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’;
    5. 模式代码及解释:
      1. 1-Null mode
      2. 2-Sub-Share
      3. 3-Sub-Exclusive
      4. 4-Share
      5. 5-Share/Sub-Exclusive
      6. 6-Exclusive
    6. Enqueue的缩写及解释;
  14. free buffer waits:
    1. 当一个会话将数据块从磁盘读到内存中时,它需要到内存中找到空闲的内存空间来存放这些数据块,当内存中没有空闲的空间时,就会产生这个等待;除此之外,还有一种情况就是会话在做一致性读时,需要构造数据块在某个时刻的前映像(image),此时需要申请内存来存放这些新构造的数据块,如果内存中无法找到这样的内存块,也会发生这个等待事件;
    2. 当数据库中出现比较严重的free buffer waits等待事件时,可能的原因是:
      1. Data buffer太小,导致内存空间不够;
      2. 内存中的脏数据太多,DBWR无法及时将这些脏数据写到磁盘中以释放空间
    3. 解决办法:
      1. 加大db_buffer_cache大小;
      2. 增加dbwr进程数量;
      3. 增加检查点或者物理磁盘的数量;
    4. 等待事件的参数:
      1. File#:需要读取的数据块所在的数据文件的文件号;
      2. Block#:需要读取的数据块块号;
  15. latch free:
    1. 在10g之前的版本里,latch free等待事件代表了所有的latch等待,在10g以后,一些常用的latch事件已经被独立了出来:所以latch free等待事件在10g以后的版本中并不常见,而是以具体的Latch等待事件出现;
    2. latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构;latch就像是一种快速地被获取和释放的内存锁;latch用于防止共享内存结构被多个用户同时访问;如果latch不可用,就会记录latch释放失败;大多数latch 问题都与以下操作相关:
      1. 不能使用邦定变量(库缓存latch);
      2. 重复生成问题(重复分配latch);
      3. 缓冲存储器竞争问题(缓冲器存储LRU 链),以及缓冲存储器中的”热”块(缓冲存储器链);
      4. 也有一些latch等待与bug(程序错误)有关;
    3. 查看latch相关的等待事件:SELECT NAME FROM v$event_name WHERE NAME LIKE ‘latch%’;
    4. 查找事件热点对象的sql语句;
    5. latch问题的解决办法:
      1. Library Cache and Shared Pool(未绑定变量—绑定变量,调整shared_pool_size):每当执行SQL或PL/SQL存储过程,包,函数和触发器时,这个Latch即被用到.Parse操作中此Latch也会被频繁使用;
      2. Redo Copy(增大_LOG_SIMULTANEOUS_COPIES参数):重做拷贝Latch用来从PGA向重做日志缓冲区拷贝重做记录;
      3. Redo Allocation(最小化REDO生成,避免不必要提交):此Latch用来分配重做日志缓冲区中的空间,可以用NOLOGGING来减缓竞争;
      4. Row Cache Objects(增大共享池):数据字典竞争,过度parsing;
      5. Cache Buffers Chains(_DB_BLOCK_HASH_BUCKETS应增大或设为质数):”过热”数据块造成了内存缓冲链Latch竞争;
      6. Cache Buffers Lru Chain(调整SQL,设置DB_BLOCK_LRU_LATCHES,或使用多个缓冲区池):扫描全部内存缓冲区块的LRU(最近最少使用)链时要用到内存缓冲区LRU链Latch;太小内存缓冲区,过大的内存缓冲区吞吐量,过多的内存中进行的排序操作,DBWR速度跟不上工作负载等会引起此Latch竞争;
    6. 等待事件的参数:
      1. Address:会话等待的latch地址;
      2. Number:latch号,通过这个号,可以从v$latchname视图中找到这个latch的相关的信息(SELECT * FROM v$latchname WHERE latch# = NUMBER;);
      3. Tries:会话尝试获取Latch的次数;
  16. library cache lock:
    1. 这个等待时间发生在不同用户在共享中由于并发操作同一个数据库对象导致的资源争用的时候,比如当一个用户正在对一个表做DDL操作时,其他的用户如果要访问这张表,就会发生library cache lock等待事件,它要一直等到DDL操作完成后,才能继续操作;
    2. 该事件通常是由于执行多个DDL操作导致的,即在library cache object上添加一个排它锁后,又从另一个会话给它添加一个排它锁,这样在第二个会话就会生成等待;可通过到基表x$kgllk中查找其对应的对象;
    3. 查询引起该等待事件的阻塞者的sid,会话用户,锁住的对象的脚本;
    4. 等待事件的参数:
      1. Handle address:被加载的对象的地址;
      2. Lock address:锁的地址;
      3. Mode:被加载对象的数据片段;
      4. Namespace:被加载对象在v$db_object_cache视图中namespace名称;
  17. Library cache pin
    1. 这个等待事件和library cache lock一样是发生在共享池中并发操作引起的事件;通常来讲,如果Oracle要对一些PL/SQL或者视图这样的对象做重新编译,需要将这些对象pin到共享池中;如果此时这个对象被其他的用户特有,就会产生一个library cache pin的等待;
    2. P1,P2可与x$kglpn和x$kglob表相关:
      1. X$KGLOB (Kernel Generic Library Cache Manager Object);
      2. X$KGLPN (Kernel Generic Library Cache Manager Object Pins);
    3. 相关锁的查询sql;
    4. 等待事件的参数:
      1. Handle address:被加载的对象的地址;
      2. Lock address:锁的地址;
      3. Mode:被加载对象的数据片段;
      4. Namespace:被加载对象在v$db_object_cache视图中namespace名称;
  18. log file parallel write:
    1. 后台进程LGWR负责将log buffer当中的数据写到REDO文件中,以重用log buffer的数据;如果每个REDO LOG组里面有2个以上的成员,那么LGWR进程会并行地将REDO信息写入这些文件中;
    2. 如果数据库中出现这个等待事件的瓶颈,主要的原因可能是磁盘I/O性能不够或者REDO文件的分布导致了I/O争用,比如同一个组的REDO成员文件放在相同的磁盘上;
    3. 等待事件的参数:
      1. Files:操作需要写入的文件个数;
      2. Blocks:操作需要写入的数据块个数;
      3. Requests:操作需要执行的I/O次数;
  19. log buffer space:
    1. 当log buffer中没有可用空间来存放新产生的redo log数据时,就会发生log buffer space等待事件;如果数据库中新产生的redo log的数量大于LGWR写入到磁盘中的redo log数量,必须等待LGWR完成写入磁盘的操作,LGWR必须确保redo log写到磁盘成功之后,才能在redo buffer当中重用这部分信息;
    2. 如果数据库中出现大量的log buffer space等待事件,可以考虑如下方法:
      1. 增加redo buffer的大小;
      2. 提升磁盘的I/O性能;
  20. log file sequential read:
    1. 这个等待事件通常发生在对redo log信息进行读取时,比如在线redo的归档操作,ARCH进程需要读取redo log的信息,由于redo log的信息是顺序写入的,所以在读取时也是按照顺序的方式来读取的;
    2. 等待事件的参数:
      1. Log#:发生等待时读取的redo log的sequence号;
      2. Block#:读取的数据块号;
      3. Blocks:读取的数据块个数;
  21. log file single write:
    1. 这个等待事件发生在更新redo log文件的文件头时,当为日志组增加新的日志成员时或者redo log的sequence号改变时,LGWR都会更新redo log文件头信息;
    2. 等待事件的参数:
      1. Log#:发生等待时读取的redo log的sequence号;
      2. Block#:读取的数据块号;
      3. Blocks:读取的数据块个数;
  22. log file switch(archiving needed):
    1. 在归档模式下,这个等待事件发生在在线日志切换(log file switch)时,需要切换的在线日志还没有被归档进程(ARCH)归档完毕的时候;当在线日志文件切换到下一个日志时,需要确保下一个日志文件已经被归档进程归档完毕,否则不允许覆盖那个在线日志信息(否则会导致归档日志信息不完整);
    2. 出现这样的等待事件通常是由于某种原因导致ARCH进程死掉,比如ARCH进程尝试向目的地写入一个归档文件,但是没有成功(介质失效或者其他原因),这时ARCH进程就会死掉;如果发生这种情况,在数据库的alert log文件中可以找到相关的错误信息;
  23. log file switch(checkpoint incomplete):
    1. 当一个在线日志切换到下一个在线日志时,必须保证要切换到的在线日志上的记录的信息(比如一些脏数据块产生的redo log)被写到磁盘上(checkpoint),这样做的原因是,如果一个在线日志文件的信息被覆盖,而依赖这些redo信息做恢复的数据块尚未被写到磁盘上(checkpoint),此时系统down掉的话,Oracle将没有办法进行实例恢复;
    2. 在v$log视图里记录了在线日志的状态,在线日志有三种状态:
      1. Active:这个日志上面保护的信息还没有完成checkpoint;
      2. Inactive:这个日志上面保护的信息已完成checkpoint;
      3. Current:当前的日志;
    3. Oracle在做实例恢复时,会使用状态为current和Active的日志进行实例恢复;
    4. 如果系统中出现大量的log file switch(checkpoint incomplete)等待事件,原因可能是日志文件太小或者日志组太少,所以解决的方法是,增加日志文件的大小或者增加日志组的数量;
  24. log file sync:
    1. 这是一个用户会话行为导致的等待事件,当一个会话发出一个commit命令时,LGWR进程会将这个事务产生的redo log从log buffer里面写到磁盘上,以确保用户提交的信息被安全地记录到数据库中;会话发出的commit指令后,需要等待LGWR将这个事务产生的redo成功写入到磁盘之后,才可以继续进行后续的操作,这个等待事件就叫作log file sync;
    2. 当系统中出现大量的log file sync等待事件时,应该检查数据库中是否有用户在做频繁的提交操作;
    3. 这种等待事件通常发生在OLTP系统上,OLTP系统中存在很多小的事务,如果这些事务频繁被提交,可能引起大量的log file sync的等待事件;
    4. 等待事件的参数:
      1. Buffer#:redo buffer中需要被写入到磁盘中的buffer;
  25. SQL*Net相关的等待事件:
    1. SQL*Net break/reset to client:当出现这个等待事件时,说明服务器端在给客户端发送一个断开连接或者重置连接的请求,正在等待客户的响应,通常的原因是服务器到客户端的网络不稳定导致的;
    2. SQL*Net break/reset to dblink:这个等待事件和SQL*Net break/reset to client相同;不过它表示的是数据库通过dblink访问另一台数据库时,他们之间建立起一个会话,这个等待事件发生在这个会话之间的通信过程中,同样如果出现这个等待事件,需要检查两台数据库之间的通信问题;
    3. SQL*Net message from client:这个等待事件基本上是最常见的一个等待事件;当一个会话建立成功后,客户端会向服务器端发送请求,服务器端处理完客户端请求后,将结果返回给客户端,并继续等待客户端的请求,这时候会产生SQL*Net message from client 等待事件;很显然,这是一个空闲等待,如果客户端不再向服务器端发送请求,服务器端将一直处于这个等待事件状态;
    4. SQL*Net message from dblink:这个等待事件和SQL*Net message from client相同,不过它表示的是数据库通过dblink 访问另一个数据库时,他们之间会建立一个会话,这个等待事件发生在这个会话之间的通信过程中;这个等待事件也是一个空闲等待事件;
    5. SQL*Net message to client:这个等待事件发生在服务器端向客户端发送消息的时候; 当服务器端向客户端发送消息产生等待时,可能的原因是用户端太繁忙,无法及时接收服务器端送来的消息,也可能是网络问题导致消息无法从服务器端发送到客户端;
    6. SQL*Net message to dblink:这个等待事件和SQL*Net message to client相同,不过是发生在数据库服务器和服务器之间的等待事件,产生这个等待的原因可能是远程服务器繁忙,而无法及时接收发送过来的消息,也可能是服务器之间网络问题导致消息无法发送过来;
    7. SQL*Net more data from client:服务器端等待用户发出更多的数据以便完成操作,比如一个大的SQL文本,导致一个SQL*Net 数据包无法完成传输,这样服务器端会等待客户端把整个SQL 文本发过来在做处理,这时候就会产生一个SQL*Net more data from client等待事件;
    8. SQL*Net more data from dblink:在一个分布式事务中,SQL 分布在不同的数据库中执行,远程数据库执行完毕后将结果通过dblink返给发出SQL的数据库,在等待数据从其他数据库中通过dblink传回的过程中,如果数据在远程数据库上处理时间很久,或者有大量的结果集需要返回,或者网络性能问题都会产生SQL*Net more data from dblink 等待事件,它的意思是本地数据库需要等到所有的数据从远程处理完毕通过dblink传回后,才可以在本机继续执行操作;
    9. SQL*Net more data to client:当服务器端有太多的数据需要发给客户端时,可能会产生SQL*Net more data to client等待事件,也可能由于网络问题导致服务器无法及时地将信息或者处理结果发送给客户端,同样会产生这个等待;
    10. SQL*Net more data to dblink:这个等待事件和SQL*Net more data to client 等待时间基本相同,只不过等待发生在分布式事务中,即本地数据库需要将更多的数据通过dblink发送给远程数据库;由于发送的数据太多或者网络性能问题,就会出现SQL*Net more data to dblink等待事件;
    11. 它们的等待事件参数一致:
      1. Driver id:服务器端和客户端连接使用的协议信息;
      2. #bytes:服务器端通过dblink发送给另一个服务器消息的字节数;
———————- latch free:查找事件热点对象的sql语句 ———————-
&2值是v$session_wait中的P1RAW,x$bh中的字段Hladdr表示该block buffer在哪个cache buffer chain latch上,可以通过v$latch_children定位哪些segment是热点块;
SELECT a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name
FROM x$bh a, dba_objects b
WHERE (a.obj = b.object_id OR a.obj = b.data_object_id) AND
a.hladdr = &2
UNION
SELECT hladdr, file#, dbablk, tch, obj, NULL
FROM x$bh
WHERE obj IN (SELECT obj
FROM x$bh
WHERE hladdr = &2
MINUS
SELECT object_id
FROM dba_objects
MINUS
SELECT data_object_id FROM dba_objects) AND
hladdr = &2
ORDER BY 4;
———————- latch free:查找事件热点对象的sql语句 ———————-
———————- 查询引起library cache lock等待事件的阻塞者的sid,会话用户,锁住的对象的脚本 ———————-
SELECT b.sid, a.user_name, a.kglnaobj
FROM x$kgllk a, v$session b
WHERE a.kgllkhdl IN (SELECT p1raw
FROM v$session_wait
WHERE wait_time = 0 AND
event = ‘library cache lock’) AND
a.kgllkmod <> 0 AND
b.saddr = a.kgllkuse;
———————- 查询引起library cache lock等待事件的阻塞者的sid,会话用户,锁住的对象的脚本 ———————-
———————- library cache lock等待事件相关锁的查询sql ———————-
— 查询X$KGLOB,可找到相关的object,其SQL语句如下(即把V$SESSION_WAIT中的P1raw与X$KGLOB中的KGLHDADR相关连);
SELECT kglnaown, kglnaobj
FROM x$kglob
WHERE kglhdadr = (SELECT p1raw FROM v$session_wait WHERE event = ‘library cache pin’);
— 查出引起该等待事件的阻塞者的sid;
SELECT sid
FROM x$kglpn, v$session
WHERE kglpnhdl IN (SELECT p1raw
FROM v$session_wait
WHERE wait_time = 0 AND
event LIKE ‘library cache pin%’) AND
kglpnmod <> 0 AND
v$session.saddr = x$kglpn.kglpnuse;
— 查出阻塞者正执行的SQL语句
SELECT sid, sql_text
FROM v$session, v$sqlarea
WHERE v$session.sql_address = v$sqlarea.address AND
sid = < 阻塞者的sid >;
———————- library cache lock等待事件相关锁的查询sql ———————-
———————- Enqueue缩写及解释 ———————-
BL:Buffer Cache management
BR:Backup/Restore
CF:Controlfile transaction
CI:Cross-instance Call Invocation
CU:Bind Enqueue
DF:Datafile
DL:Direct Loader Index Creation
DM:Database Mount
DR:Distributed Recovery Process
DX:Dirstributed Transaction
FP:File Object
FS:File Set
HW:High-water Lock
IN:Instance Number
IR:Instance Recovery
IS:Instance State
IV:Library Cache Invalidation
JI:Enqueue used during AJV snapshot refresh
JQ:Job Queue
KK:Redo Log “Kick”
KO:Multiple Object Checkpoint
L[A-p]:Library Cache Lock
LS:Log start or switch
MM:Mount Definition
MR:Media recovery
N[A-Z]:Library Cache bin
PE:Alter system set parameter =value
PF:Password file
PI:Parallel slaves
PR:Process startup
PS:Parallel slave synchronization
Q[A-Z]:Row Cache
RO:Object Reuse
RT:Redo Thread
RW:Row Wait
SC:System Commit Number
SM:SMON
SN:Sequence Number
SQ:Sequence Number Enqueue
SR:Synchronized replication
SS:Sort segment
ST:Space management transaction
SV:Sequence number Value
TA:Transaction recovery
TC:Thread Checkpoint
TE:Extend Table
TM:DML enqueue
TO:Temporary Table Object Enqueue
TS:Temporary Segement(also TableSpace)
TT:Temporary Table
TX:Transaction
UL:User-defined Locks
UN:User name
US:Undo segment, Serialization
WL:Being Written Redo Log
XA:Instance Attribute Log
XI:Instance Registration Lock
———————- Enqueue缩写及解释 ———————-