一条空间不足报警的分析

今天下午收到一条报警邮件
ZABBIX-监控系统:
------------------------------------
报警内容: Free disk space is less than 20% on volume /U01
------------------------------------
报警级别: PROBLEM
------------------------------------
监控项目: Free disk space on /U01 (percentage)：9.7 %
------------------------------------
报警时间:2015.10.27-18:08:49
对于目前的监控情况还算是比较稳定的，突然出现这个问题感觉还是有些奇怪。
这个环境是一个数据量也不大，负载也不高的环境，于是引起了我的重视。
首先就是查看DB time的情况,没有发现异常。
BEGIN_SNAP   END_SNAP SNAPDATE     DURATION_MINS     DBTIME
---------- ---------- ------------------------------- ----------
     17867      17868 27 Oct 2015 11:00    60      15
     17868      17869 27 Oct 2015 12:00    60      15
     17869      17870 27 Oct 2015 13:00    60      15
     17870      17871 27 Oct 2015 14:00    60      15
     17871      17872 27 Oct 2015 15:00    60      15
     17872      17873 27 Oct 2015 16:00    60      15
     17873      17874 27 Oct 2015 17:00    59      36
看来这个问题似乎被平均了，来查看实时的DB time情况。

可以看到在短时间内确实有了很大的提升，但是还没有达到阀值，所以没有报警，这种变化似乎也是可以接受的。
这个时候查看归档的情况，因为数据变更很小，50M的redo平时切换都不多，结果这个时候一看。
sh showarchrate.sh
DBNAME    TIME_STAMP
--------- ------------------------------------------------------------
DOOP    2015-Oct-27 18:16:39
    GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1     104404          1         50 YES ACTIVE
         2          1     104405          1         50 NO  ACTIVE
         3          1     104406          1         50 NO  CURRENT
在短短的10分钟，redo切换竟然达到了400多次。
问题到这个程度，想不重视都难，来看看是否是因为sql语句导致。结果发现有几条sql语句还是存在明显的问题。
$ sh showsnapsql.sh 17874
   SNAP_ID SQL_ID        EXECUTIONS_DELTA ELAPSED_TI PER_TOTAL
---------- ------------- ---------------- ---------- ----------
     17874 0j7ntjx8km98j                72  576s       26%
     17874 6bz586uwmw2ry               0 582s       26%
     17874 3y93ywsfgbsnx                 0 558s       25%
     17874 cwq7h73hmda0p               12 108s       5%
     17874 ckv5fwgrvsx4j                   12 79s        3%
第一条语句是一个关联delete，目前来看性能尚可接受
第二，第三条的语句竟然是
create table test_login_bak as select * from t_login t
create table _test_heart_bak as select * from t_heart t
这种操作明显不是程序端发过来的，但是得确认一下，从ash里面看看。发现是一个PL/SQL Dev操作的，哪个客户端一目了然。
sh showsqlsess.sh 6bz586uwmw2ry
SESSION_ID SESSION_TY USERNAME   PROGRAM              MODULE               ACTION      MACHINE
---------- ---------- -------------------- ------- -------------------- -------------------- ---------- ------------------------------
      1993 FOREGROUND TEST_BI     plsqldev.exe         PL/SQL Developer     SQL Window- Query data of table TEST-INC\TEST5431
问题到了这个程度也就很明显了，这种操作就是不太合理的，因为数据量都在亿级，这种操作真是让人胆战心惊啊。
而且关键使用的用户竟然是属主用户，因为为了隔离权限，所有开发人员的账户都是一个连接用户，通过同义词来访问，这个时候看似这位同学不知怎么拿到了密码，直接来操作了。
当我们准备联系开发的同学时，发现产生的日志量更大了。
使用脚本来跟踪，发现top SQL变了，所以赶紧联系他们，想他们了解他们需要做什么工作。
有一条新增的语句
SQL_FULLTEXT
-----------------------------
delete from t_heart t
最后得到的反馈是需要数据清理。好吧，这种事情还是需要DBA来帮着把把关。
迅速沟通后，就先终止了这个过程。这个时候redo切换了近900多次。
通过上面的案例，可以看到其实还是需要对一些操作进行规范和限制，保证在DBA的工作中不会有太多节外生枝的事情，而且这个部分也需要开发和DBA进行充分的沟通。