问题描述
最近遇到的一则案例,客户系统响应缓慢,IO Wait超高,系统体现在Log file sync上出现大量等待,磁盘没有错误信息。
专家解答
我的第一印象就是,可能有大事务在回滚,通过如下查询立刻找到了数据库中存在的一个死事务:
SQL> select distinct KTUXECFL,count(*) from x$ktuxe group by KTUXECFL; KTUXECFL COUNT(*) ------------------------ ---------- DEAD 1 NONE 7969
首先这个死事务是极其可以的,具体查看其信息,发现其回退的极其缓慢:
SQL> select ADDR,KTUXEUSN,KTUXESLT,KTUXESQN,KTUXESIZ 2 from x$ktuxe where KTUXECFL='DEAD'; ADDR KTUXEUSN KTUXESLT KTUXESQN KTUXESIZ -------- ---------- ---------- ---------- ---------- B7FCBB98 37 1 4915 158026 SQL> / ADDR KTUXEUSN KTUXESLT KTUXESQN KTUXESIZ -------- ---------- ---------- ---------- ---------- B7FCBB98 37 1 4915 158026 SQL> select ADDR,KTUXEUSN,KTUXESLT,KTUXESQN,KTUXESIZ from x$ktuxe where KTUXECFL='DEAD'; ADDR KTUXEUSN KTUXESLT KTUXESQN KTUXESIZ -------- ---------- ---------- ---------- ---------- B7FCBB98 37 1 4915 157966
按照这个进度,可能需要几天去回滚这个失败的事务,最后客户选择了激活备库,放弃主库来恢复生产。
最后通过AWR数据找到了这个导致大事务的SQL,其逻辑读超高,执行未能成功完成
根据执行计划,这个INSERT操作可能访问高达13M的记录,其回滚的效率可想而知,而且Oracle的并行回退效率并不高。
朋友们遇到这个问题,可以尝试将fast_start_parallel_rollback改为HIGH看是否能够有所帮助,通常情况下是没有用的。
由此可见,对于大批量的数据处理,是应当小心谨慎的。
最后修改时间:2019-05-08 11:02:54
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。