记一次生产环境卡顿优化过程：大事务并发回滚

记一次生产环境卡顿优化过程：大事务并发回滚

概述

最近生产环境有这么个现象，平时的订单调度只需要2s内可以出结果，但是多个人调度就会卡住，超过15分钟都没有结果出来，有时还会失败然后导致数据不准确。

下面记录一下生产环境卡顿时排查的过程。

1、获取ASH报告

SQL> @?/rdbms/admin/ashrpt.sql --To specify absolute begin time: --[MM/DD/YY]] HH24:MI[:SS] --08/09/19 08:40:00

2、ASH分析

（1）Top User Events

（2）相关sql

Top SQL with Top Events

sql明细

（3）存储过程

（4）TOP sessions

从上面分析可以看到两个明显的等待事件：wait for stopper event to be increased 等待事件和wait for a undo record 等待事件，这个应该是批量任务调度的时候产生了大量的大事务，产生了一些回滚造成了严重的资源消耗

3、处理大事务并发回滚

一般情况下wait for stopper event to be increased 等待事件是跟wait for a undo record 等待事件联系起来的。

对于这个等待事件metalink上面有一篇文档

解决的办法：

--关掉并发回滚，变成串行回滚（直接重启解决） sql> alter system set fast_start_parallel_rollback = false scope=spfile;

通常，如果有很多并发进程，可以根据v$px_session视图去查看，查看v$px_session视图，发现所有的并发进程都是由smon进程导致(即qcsid列为smon进程的session id)

而smon进程的等待事件为wait for stopper event to be increased

即smon进程在做大事务的回滚，默认参数fast_start_parallel_rollback参数为low，即回滚时会启动2*CPU个数 个并发进程。而由于是使用并发，所以可能由于并发之间相互使用共同的资源，导致回滚速度更慢。因为是生产环境，不能随便重启，所以我用了下面的方法来修改这个参数：

（1）查找smon进程ID

select pid,spid,pname,username,tracefile from v$process where pname='SMON'

（2）禁用smon进程的事务清理(Disable SMON transaction cleanup)

oradebug setorapid 'SMON's *** PID';  oradebug event 10513 trace name context forever, level 2

（3）查询V$FAST_START_SERVERS视图，将所有smon启用的并发进程杀掉

（4）修改fast_start_parallel_rollback参数

alter system set fast_start_parallel_rollback=false;

（5）启用smon进程的事务清理(enable transaction recovery)

oradebug setorapid 'SMON's *** PID'; oradebug event 10513 trace name context off

（6）获得tracefile name

oradebug tracefile_name

（7）验证

4、业务验证

修改后去业务验证，到高峰期还是有卡顿现象，不过频率减少了很多，报错之类的也没有了，同时观察新的报告可以发现并发回滚之类的等待事件已经没有了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。