enqueue HW wait 引起表空间突然大量扩展

我们在10.2.0.4上遇到过好几次了,enqueue HW wait不仅堵塞了事务,表空间也一下被用了很多,后来每次都预留几十GB的空间,但事务还是被堵塞,下面说说这个WAIT。

在高并发的oltp数据库,平时150多的active session,数据库的总session数会经常波动,可能从1000波动到1500或2000,几分钟后又回到1000左右。

一个表同时有大量的insert或update时,会有enq HW wait。因为insert/update会请求空间,而如果HWM下的free list 用完,没有剩余的数据块时,请求段内的空数据块,高水位往上移。而每个请求都需要HW enqeue。出现排队,此时如果高水位之上没有空余空间了,会出现段空间扩展。等待段空间扩展会使队列更长。

HW enqueue在非ASSM和ASSM都会出现,在我们的一个ASSM上的表,出现过段空间突然扩展9GB,同时表空间扩展15GB。可见ASSM oracle为了满足这么多HW enqueue 队列,会一下扩展很多。
应对方法看后面

[@more@]

non ASSM的解决,调整_bump_highwater_mark_count :

In non-ASSM tablespaces, HWM is bumped up by 5 blocks at a time ( Actually, undocumented parameter _bump_highwater_mark_count controls this behavior and defaults to 5). Heavy inserts in to a table can result in increased HWM activity leading to HW enqueue contention. This issue is prevalent if the table has LOB columns or if the row length is big.

ASSM的解决:

oracle记录了bug 6376915,不过按下面说法,应该只对LOB有用。

This fix causes ASSM LOB space to batch up reclaim instead of just reclaiming the requested/required number of LOB chunks. To enable this fix, set event 44951 to the maximum number of chunks that you would like to have reclaimed per attempt. The maximum allowed is 1024. Anything larger becomes 1024. However, if the requested amount of space is larger than the event’s value, the reclaim will be for the requested amount of space.

而如果表里根本没有LOB,这个event没用,怎么做。

能想到的是,低峰期手工扩展,防止高峰期HW enqueue对事务的阻塞,影响业务。

首先看看unused空间,我推测应该是HWM以上空间+free list的空间。所以要给unused多预留一些:

set serveroutput on size 10000;
DECLARE
su NUMBER;
sa NUMBER;
cp NUMBER;
BEGIN
dbms_space.object_space_usage('USER','TEST_TABLE','TABLE', NULL, su, sa, cp);

dbms_output.put_line('Space Used: ' || round(su/1024/1024,0));
dbms_output.put_line('Space Allocated: ' || sa/1024/1024);
dbms_output.put_line('space unused: ' || round(sa/1024/1024-su/1024/1024,0));
dbms_output.put_line('Chained Percentage: ' || TO_CHAR(cp));
END;
/

手工扩展,注意会使相关sql age out,所以要在低峰期跑。

alter table test_table allocate extent (size 1024m);

如果你用dbms_space.space_usage 查看HWM下的块情况,会发现扩展前后HWM下的空间并没有变化。

而你用dbms_space.unused_space看这个段,发现unused bytes刚好是你扩展的空间。

而前面dbms_space.object_space_usage里的unused space大于dbms_space.unused_space里的unused bytes。

我推测dbms_space.unused_space里的unused bytes是HWM以上的空余空间,而dbms_space.object_space_usage里的unused space是HWM以上的空间+free list得到的。

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

转载于:http://blog.itpub.net/668365/viewspace-1037858/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值