一、最常用的日志挖掘方式

日志挖掘可以在源庫進行，也可以在其他目標庫進行，但需要注意必須是同構操作系統、數據庫版本要大于等于源庫，字符集也需相同。

最常用的還是在源庫加載歸檔日志進行挖掘。

二.操作案例

2.1 程序異常造成誤刪除記錄

某系統應用程序BUG，造成數據庫丟失了幾千條數據，但程序上沒有找到對應的刪除SQL，需通過日志挖掘定位數據刪除的具體操作、時間點等信息。

打開補充日志：

圖片

2.2 確認出現問題的時間點

根據業務排查，第一次出現問題的時間點應該在6月5日上午08:30分左右，最后問題時間在6月5日下午17:00左右。

2.3 從數據庫視圖中查看問題時間段歸檔的序號

圖片

2.4 恢復已刪除的歸檔

當前系統備份由NBU接管，歸檔備份存儲在NBU的存儲上，沒有在數據庫本地，所以恢復時分配通道時要指定NBU相關的環境變量并創建一個本地目錄用于存放恢復的歸檔。

圖片

2.5 加載歸檔文件

第一個加載的歸檔文件需要使用DBMS_LOGMNR.NEW，后面的不需要。

圖片

2.6 執行分析

exec DBMS_LOGMNR.START_LOGMNR(OPTIONS=>DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

2.7 保存分析的數據

由于涉及了多張表的操作，并且數據較多，在存儲空間允許的情況下，最好是創建一張臨時表存放挖掘出的數據，由于數據量較大，可以對表名和操作類型創建聯合索引，避免查詢太慢。

圖片

2.8 結束挖掘

execute dbms_logmnr.end_logmnr;

2.9 按表名和類型檢查操作

圖片

可以看到，從6月5日8:29開始，總共被刪除了4000多條記錄。

username，machine等字段為UNKONWN，是由于問題時間段沒有開啟補充日志，如果啟用了還是顯示UNKNOWN，那么可能是缺少登錄信息，即在挖掘的時間段之前會話已登錄了。

注意，這里查詢出的SQL并不是和實際執行的SQL完全一致的，是經過數據庫轉換過的SQL。