eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Statspack之十二-db file scattered read-DB文件分散读取 | Blog首页 | Statspack之十四-"log file sync" 等待事件 »

Statspack之十三-Enqueue

enqueue是一种保护共享资源的锁定机制。该锁定机制保护共享资源,如记录中的数据,以避免两个人在同一时间更新 同一数据。enqueue
包括一个排队机制,即FIFO(先进先出)排队机制。

Enqueue等待常见的有ST、HW 、TX 、TM等

ST enqueue,用于空间管理和字典管理的表空间(DMT)的区间分配,在DMT中典型的是对于uet$和fet$数据字典表的 争用。对于支持LMT的
版本,应该尽量使用本地管理表空间. 或者考虑手工预分配一定数量的区(Extent),减少动态扩展
时发生的严重队列竞争。

我们通过一个实例来看一下:

 
DB Name         DB Id    Instance     Inst Num Release     OPS Host
------------ ----------- ------------ -------- ----------- --- ------------------
DB       40757346      aaa                 1 8.1.7.4.0   NO    server

                Snap Id     Snap Time      Sessions
                ------- ------------------ --------
 Begin Snap:       2845 31-10月-03 02:10:16      46
   End Snap:       2848 31-10月-03 03:40:05      46
    Elapsed:                  89.82 (mins)


对于一个Statspack的report,采样时间是非常重要的维度,离开时间做参考,任何等待都不足以说明问题。

Cache Sizes
~~~~~~~~~~~
           db_block_buffers:      51200          log_buffer:    2097152
              db_block_size:      16384    shared_pool_size:  209715200
...........
Top 5 Wait Events
~~~~~~~~~~~~~~~~~                                   Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
enqueue                                            53,793   16,192,686   67.86
rdbms ipc message                                  19,999    5,927,350   24.84
pmon timer                                          1,754      538,797    2.26
smon timer                                             17      522,281    2.19
SQL*Net message from client                   94,525      520,104   2.18
          -------------------------------------------------------------

在Statspack分析中,Top 5等待事件是我们最为关注的部分。
这个系统中,除了enqueue 等待事件以外,其他4个都属于空闲等待事件,无须关注。我们来关注一下enqueue等
待事件,在89.82 (mins)的采样间隔内,累计enqueue等待长达16,192,686cs,即45小时左右。这个等待已经太过
显著,实际上这个系统也正因此遭遇了巨大的困难,观察到队列等待以后,我们就应该关注队列等待在等待什么
资源。快速跳转的Statspack的其他部分,我们看到以下详细内容:

Enqueue activity for DB: DB  Instance: aaa  Snaps: 2716 -2718
-> ordered by waits desc, gets desc

Enqueue            Gets      Waits
---------- ------------ ----------
ST                1,554      1,554
          -------------------------------------------------------------

我们看到主要队列等待在等待ST锁定,对于DMT,我们说这个等待跟FET$,UET$的争用紧密相关。我们在回过头来
研究捕获的SQL语句:

-> End Buffer Gets Threshold:   10000
-> Note that resources reported for PL/SQL includes the resources used by
   all SQL statements called within the PL/SQL code.  As individual SQL
   statements are also reported, it is possible and valid for the summed
   total % to exceed 100

  Buffer Gets    Executions  Gets per Exec  % Total  Hash Value
--------------- ------------ -------------- ------- ------------
      4,800,073       10,268          467.5    51.0   2913840444
select length from fet$ where file#=:1 and block#=:2 and ts#=:3

        803,187       10,223           78.6     8.5    528349613
delete from uet$ where ts#=:1 and segfile#=:2 and segblock#=:3 a
nd ext#=:4

        454,444       10,300           44.1     4.8   1839874543
select file#,block#,length from uet$ where ts#=:1 and segfile#=:
2 and segblock#=:3 and ext#=:4

         23,110       10,230            2.3     0.2   3230982141
insert into fet$ (file#,block#,ts#,length) values (:1,:2,:3,:4)

         21,201          347           61.1     0.2   1705880752
select file# from file$ where ts#=:1
....
          9,505           12          792.1     0.1   1714733582
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t whe
re t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0

          6,426          235           27.3     0.1   1877781575
delete from fet$ where file#=:1 and block#=:2 and ts#=:3

 
我们看到数据库频繁操作UET$,FET$系统表已经成为了系统的主要瓶颈。 至此,我们已经可以准确的为该系统定位问题,相应的解决方案也很容易确定,在8.1.7中,使用LMT代替DMT, 这是解决问题的根本办法,当然实施起来还要进行综合考虑,实际情况还要复杂得多。

 

HW enqueue指和段的高水位标记相关等待;手动分配适当区可以避免这一等待。

TX锁(事务锁)是最常见的enqueue等待。TX enqueue等待通常是以下三个问题之一产生的结果。
第一个问题是唯一索引中的重复索引,你需要执行提交(commit)/回滚(rollback)操作来释放enqueue。
第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址(rowid),所以当多个用户试图更新同一段时,可能一个
用户会锁定其他用户请求的记录,这时等待出现。直到获得锁定的用户提交或回滚, enqueue释放。
第三个问题,也是最可能发生的问题是多个用户同时更新同一个块。如果没有足够的ITL槽,就会发生块级锁定。通过增大initrans和/或maxtrans以允许使用多个ITL槽(对于频繁并发进行DML操作的数据表,在建表之初就应该考虑为相应参数设置合理的数值,避免系统运行以后在线的更改,在8i之前,freelists等参数不能在线更改,设计时的考虑就尤为重要),或者增大表上的pctfree值,就可以很容易的避免这种情况。

TM enqueue队列锁在进行DML操作前获得,以阻止对正在操作的数据表进行任何DDL操作(在DML操作一个数据表时,其结构不能被更改)。

 


历史上的今天...
    >> 2010-10-14文章:
    >> 2009-10-14文章:
    >> 2008-10-14文章:
    >> 2007-10-14文章:
           我的新房 我的家
    >> 2006-10-14文章:
           有朋自远方来 不亦悦乎
    >> 2005-10-14文章:

无觅

By eygle on 2004-10-14 22:23 | Comments (1) | Special | 62 |

1 Comment

hi eygle. 我遇到一个故障不属于其中的任何一种TX情形,数据库某表上有个复合主键约束,同时我在另外一个区分度较好的列上又加了一个索引,查询性能得到极大提高,但是插入的时候导致大量的ENQUEUE,数据库几乎崩溃。取消新添加索引之后,又恢复了正常。这是什么原因?


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com