(接上文)
https://likingzi.com/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%的等待事件就是它，单个等待时间不长，但是它多啊，它的排名淹没在了监控上的最后面，让你注意不到它！
但是，幸好这个累计等待事件排名，给了我极大的提示，我这才突然意识到，我刚才是走错路了。于是赶紧查找这个事件的底细，才有了重大发现，在此采用官方文档的说法来说明吧。
---未完待续
文章评论