设为首页 - 加入收藏 云计算网_泰州站长网 (http://www.0523zz.com)- 中小站长必上的网站 - 聚焦泰州站长前沿资讯!
热搜: 徐屾屾 2008 2012 2005
当前位置: 主页 > 站长学院 > MySql教程 > 正文

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

发布时间:2019-08-15 18:35 所属栏目:[MySql教程] 来源:波波说运维
导读:副标题#e# 概述 最近生产环境有这么个现象,平时的订单调度只需要2s内可以出结果,但是多个人调度就会卡住,超过15分钟都没有结果出来,有时还会失败然后导致数据不准确。 下面记录一下生产环境卡顿时排查的过程。 1、获取ASH报告 SQL@?/rdbms/admin/ashrpt

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

概述

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

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

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

1、获取ASH报告

  1. SQL> @?/rdbms/admin/ashrpt.sql 
  2. --To specify absolute begin time: 
  3. --[MM/DD/YY]] HH24:MI[:SS] 
  4. --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上面有一篇文档

  1. 464246.1 
  2. Sometimes Parallel Rollback of Large Transaction may become very slow. After killing a large running transaction  
  3. (either by killing the shadow process or aborting the database) then database seems to hang, or smon and parallel query servers  
  4. taking all the available cpu. 
  5. In fast-start parallel rollback, the background process Smon acts as a coordinator and rolls back a set of transactions in parallel  
  6. using multiple server processes. Fast start parallel rollback is mainly useful when a system has transactions that run a long time  
  7. before comitting, especially parallel Inserts, Updates, Deletes operations. When Smon discovers that the amount of recovery work is  
  8. above a certain threshold, it automatically begins parallel rollback by dispersing the work among several parallel processes. 
  9. There are cases where parallel transaction recovery is not as fast as serial transaction recovery, because the pq slaves are interfering 
  10. with each other. It looks like the changes made by this transaction cannot be recovered in parallel without causing a performance problem.  
  11. The parallel rollback slave processes are most likely contending for the same resource, which results in even worse rollback performance  
  12. compared to a serial rollback. 

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章