[RAC Clusterware] insert引起的blocking

2^#

发表于 2013-3-12 12:05:41

25% -- 50% free spaceblocks.............52136
25% -- 50% free spacebytes..............427098112

大多是 25~50的free block，可能这个 index上的数据被删除过不少存在所谓“碎片”

你能否上传问题时段的 AWR+ASH+ADDM?

3^#

发表于 2013-3-12 12:22:38

本帖最后由波导手机于 2013-3-12 13:03 编辑

Maclean Liu(刘相兵发表于 2013-3-12 12:05
25% -- 50% free spaceblocks.............52136
25% -- 50% free spacebytes..............427098112

最后我们重建了索引。该表是一个大的分区表，每月做drop partition update global indexes操作。
主要是想找到root cause.

1 是一条insert ，为什么要等很长时间的db file sequenctial read
2 是该insert 阻塞了索引的块分裂。

4^#

发表于 2013-3-12 12:26:52

select SS.snap_id,
SS.stat_name,
TO_CHAR(S.BEGIN_INTERVAL_TIME, ‘DAY’) DAY,
S.BEGIN_INTERVAL_TIME,
S.END_INTERVAL_TIME,
SS.value,
SS.value – LAG(SS.VALUE, 1, ss.value) OVER (ORDER BY SS.SNAP_ID) AS DIFF
from DBA_HIST_SYSSTAT SS,
DBA_HIST_SNAPSHOT S
where S.SNAP_ID = SS.SNAP_ID
AND SS.stat_NAME = ‘failed probes on index block reclamation’
ORDER BY SS.SNAP_ID ;

复制代码

上面的脚本查一下

5^#

发表于 2013-3-12 12:30:51

本帖最后由波导手机于 2013-3-12 13:37 编辑

Maclean Liu(刘相兵发表于 2013-3-12 12:26
上面的脚本查一下

结果附件中

6^#

发表于 2013-3-12 12:38:38

8546	failed probes on index block reclamation	MONDAY	2013-03-11 15:00:36.410	2013-03-11 15:30:04.739	1765	-17650
28546	failed probes on index block reclamation	MONDAY	2013-03-11 15:00:36.515	2013-03-11 15:30:04.808	1765	0
28546	failed probes on index block reclamation	MONDAY	2013-03-11 15:00:36.410	2013-03-11 15:30:04.739	19415	17650
28546	failed probes on index block reclamation	MONDAY	2013-03-11 15:00:36.515	2013-03-11 15:30:04.808	19415	0
28547	failed probes on index block reclamation	MONDAY	2013-03-11 15:30:04.739	2013-03-11 16:00:01.815	1765	-17650
28547	failed probes on index block reclamation	MONDAY	2013-03-11 15:30:04.808	2013-03-11 16:00:01.821	1765	0
28547	failed probes on index block reclamation	MONDAY	2013-03-11 15:30:04.739	2013-03-11 16:00:01.815	19415	17650
28547	failed probes on index block reclamation	MONDAY	2013-03-11 15:30:04.808	2013-03-11 16:00:01.821	19415	0
28548	failed probes on index block reclamation	MONDAY	2013-03-11 16:00:01.815	2013-03-11 16:30:10.202	194661	175246
28548	failed probes on index block reclamation	MONDAY	2013-03-11 16:00:01.821	2013-03-11 16:30:10.276	194661	0
28548	failed probes on index block reclamation	MONDAY	2013-03-11 16:00:01.815	2013-03-11 16:30:10.202	19415	-175246
28548	failed probes on index block reclamation	MONDAY	2013-03-11 16:00:01.821	2013-03-11 16:30:10.276	19415	0
28549	failed probes on index block reclamation	MONDAY	2013-03-11 16:30:10.202	2013-03-11 17:00:27.927	194661	175246
28549	failed probes on index block reclamation	MONDAY	2013-03-11 16:30:10.276	2013-03-11 17:00:27.933	194661	0

7^#

发表于 2013-3-12 12:41:22

请问这个产生的原因，是因为索引的碎片太多吗？怎么理解这个事件？

8^#

发表于 2013-3-12 12:42:20

因为是RAC 所以这个脚本出现的结果会有点问题，但是可以看到的是 16:00~16:30
这个时段的

failed probes on index block reclamation 是平时的几十倍，这说明 index split时持有 enq:tx index锁的process 探测了大量的block 以便能找到合适的block来分裂块，这是其他insert会等待 enq:tx index contention。

若持有enq:tx锁的进程一直找不到合适的block，则会导致大量的enq:tx index contention等待。负责找这个block的进程会读取索引中 freelist上的合适块，如果这些块不在buffer cache中则会有 db file sequential read等待。

你可以看看这个文档：
http://www.askmaclean.com/archiv ... 88%86%E6%9E%90.html

9^#

发表于 2013-3-12 13:00:46

assm同样也存在，split时，找空闲块的情况，assm 从bitmap里扫标记空闲的块，可是扫到的块虽然空闲，但是不能进行分裂，分裂必须找到100%空闲，于是就不断的db file sequential read, 其他split只能等在这里，直到找到真正空闲的块。
我的理解是否正确？

10^#

发表于 2013-3-12 13:02:09

波导手机发表于 2013-3-12 13:00
assm同样也存在，split时，找空闲块的情况，assm 从bitmap里扫标记空闲的块，可是扫到的块虽然空闲，但是 ...

不管mssm还是assm都存在，解决方法包括：

1. 强制缓存索引在keep中避免物理读
2. 不做rebuild ，只做coalesce
3. 考虑用global hash or range+hash local index

11^#

发表于 2013-3-12 13:03:10

非常感谢，结束此贴，受益匪浅。