大事务回滚导致系统故障

盖国强 2019-05-08
18
0 0
摘要:系统响应缓慢,IO Wait超高,系统体现在Log file sync上出现大量等待,磁盘没有错误信息。对于大批量的数据处理,是应当小心谨慎的。

问题描述

最近遇到的一则案例,客户系统响应缓慢,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看是否能够有所帮助,通常情况下是没有用的。

由此可见,对于大批量的数据处理,是应当小心谨慎的。

「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
Oracle
订阅
欢迎订阅Oracle频道,订阅之后可以获取最新资讯和更新通知。
墨值排行
今日本周综合
近期活动
全部
相关课程
全部