ITPub博客

首页 > 数据库 > Oracle > 一条空间不足报警的分析

一条空间不足报警的分析

原创 Oracle 作者:jeanron100 时间:2015-10-27 20:13:04 3 删除 编辑
今天下午收到一条报警邮件
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进行充分的沟通。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-1816845/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
技术文章每天更新,阵地已转移到微信公众号端。 公众号:jianrong-notes

注册时间:2012-05-14

  • 博文量
    1498
  • 访问量
    14405278