今天下午收到一條報警郵件
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進行充分的溝通。
![Oracle的基本操作[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)