大量事务并发回滚彻底堵塞数据库(2)

2021年6月10日 1139点热度 0人点赞 0条评论

(接上文)
https://liking.site/2021/06/09/大量事务并发回滚彻底堵塞数据库1/
在数次停库、起库的过程当中,遭遇过部分实例起在其他节点的情况,如下。

srvctl start instance -d jkdb -i jkdb1
发现实例1起在了2号节点
srvctl stop instance -d jkdb -i jkdb1

srvctl start instance -d jkdb -i jkdb3
实例3起在了3号节点

srvctl start instance -d jkdb -i jkdb2
发现实例2起在了1号节点
srvctl stop instance -d jkdb -i jkdb2

对这个机制理解不深,此处暂时略过。
根据之前的配置优化记录,优化配置参数_use_adaptive_log_file_sync,“该参数在commit次数较多的系统中,post/wait and polling特性对性能影响明显,主要是在写日志上的等待上影响了事务的提交速度,建议在11g中关闭”,设置为FALSE,即时生效,如下:

alter system set "_use_adaptive_log_file_sync"=FALSE scope=both sid='*';

监控显示,等待事件没有起色,甚至怀疑过是否DG拖累了主库?这个怀疑一瞬记过,因为DG配置为最大性能模式,理论上即使DG死掉,也不会对主库性能造成影响,更不必说有人怀疑“DG日志空间满导致了本次数据库无响应”。
在此只是临时停掉了DG的日志传输,随后马上就打开了,只是为了验证错误说法的错误而已,如下:

SYS@jkdb2> alter system set log_archive_dest_state_3=defer scope=both sid='*';
System altered.
SYS@jkdb2> alter system set log_archive_dest_state_1=defer scope=both sid='*';
System altered.

经历了前期几个小时的折腾之后,我才真正注意到了这个罪魁祸首的等待事件wait for a undo record,之前过分关注了排在前面的事务前滚的等待事件,未能想到这不是事件的根因。
尽管这个wait for a undo record事件没有排在屏幕最前面,但是累计等待事件显示,数据库66%的等待事件就是它,单个等待时间不长,但是它多啊,它的排名淹没在了监控上的最后面,让你注意不到它!
但是,幸好这个累计等待事件排名,给了我极大的提示,我这才突然意识到,我刚才是走错路了。于是赶紧查找这个事件的底细,才有了重大发现,在此采用官方文档的说法来说明吧。
---未完待续

liking

这个人很懒,什么都没留下

文章评论