生產案例：忽然產生大量的歸檔日誌，致使磁盤空間滿了沒法登錄數據庫

早上吃完早飯打開電腦，忽然告知數據庫沒法登錄，立刻打開終端鏈接數據庫，報以下錯誤

sqlplus / as sysdba
ERROR:
ORA-09817: Write to audit file failed.
SVR4 Error: 28: No space left on device
ORA-01075: you are currently logged on

很明顯幾個單詞NO SPACE，趕緊看系統df -h 果真100%沒了，第一反應，是歸檔日誌佔滿了空間，數據庫不會增加那麼快，因此到歸檔日誌目錄裏發現不少不少歸檔日誌；

爲了讓業務人員能立刻連上數據庫使用，先手動刪除了部分歸檔日誌，騰出一點點空間，可是沒多久空間又滿了，而後去看歸檔日誌目錄，發現每一個6秒就要生成一個歸檔日誌文件，每個文件大小187M，這很嚇人，

分分鐘就把磁盤佔滿。

 

立刻查看天天的歸檔日誌量，發現昨天到今天，天天大概有600多G，而平時差很少1g不到，立刻就問業務最近在作什麼操做，說他們在把其它業務遷移過來，問題大概知道了，就是由於遷移這個來出問題了。

SELECT TRUNC(FIRST_TIME) "TIME",
SUM(BLOCK_SIZE * BLOCKS) / 1024 / 1024 / 1024 "SIZE(GB)"
FROM V$ARCHIVED_LOG
GROUP BY TRUNC(FIRST_TIME);

 

查看都是最近兩天的歸檔日誌，並無過時的。

select * from v$archived_log

 

問題排查一，看alert告警日誌

查看alter日誌後，發現並無什麼異常，只是裏面歸檔很快，伴有日誌切換等待，

因此我查看了日誌組大小，發現是三個組，每一個組200M，應該是夠了，爲了保險，我增長了兩組。

select group#,sequence#,bytes/1024/1024,members,status from v$log; 
 
alter database add logfile group 4 ('/oradata/hhfz/redo04.log') size 200M;
alter database add logfile group 5 ('/oradata/hhfz/redo05.log') size 200M;

 

最後仍是沒有改變歸檔日誌頻率大的問題，因此應該不是這裏問題，這不能無休止增長日誌組。

 

問題排查二，logminer查看歸檔日誌

究竟是什麼產生的呢？看看日誌寫的是啥，因此用oracle自帶的logminer查看了一下

--建立logminer數據字典表
@?/rdbms/admin/dbmslm.sql;
@?/rdbms/admin/dbmslmd.sql;
--執行要分析的歸檔日誌
exec sys.dbms_logmnr.add_logfile(logfilename => '/oradata/hhfz_arch/1_5056_912160774.arc',options => dbms_logmnr.new);
exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);
--查詢 歸檔日誌的內容
select seg_owner,count(*) from v$logmnr_contents group by seg_owner;
select count(1),substr(sql_redo,1,60) from v$logmnr_contents group by substr(sql_redo,1,60) order by count(1) desc ;
--增長別的日誌文件
exec sys.dbms_logmnr.add_logfile(logfilename=>'/oradata/hhfz_arch/1_5056_912160774.arc');
exec sys.dbms_logmnr.add_logfile(logfilename=>'/oradata/hhfz_arch/1_4986_912160774.arc');
--結束分析歸檔日誌
exec sys.dbms_logmnr.end_logmnr;

 最後查出一些sql，可是業務以爲這些sql不算大，因此並不以爲有啥問題。我也感受，雖然一直同一個SQL在插入，可是這點應該能承受纔對。

 

問題排查三，AWR分析

等了幾個小時，AWR的時間點也有了，因此抽取了一個小時的AWR查看，

load profile裏的redo size很大，由於有一直在產生歸檔日誌，確定是日質量很大，因此這點想獲得

 

TOP10 的log file sync很大，也正常，由於日誌切換很頻繁，因此都是同個問題引發的。

 

而後看下面的SQL語句排序，不少個指標不管執行次數與時間，一眼就看出問題來了。立刻找業務查該SQL，最後果真是代碼裏BUG致使，每一條數據都要全表update。

 

 

修改BUG後，問題解決，一切恢復正常。