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

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

经过查询发现，消耗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由一个数据同步程序发出。

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

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

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

本文固定链接: https://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/ | 信春哥，系统稳，闭眼上线不回滚！