生產案例：突然產生大量的歸檔日誌，導致磁碟空間滿了無法登陸資料庫

早上吃完早飯開啟電腦，突然告知資料庫無法登陸，馬上開啟終端連線資料庫，報如下錯誤

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後，問題解決，一切恢復正常。