今天下午收到一条报警邮件 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 cwq7h73h
mda0p 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-INCTEST5431 问题到了这个程度也就很明显了，这种操作就是不太合理的，因为数据量都在亿级，这种操作真是让人胆战心惊啊。 而且关键使用的用户竟然是属主用户，因为为了隔离权限，所有开发人员的账户都是一个连接用户，通过同义词来访问，这个时候看似这位同学不知怎么拿到了密码，直接来操作了。 当我们准备联系开发的同学时，发现产生的日志量更大了。 使用脚本来跟踪，发现top SQL变了，所以赶紧联系他们，想他们了解他们需要做什么工作。 有一条新增的语句 SQL_FULLTEXT ----------------------------- delete from t_heart t 最后得到的反馈是需要数据清理。好吧，这种事情还是需要DBA来帮着把把关。 迅速沟通后，就先终止了这个过程。这个时候redo切换了近900多次。
通过上面的案例，可以看到其实还是需要对一些操作进行规范和限制，保证在DBA的工作中不会有太多节外生枝的事情，而且这个部分也需要开发和DBA进行充分的沟通。
