eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« 2011-恩墨科技数据库基础与性能优化培训 | Blog首页 | Oracle Linux 6发布 缺省使用Ext4文件系统 »

大事务回滚导致系统故障案例一则

最近遇到的一则案例,客户系统响应缓慢,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,其逻辑读超高,执行未能成功完成:
Stat NameStatement TotalPer Execution% Snap Total
Elapsed Time (ms)12,233,40712,233,407.370.42
CPU Time (ms)274,181274,180.530.20
Executions1  
Buffer Gets46,723,42346,723,423.000.99
Disk Reads1,223,9471,223,947.001.81
Parse Calls11.000.00
Rows00.00 
User I/O Wait Time (ms)11,965,756  
Cluster Wait Time (ms)0  
Application Wait Time (ms)0  
Concurrency Wait Time (ms)0  
Invalidations0  
Version Count5  
Sharable Mem(KB)87  

根据执行计划,这个INSERT操作可能访问高达13M的记录,其回滚的效率可想而知,而且Oracle的并行回退效率并不高。

Execution Plan

Id Operation Name Rows Bytes Cost (%CPU) Time Pstart Pstop
0 INSERT STATEMENT     603K(100)   
1    FILTER        
2      PARTITION RANGE ITERATOR   1800K 111M 603K (1) 02:00:42 KEY KEY
3        TABLE ACCESS BY LOCAL INDEX ROWID TAB_LOG_CB2 1800K 111M 603K (1) 02:00:42 KEY KEY
4          INDEX RANGE SCAN IDX_CB2_DA 13M  36095 (1) 00:07:14 KEY KEY

朋友们遇到这个问题,可以尝试将fast_start_parallel_rollback改为HIGH看是否能够有所帮助,通常情况下是没有用的。

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



历史上的今天...
    >> 2009-02-11文章:
    >> 2008-02-11文章:
           遥远与安宁-2008新年记事
    >> 2005-02-11文章:
           关于redo copy latch的说明

无觅

By eygle on 2011-02-11 15:07 | Comments (8) | Case | 2726 |

8 Comments

请我能不能通过公开的v$视图诊断呢? 比如v$transaction.

我一见到x$内存表,就发怵. :)

请我 = 请问. 我 同 问. 通假字. 这两天[孙子兵法]看多了.

给力,记下了

  我们开发也有一次delete 一两千万的记录 大约4GB左右数据。然后delete 了几个小时还没有执行完,他就去kill那个进程。
  这时我根本都没有办法知道那个回退要回退多久....
受教了,这篇!

 我的这个系统里有4条DEAD的记录 ,但是KTUXESIZ 字段的值都是0
这个是为什么 ?

我的印象中,可以通过修改两个内部参数加快回退效率,不过会有风险
遇到过好几次的。。。。


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com