[[266476]]

概述

上周下班時突然來了一件事...某個重要的表數據全沒了!哎，有兄弟搞事情啊，雖然事后通過閃回恢復了兩個小時前的數據，但是領導還是要求查一下日志看是誰操作的。。。這里主要用日志挖掘工具logmnr來跟蹤。

01.查看日志基本信息

先了解數據庫日志情況

select * from v$logfile; 
select * from v$log; 
select * from v$archived_log where status='A' ORDER BY FIRST_TIME DESC  

這里根據故障時間點拿了這段時間的歸檔日志。

02.安裝logmnr

@$ORACLE_HOME/rdbms/admin/dbmslm.sql:DBMS_LOGMNR 
@$ORACLE_HOME/rdbms/admin/dbmslmd.sql:DBMS_LOGMNR_D 
@$ORACLE_HOME/rdbms/admin/dbmslms.sql --會話管理 

忘記截圖，這里就不發了，用dba權限執行就可以。

03.建立日志分析列表

本來需要先開補充日志的，但是因為是事后了，所以開了也沒意義。

execute dbms_logmnr.add_logfile(logfilename=>'+RFDATA/rfdb/archivelog/2019_05_24/thread_1_seq_63614.749.1009132933',options=>dbms_logmnr.new); 
execute dbms_logmnr.add_logfile(logfilename=>'+RFDATA/rfdb/archivelog/2019_05_24/thread_2_seq_56388.526.1009131229',options=>dbms_logmnr.addfile); 
execute dbms_logmnr.add_logfile(logfilename=>'+RFDATA/rfdb/archivelog/2019_05_24/thread_1_seq_63613.753.1009129303',options=>dbms_logmnr.addfile); 
execute dbms_logmnr.add_logfile(logfilename=>'+RFDATA/rfdb/archivelog/2019_05_24/thread_2_seq_56387.897.1009126625',options=>dbms_logmnr.addfile); 
execute dbms_logmnr.add_logfile(logfilename=>'+RFDATA/rfdb/archivelog/2019_05_24/thread_2_seq_56386.693.1009123411',options=>dbms_logmnr.addfile); 
execute dbms_logmnr.add_logfile(logfilename=>'+RFDATA/rfdb/archivelog/2019_05_24/thread_1_seq_63612.512.1009125633',options=>dbms_logmnr.addfile); 
execute dbms_logmnr.add_logfile(logfilename=>'+RFDATA/rfdb/archivelog/2019_05_24/thread_2_seq_56385.727.1009123111',options=>dbms_logmnr.addfile); 

04.開啟logmnr

execute dbms_logmnr.start_logmnr(Options=>dbms_logmnr.dict_from_online_catalog); 

05創建臨時表

create table logmnr_temp nologging as select * from v$logmnr_contents; 

小技巧：因為一直開著logmnr很耗資源，所以先創建個臨時表收集信息后就可以關閉logmnr了

06.結束logmnr

execute dbms_logmnr.end_logmnr; 

07.分析相關操作

SELECT scn, 
 timestamp, 
 sql_redo, 
 sql_undo, 
 operation, 
 seg_name, 
 table_name, 
 username, 
 os_username, 
 session_info 
 FROM sys.logmnr_temp  
 WHERE TABLE_NAME='FSL_RDC_PLANT_MAPPING' order by timestamp; 

好吧，到這里功虧一簣，只記錄到操作的用戶，但是沒有具體的IP信息(之前沒有開補充日志)。因為之前沒alter database add supplemental log data所以session_info是沒有信息的。

08.根據logmnr的時間字段，間接查審計

select sessionid, userid, userhost, comment$text, spare1,cast (/* TIMESTAMP */(from_tz(ntimestamp#,'00:00') at local) as date) from sys.aud$ where OBJ$NAME='FSL_RDC_PLANT_MAPPING' 

這里嘗試了下還是不行，獲取不到更多有價值信息，只能放棄了。

嚴格來說，是一次比較失敗的日志挖掘，畢竟獲取不到相關的IP操作，無法直接定位。不過也知道了是數據庫用戶glogowner在下午3:53分執行了delete命令導致，也不算一無所獲。大家如果有什么更好的辦法抓住兇手，可以在下方留言一起探討哦!