博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
enqueue HW wait 引起表空间突然大量扩展
阅读量:2492 次
发布时间:2019-05-11

本文共 2451 字,大约阅读时间需要 8 分钟。

我们在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/

你可能感兴趣的文章
期货市场技术分析04_持续形态
查看>>
期货市场技术分析05_交易量和持仓兴趣
查看>>
TB交易开拓者入门教程
查看>>
TB创建公式应用dll失败 请检查用户权限,终极解决方案
查看>>
python绘制k线图(蜡烛图)报错 No module named 'matplotlib.finance
查看>>
talib均线大全
查看>>
期货市场技术分析06_长期图表和商品指数
查看>>
期货市场技术分析07_摆动指数和相反意见理论
查看>>
满屏的指标?删了吧,手把手教你裸 K 交易!
查看>>
不吹不黑 | 聊聊为什么要用99%精度的数据回测
查看>>
对于模拟交易所引发的思考
查看>>
高频交易的几种策略
查看>>
量化策略回测TRIXKDJ
查看>>
量化策略回测唐安奇通道
查看>>
CTA策略如何过滤部分震荡行情?
查看>>
量化策略回测DualThrust
查看>>
量化策略回测BoolC
查看>>
量化策略回测DCCV2
查看>>
mongodb查询优化
查看>>
五步git操作搞定Github中fork的项目与原作者同步
查看>>