Oracle高并发系列1：DML引起的常见问题及优化思路(2)

发布时间：2021-01-07 19:15 所属栏目：53 来源：网络整理

导读：解决思路：? ? 删除无用索引.为什么把这个显而易见的措施放到第一位呢,其实是有来由的.很多开发人员其实并不知道一个表上若创建过多索引会对DML产生影响,只知道创建索引对查询带来帮助,有些夸张的甚至会为一个表的

解决思路：? ?

删除无用索引.为什么把这个显而易见的措施放到第一位呢,其实是有来由的.很多开发人员其实并不知道一个表上若创建过多索引会对DML产生影响,只知道创建索引对查询带来帮助,有些夸张的甚至会为一个表的每个列上都创建单列或组合索引.但是事实证明,经过DBA的采样监控,很多索引可能一年半载都不会被用到,那么还不删除这些索引更待何时?
将索引改造为hash分区索引.原理是可以打散并发操作的叶子节点.
将索引改造为反序索引.原理同上,因为是reverseindex,同样可以打散high key的叶子节点.
设置更小的block size,比如8k -> 4k – 2k.原理一样,因为更小的索引block里面存放的条目更少,理论上减少了两个不同会话同时访问同一个block的几率,进而减少了争用.但是这个方案其实会有其它副作用,除非其它方案都不能考虑,否则不建议这个方案.
重建索引. 为什么重建索引对这个问题能够带来帮助呢,因为重建索引后减少了索引的碎片,索引block变得更加紧凑,减少了index leaf block split时寻找空块的时间,提高了Oracle进行索引分裂时的效率,进而可以减少等待时间.
如果index contention的对象不是leaf block,而是rootblock,则可以考虑通过以下方法激活索引的root block分裂时的优化：1)alter system set events ‘43822 trace name context forever,level1’;
2)event 43822启用后,对于root block的split进行了增强,不会超过5次的index block reclamation,Oracle就会去申请分配新块了.

背景知识：

Oracle在索引split时中寻找可复用的free block的过程如下：

Oracle不会一开始就让index segment申请分配新的空间(这会造成index segment的空间过度增长),而是到该index segment的其它地方搜索是否存在可用的Free Block,这些Free Block的要求是status是75%-100% Free的,server process会扫描这些75%-100% Free的block 并确认这些block 实际上是100%空的,如果找到100% Free Block则使用；如果没有则继续搜索,直到所有候选block都被检查过,这个行为叫做 probes on index block reclamation.每次寻找空块并failed,oracle就会增加这个统计指标： “failed probes on index block reclamation”.Oracle内部机制会控制要找多少次,不会去FULL SCAN所有index block的,failed超过一定次数后就会申请分配新的block.

不能重用的原因有2个：??

可能这个块不是100%free的,而是70% ~ <100% free的,也就是找到的这个block上面还有几行或者多行索引记录,所以不能被重用来做split.
可能这个块上还有一些其它的active transaction,所以它重用不了.

在这个过程中,Oracle还有机会找到的block其实已经是索引结构中的一个非空block,但是Oracle只会在splittingand relinking to index structure之后才会发现这个block其实是illegal的选择,这个时候Oracle会回滚这个操作,这个统计记录在‘transaction rollback’ in v$sysstat,然后继续寻找另外一个block.

Oracle进行找空块的过程中,如果这些块不在内存中,会增加物理读,如果这些块还需要做延迟块清除或者还要回滚,则需要触发更多系统递归操作,可见,如果“failed probes”过多,split效率低下时,会直接导致index contention增加.

3、enq: HW –contention

TABLE的High WaterMark(即高水位线)标识table segment中已用空间和未用空间的边界,具体来讲,HWM以上的block的状态是：unformattedand have never been used； HWM以下的block的状态是：Allocated,but currentlyunformatted and unused、 Formatted and contain data、Formatted and empty because the data was deleted.当HWM以下的block都无空闲空间可以使用时,Oracle会推进HWM来申请分配新的block到segment里面,而HW enqueue锁被用来管理推进HWM分配新空间时的串行操作.

显而易见,当高并发的insert发生时,甚至表中若有LOB字段时情况更糟,HWM的推进分配新空间的速度赶不上并发会话所需空间的速度时,就会发生在HW的enq上的等待.

解决思路： ?

删除无用索引.
改造为hash分区表.同一时间的并发的空间分配需求会被打散到多个分区段上.
提前手工allocatenew空间(可以做成定期自动任务).
主动shrink回收可以重用的空间,避免业务高峰期的自动allocate竞争.
设置表空间更大的UNIFORM SIZE,每次allocate更多extent到表的HWM之上,避免HWM剧烈时偶尔还会等在表空间的extent分配上.
确保使用ASSM (Automatic segment spacemanagement) tablespace.
隐含参数_bump_highwater_mark_count,可以控制HWM每次推进的block个数.但是设置该隐含参数应该得到Oracle的支持,而且对其它小表有负面影响.
检查IO子系统性能,有时候IO性能的变化也会导致空间分配操作缓慢,进而引发等待.
LOB段空间的频繁重回收,可能也会导致该竞争,针对LOB可以适当增加chunk,每次分配更多空间；也可以主动allocate 或shrink
另外针对使用ASSM表空间的LOB有一个Bug 6376915注意检查是否已applied fixed patch,并且要通过设置event来启用.此event用于控制1次LOB chunk回收操作时的chunk个数(default是1),进而可以减少HWM enq等待发生的次数.
EVENT=”44951 TRACE NAME CONTEXT FOREVER,LEVEL < 1 -1024 >”

4、enq: US –contention

这个等待事件通常说明会话在等待Undo Segment,注意等待的原因一般其实并不是因为UNDO TABLESPACE没有空间了,UNDO表空间不足会直接报ORA-30036(NOSPACEERRCNT).

（编辑：ASP站长网）