1. [[email protected]]/oracle>df -g
2. Filesystem GB blocks Free %Used Iused %Iused Mounted on
   
3. /dev/hd4 0.50 0.28 44% 13674 17% /
   
4. /dev/hd2 3.00 0.67 78% 49208 23% /usr
   
5. /dev/hd9var 1.00 0.37 63% 9285 10% /var
   
6. /dev/hd3 2.00 1.03 49% 2407 1% /tmp
   
7. /dev/fwdump 1.
   00 0.99 2% 30 1% /var/adm/ras/platform
   
8. /dev/hd1 0.25 0.18 28% 465 2% /home
   
9. /dev/hd11admin 0.25 0.25 1% 5 1% /admin
   
10. /proc - - - - - /proc
    
11. /dev/hd10opt 0.50 0.28 44% 10241 14% /opt
    
12. /dev/livedump 0.25 0.25 1% 12 1% /var/adm/ras/livedump
    
13. /dev/oraclelv 30.00 11.29 63% 161681 6% /oracle
    
14. /dev/installlv 15.00 3.38 78% 6478 1% /install
    
15. /dev/crslv 10.
    00 3.35 67% 7807 1% /crs
    
16. /dev/wmsapplv 30.00 17.49 42% 15537 1% /wmprod
    
17. /dev/archivelv 29.25 29.25 1% 4 1% /arch1
    
18. /dev/backuplv 400.00 107.13 74% 306 1% /sysbackup
    
19. aix02:arch2 30.25 0.64 99% 3 1% /arch2

可以看到，/arch2裡檔案系統空間已經達到99%，/arch2是用來存放歸檔日誌的檔案系統，進而導致資料庫出錯。

提出問題：
這下問題來了，/arch2的空間是30G，每天備份指令碼都會自動rman備份歸檔日誌，並自動清除歸檔日誌檔案，按照正常情況下，資料庫不可能一天產生這麼大的歸檔日誌量。

如何查詢歸檔日誌都是由什麼應用產生的，這就是logminer的用途。

使用方法：

1. -- 1.指定要分析的日誌檔案
   
2. exec sys.dbms_logmnr.add_logfile(logfilename => '/arch2/2_825_733092736.dbf',options => dbms_logmnr.new);
   
3. -- 2.使用本地的線上資料字典分析歸檔日誌
   
4. exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);
   
5. -- 3.查詢分析出來的歸檔日誌內容，例如統計最大修改量的Schema
   
6. select seg_owner,count(*) from v$logmnr_contents group by seg_owner;
   
7. -- 4.增加別的日誌檔案
   
8. exec sys.dbms_logmnr.add_logfile(logfilename=>'/arch2/2_825_733092736.dbf');
   
9. -- 5.結束分析歸檔日誌
   
10. exec sys.dbms_logmnr.end_logmnr;

下面是具體的過程：

1. SQL> exec sys.dbms_logmnr.add_logfile(logfilename => '/arch2/2_825_733092736.dbf',options => dbms_logmnr.new);
   
2. PL/SQL procedure successfully completed
   
3. SQL> exec sys.dbms_logmnr.start_logmnr(options => sys.dbms_logmnr.dict_from_online_catalog);
   
4. PL/SQL procedure successfully completed 

結論：
從上面查詢結果可以看出操作量最大的使用者是WAS使用者，再具體看下v$logmnr_contents可以發現基本修改的內容是一致的。
與開發人員溝通後，最終確認是一個執行update過程存在問題，where條件未正確定位到記錄，每執行一次都會導致大規模的修改資料。

延伸：
LogMiner使用示例