AWR报告，很多索引的行级锁冲突。

wabjtam123

原帖由 lsq_008 于 2010-6-22 16:15 发表
Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
enq: TX - index contention          100,662     192,189   1909   56.0 Concurrenc
enq: US - contention                172,842      64,292    372   18.7      Other
latch: row cache objects            827,074      38,649     47   11.3 Concurrenc
db file sequential read           2,213,102      18,923      9    5.5   User I/O
CPU time                                         14,680           4.3

Segments by Row Lock Waits           DB/Inst: xxxx/xxxx  Snaps: 16921-16922                  
-> % of Capture shows % of row lock waits for each top segment compared                        
-> with total row lock waits for all segments captured by the Snapshot                        
                        
                                                                     Row                        
           Tablespace                      Subobject  Obj.          Lock    % of               
Owner         Name    Object Name            Name     Type         Waits Capture               
---------- ---------- -------------------- ---------- ----- ------------ -------               
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX       14,726   38.69                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        5,271   13.85                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        3,949   10.38                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        3,736    9.82                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        3,349    8.80                        
                        
这可能是索引块分裂引起的锁等待。

我没看见附件，兄台怎么看到这个啊？

junsansi

原帖由 lsq_008 于 2010-6-22 16:15 发表
Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
enq: TX - index contention          100,662     192,189   1909   56.0 Concurrenc
enq: US - contention                172,842      64,292    372   18.7      Other
latch: row cache objects            827,074      38,649     47   11.3 Concurrenc
db file sequential read           2,213,102      18,923      9    5.5   User I/O
CPU time                                         14,680           4.3

Segments by Row Lock Waits           DB/Inst: xxxx/xxxx  Snaps: 16921-16922                  
-> % of Capture shows % of row lock waits for each top segment compared                        
-> with total row lock waits for all segments captured by the Snapshot                        
                        
                                                                     Row                        
           Tablespace                      Subobject  Obj.          Lock    % of               
Owner         Name    Object Name            Name     Type         Waits Capture               
---------- ---------- -------------------- ---------- ----- ------------ -------               
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX       14,726   38.69                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        5,271   13.85                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        3,949   10.38                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        3,736    9.82                        
xxxxx      xxxxxxxxxx xxxxxxxxxxxxx           INDEX        3,349    8.80                        
                        
这可能是索引块分裂引起的锁等待。

好贴，学习~~~

xzh2000

这样的贴子也可以授精啊?

zhanglei_itput

请问lz问题是否已经解决了？关注中。。。

wei-xh

原帖由 zhanglei_itput 于 2010-6-24 09:56 发表
请问lz问题是否已经解决了？关注中。。。

这几个索引都是并发插入很高的，我能想到的办法一个是增加数据块大小，二是为表建立HASH分区，可是这样的分区对索引范围扫描代价又过高。我没有太好的理由去说服领导这么做，而且现在系统的性能并不差，暂时先这样吧。要是测试库多好啊，我就可以瞎倒腾倒腾。

[ 本帖最后由 wei-xh 于 2010-6-29 14:49 编辑 ]

MicroJoey

解决办法是？

wabjtam123

不知道是否是开始有附件，后来LZ又删除了

lsq_008

原帖由 wabjtam123 于 2010-6-24 08:56 发表


我没看见附件，兄台怎么看到这个啊？

呵呵，这个从我管的库的一份awr报告里取的，为了说明row lock wait与索引块分裂之间的联系

ABAP/4

原帖由 wei-xh 于 2010-6-24 10:32 发表


这几个索引都是并发插入很高的，我能想到的办法一个是减少数据块大小，二是为表建立HASH分区，可是这样的分区对索引范围扫描代价又过高。我没有太好的理由去说服领导这么做，而且现在系统的性能并不差，暂时先这样吧。要是测试库多好啊，我就可以瞎倒腾倒腾。

    为什么是要减少块的大小？ 我觉得应该是增大才对，单独建立一个大块的表空间，从新建立索引。

   至于建立HASH分区，老实说，没有看明白为什么这样

wei-xh

原帖由 ABAP/4 于 2010-6-29 13:12 发表



    为什么是要减少块的大小？ 我觉得应该是增大才对，单独建立一个大块的表空间，从新建立索引。

   至于建立HASH分区，老实说，没有看明白为什么这样

第一条已修正。
第二条，为索引建立hash分区后，会减少相同索引块的争用啊。本来10个记录都要往块A插的，HASH(假设4分区)以后很大的可能往四个块插了。