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

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

导读：造成这个等待的典型场景有：如果UNDO表空间是AUTOEXTEND的,则Oracle会自动调整undo retention,在尽量保持retention参数设定的undo block保留期的基础上,还会尽量满足一些长查询的读一致性需求.那么当这个特性发挥

造成这个等待的典型场景有：

如果UNDO表空间是AUTOEXTEND的,则Oracle会自动调整undo retention,在尽量保持retention参数设定的undo block保留期的基础上,还会尽量满足一些长查询的读一致性需求.那么当这个特性发挥作用时,很多UNDO segment都被用在了长查询(MAXQUERYLEN)的支持上,当突发很多并发会话同时需要申请分配undo segment时,Oracle的回收机制(UNXPSTEAL)就会捉襟见肘.
大量active的undo block正在回滚、无法重用,可能是由于不久之前刚kill了一个长事务造成的.
也可能是虽然有空闲空间,但是由于应用重启、或者准点抢售类的应用导致高并发事务进入数据库后,短暂时间内需要将大量的undo seg从offline变成online,而smon没有处理得那么快,故可能出现短暂的大量enq:US-contention,这个时候通常会伴随大量的’latch: rowcache objects'(on DC_ROLLBACK_SEGMENTS).我们的一个保险类系统在双11抢售时后台数据库就曾经出现过这个问题.

解决思路：

如果预期要做抢售活动,可以提前维护,设置_ROLLBACK_SEGMENT_COUNT为一个较高的值,保持一定数量的undosegments始终是online状态.
设置event让SMON不会自动将undo segment OFFLINE：
alter system set events ‘10511 trace name context forever,level1 ‘;
将_UNDO_AUTOTUNE临时设置为FALSE,以避免当UNDO TBS很空闲时,Oracle自动将undo retention调得很大,提前占用过多undo segments.
设置_HIGHTHRESHOLD_UNDORETENTION,虽然允许Oracle自动调整undo retention,但是为它设置一个天花板,不会过份地受MAXQUERYLEN的影响.

本文重要提示：

上述所有隐含参数的介绍,一方面是为了加深对Oracle相关管理机制的了解,另一方面都是在常规手段包括应用层调优的手段无法奏效的前提下的应急方案,在生产环境启用之前请得到Oracle原厂的确认与支持,而且在高峰期或问题应急解决后务必要取消隐参.

不要随意在生产环境使用隐含参数,这是一个最基本的数据库运维原则!

总结

上面这些问题的解决思路其实都是治标不治本的,这些优化措施可能能够帮助你的系统度过当前的系统波峰,但是随着时间的推移当更大的波峰出现时,问题还会再次发生.优化“对数据库的需求”带来的效果永远大于优化“数据库所能提供的资源”,虽然有时候优化“对数据库的需求”的成本投入更高,但是投入与产出一般都是成正比的.从这个意义上来讲,若应用能够合理控制并发、系统架构中引入缓存层、采用异步队列处理机制、优化DB模型设计以及SQL写法等,这才是解决问题的根本之道.

文章出处：DBAplus社群

（编辑：ASP站长网）