ITPub博客

首页 > Linux操作系统 > Linux操作系统 > top5 events

top5 events

原创 Linux操作系统 作者:cc59 时间:2006-07-08 00:00:00 0 删除 编辑


查看Statspack报告中的"5个顶级等待事件"部分。报告的这一部分给出了前5个顶级等待事件、等待事件的完整列表和后台等待事件。如果系统的TEMED_STATISTICS初始化参数被设为"true",这些事件是按其等待时间进行排序的。这种排序是较好的排序方式,因为并不是所有的事件都显示等待。如果TIMED_STATISTICS被设为"false",这些事件就按等待数目进行排序。

下面是导致等待事件的10个最常见原因,以及对事件的解释和可能的解决方案:

1. DB文件分散读取。这种情况通常显示与全表扫描相关的等待。当全表扫描被限制在内存时,它们很少会进入连续的缓冲区内,而是分散于整个缓冲存储器中。如果这个数目很大,就表明该表找不到索引,或者只能找到有限的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效,但如果出现这种等待时,最好检查一下这些全表扫描是否必要。因为全表扫描被置于LRULeast Recently Used,最近最少使用)列表的冷端(cold end),所以应尽量存储较小的表,以避免一次又一次地重复读取它们。

2. DB文件顺序读取。这一事件通常显示单个块的读取(如索引读取)。这种等待的数目很多时,可能显示表的连接顺序不佳,或者不加选择地进行索引。对于高级事务处理(high-transaction)、调整良好(welltuned)的系统,这一数值很大是很正常的,但在某些情况下,它可能暗示着系统中存在问题。你应当将这一等待统计量与Statspack报告中的已知问题(如效率较低的SQL)联系起来。检查索引扫描,以保证每个扫描都是必要的,并检查多表连接的连接顺序。DB_CACHE_SIZE也是这些等待出现频率的决定因素。有问题的散列区域(Hash-area)连接应当出现在PGA内存中,但它们也会消耗大量内存,从而在顺序读取时导致大量等待。它们也可能以直接路径读/写等待的形式出现。

3. 释放缓冲区。这种等待表明系统正在等待内存中的缓冲,因为内存中已经没有可用的缓冲空间了。如果所有SQL都得到了调优,这种等待可能表示你需要增大DB_BUFFER_CACHE。释放缓冲区等待也可能表示不加选择的SQL导致数据溢出了带有索引块的缓冲存储器,没有为等待系统处理的特定语句留有缓冲区。这种情况通常表示正在执行相当多数量的DML(插入/更新/删除),并且数据库书写器(DBWR)写的速度不够快,缓冲存储器可能充满了相同缓冲器的多个版本,从而导致效率非常低。为了解决这个问题,可能需要考虑增加检查点、利用更多的DBWR进程,或者增加物理磁盘的数量。

4. 缓冲区忙。这是为了等待一个以非共享方式使用的缓冲区,或者正在被读入缓冲存储器的缓冲区。缓冲区忙等待不应大于百分之一。检查缓冲等待统计部分(或V$WAITSTAT),看一下等待是否位于字段头部。如果事实如此,应增加自由列表(freelist)的组数,或者增加pctusedpctfree之间的距离。如果这一等待处于回退段(undo)头部块,可以通过增加回滚段(rollback segment)来解决缓冲区的问题;如果等待处于回退段(undo)非头部块上,就需要降低驱动一致读取的表中的数据密度,或者增大DB_CACHE_SIZE;如果等待处于数据块,可以将数据移到另一数据块以避开这个""数据块、增加表中的自由列表或使用本地化管理的表空间(Locally Managed Tablespaces);如果等待处于索引块,应该重建索引、分割索引或使用反向键索引。为了防止与数据块相关的缓冲忙等待,也可以使用较小的块:在这种情况下,单个块中的记录就较少,所以这个块就不是那么"繁忙"。在执行DML(插入/更新/删除)时,Oracle数据库书写器就向块中写入信息,包括所有对块状态"感兴趣"的用户(感兴趣的事务表,ITL)。为了减少这一区域的等待,可以增加initrans,这样会在块中创建空间,从而使你能够使用多个ITL槽。你也可以增加该块所在表中的pctfree(当根据指定的initrans建立的槽数量不足时,这样可以使ITL信息数量达到maxtrans指定的数量)5. latch释放。latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch就像是一种快速地被获取和释放的内存锁。latch用于防止共享内存结构被多个用户同时访问。如果latch不可用,就会记录latch释放失败。大多数latch问题都与以下操作相关:不能使用邦定变量(库缓存latch)、重复生成问题(重复分配latch)、缓冲存储器竞争问题(缓冲器存储LRU链),以及缓冲存储器中的""块(缓冲存储器链)。也有一些latch等待与bug(程序错误)有关,如果怀疑是这种情况,可以检查MetaLink上的bug报告(oracle.com/support)。当latch不命中率大于0.5%时,就应当研究这一问题。

6. Enqueueenqueue是一种保护共享资源的锁定机制。该锁定机制保护共享资源,如记录中的数据,以避免两个人在同一时间更新同一数据。enqueue包括一个排队机制,即FIFO(先进先出)排队机制。注意:Oraclelatch机制不是FIFOEnqueue等待通常指的是ST enqueueHW enqueueTX4 enqueueTM enqueueST enqueue用于空间管理和字典管理的表空间的分配。利用LMT,或者试图对区域进行预分配,或者至少使下一个区域大于有问题的字典管理的表空间。HW enqueue与段的高水位标记

一起使用;手动分配区域可以避免这一等待。TX4是最常见的enqueue等待。TX4 enqueue等待通常是以下三个问题之一产生的结果。第一个问题是唯一索引中的重复索引,你需要执行提交(commit/回滚(rollback)操作来释放enqueue。第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址(rowid),所以当多个用户试图更新同一段时,你需要执行提交或回滚操作,以释放enqueue。第三个问题,也是最可能发生的问题是多个用户同时更新同一个块。如果没有自由的ITL槽,就会发生块级锁定。通过增大initrans/maxtrans以允许使用多个ITL槽,或者增大表上的pctfree值,就可以很轻松地避免这种情况。最后,TM enqueueDML期间产生,以避免对受影响的对象使用DDL。如果有外来关键字,一定要对它们进行索引,以避免这种常见的锁定问题。

7. 日志缓冲空间。当你将日志缓冲(log buffer)写入重做日志(redo log)的速度比LGWR的写入速度快,或者是当日志转换(log switch)太慢时,就会发生这种等待。为解决这个问题,可以增大日志文件的大小,或者增加日志缓冲器的大小,或者使用写入速度更快的磁盘。你甚至可以考虑使用固态磁盘,因为它们的速度很高。

8. 日志文件转换。所有的提交请求都需要等待"日志文件转换(必要的归档)""日志文件转换(chkpt.不完全)"。确保归档磁盘未满,并且速度不太慢。DBWR可能会因为输入/输出(IO)操作而变得很慢。你可能需要增加更多或更大的重做日志,而且如果DBWR是问题症结所在的话,可能需要增加数据库书写器。

9. 日志文件同步。当一个用户提交或回滚数据时,LGWR将会话期的重做由日志缓冲器写入到重做日志中。日志文件同步过程必须等待这一过程成功完成。为了减少这种等待事件,可以尝试提交更多的记录(如一次提交50个记录,而不是一个)。将重做日志置于较快的磁盘上,或者交替使用不同物理磁盘上的重做日志,以降低归档对LGWR的影响。不要使用RAID 5,因为它对于那些书写很多的应用程序速度很慢,可以考虑使用文件系统直接输入/输出,或者使用原始设备(raw device),它们在书写信息时的速度非常快。

10. 空闲事件。在输出之后列出了几个空闲等待事件,你可以忽略它们。空闲事件一般被列在每节的底部,并且包括诸如送给/来自客户机构的SQLNet消息以及其他与后台相关的时间选择。空闲事件被列于stats$idle_event表中。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/104152/viewspace-139937/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 监控表的dml操作
下一篇: latch wait events
请登录后发表评论 登录
全部评论

注册时间:2007-12-21

  • 博文量
    132
  • 访问量
    286470