当前位置: 首页 > Oracle, oracle 10g, oracle 11g > 正文

一次ORACLE数据库IO异常故障

前几天监控显示数据库的I/O异常。

201603080001

 

由于这台服务器上有两个实例,这个数据库消耗了大量的I/O,导致另一个数据库的压力也很大。

201603080002

经过查询发现,消耗I/O资源较高的是一条很简单的查询SQL。

select count(id) 
from CHHMIF.IF_ORD_GHB_RECORD_2014 
where customercallid='dc54034c-debe-4764-87c3-7df47bb1caff'

从这条SQL可以看出几个问题,首先这个SQL没有使用绑定变量,虽然这条SQL频繁执行,但这不是导致故障的具体原因。其次,从表名可以看出,这个表存放的是2014年的数据,这种一年多以前的历史数据,不应该在核心数据库内操作。

经查看,这个表是在2016年1月21日创建的,这次故障正好赶上应用系统刚刚发版,可能是这次发版开始使用这张表。

SQL> select object_name,created from dba_objects where object_name='IF_ORD_GHB_RECORD_2014';

OBJECT_NAME               CREATED
------------------------- -------------------
IF_ORD_GHB_RECORD_2014    2016-01-21 15:04:50

经过查询,这张表只有ID字段存在主键,其他字段均没有索引。

SQL> select index_name,column_name from dba_ind_columns where table_name='IF_ORD_GHB_RECORD_2014';

INDEX_NAME                     COLUMN_NAM
------------------------------ ----------
PK_ORD_GHB_REC_2014            ID

经查询,这张表将近1.5GB。

SQL> select sum(bytes/1024/1024/1024),segment_name from dba_segments where segment_name='IF_ORD_GHB_RECORD_2014' group by segment_name;

SUM(BYTES/1024/1024/1024) SEGMENT_NAME
------------------------- -------------------------
               1.44335938 IF_ORD_GHB_RECORD_2014

由于没有索引,这条SQL每次运行都要全表扫描,以下是执行计划。

Execution Plan
----------------------------------------------------------
Plan hash value: 1606676435

---------------------------------------------------------------------------------------------
| Id  | Operation          | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |                        |     1 |    37 | 51330   (1)| 00:10:16 |
|   1 |  SORT AGGREGATE    |                        |     1 |    37 |            |          |
|*  2 |   TABLE ACCESS FULL| IF_ORD_GHB_RECORD_2014 |     1 |    37 | 51330   (1)| 00:10:16 |
---------------------------------------------------------------------------------------------

以下是SQL执行计划的统计信息。

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     169306  consistent gets
     169273  physical reads
          0  redo size
        527  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

通过统计信息可以算出,这条SQL每次运行,需要扫描磁盘1.3GB的数据。

SQL> select 169273*8/1024/1024 from dual;

169273*8/1024/1024
------------------
         1.2914505

通过监控定位到,这条SQL由一个数据同步程序发出。

201603080005

经和项目负责人沟通,项目负责人下令关闭了这个模块,并由他们提供创建索引的脚本。应用停掉之后,I/O明显下降。

201603080003

另一个数据库的压力也明显下降。

201603080004

至今,并没有收到创建索引的SQL,而这条SQL也再未出现。

本文固定链接: http://www.dbdream.com.cn/2016/03/%e4%b8%80%e6%ac%a1oracle%e6%95%b0%e6%8d%ae%e5%ba%93io%e5%bc%82%e5%b8%b8%e6%95%85%e9%9a%9c/ | 信春哥,系统稳,闭眼上线不回滚!

该日志由 dbdream 于2016年03月08日发表在 Oracle, oracle 10g, oracle 11g 分类下, 你可以发表评论,并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 一次ORACLE数据库IO异常故障 | 信春哥,系统稳,闭眼上线不回滚!
关键字: ,

一次ORACLE数据库IO异常故障:目前有4 条留言

  1. 板凳
    element:

    什么监控啊?

    2016-03-10 14:37 [回复]
  2. 沙发
    ELEMENT:

    EM12C ?

    2016-03-10 14:37 [回复]

发表评论

快捷键:Ctrl+Enter