「Oracle」善用日志挖掘，找出罪魁禍?zhǔn)?/h1>
概述
上周下班時(shí)突然來了一件事...某個(gè)重要的表數(shù)據(jù)全沒了!哎，有兄弟搞事情啊，雖然事后通過閃回恢復(fù)了兩個(gè)小時(shí)前的數(shù)據(jù)，但是領(lǐng)導(dǎo)還是要求查一下日志看是誰操作的。。。這里主要用日志挖掘工具logmnr來跟蹤。
01.查看日志基本信息
先了解數(shù)據(jù)庫日志情況
- select * from v$logfile;
- select * from v$log;
- select * from v$archived_log where status='A' ORDER BY FIRST_TIME DESC
這里根據(jù)故障時(shí)間點(diǎn)拿了這段時(shí)間的歸檔日志。
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 --會話管理
忘記截圖，這里就不發(fā)了，用dba權(quán)限執(zhí)行就可以。
03.建立日志分析列表
本來需要先開補(bǔ)充日志的，但是因?yàn)槭鞘潞罅耍蚤_了也沒意義。
- 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創(chuàng)建臨時(shí)表
- create table logmnr_temp nologging as select * from v$logmnr_contents;
小技巧：因?yàn)橐恢遍_著logmnr很耗資源，所以先創(chuàng)建個(gè)臨時(shí)表收集信息后就可以關(guān)閉logmnr了
06.結(jié)束logmnr
- execute dbms_logmnr.end_logmnr;
07.分析相關(guān)操作
- 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信息(之前沒有開補(bǔ)充日志)。因?yàn)橹皼]alter database add supplemental log data所以session_info是沒有信息的。
08.根據(jù)logmnr的時(shí)間字段，間接查審計(jì)
- 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'
這里嘗試了下還是不行，獲取不到更多有價(jià)值信息，只能放棄了。
嚴(yán)格來說，是一次比較失敗的日志挖掘，畢竟獲取不到相關(guān)的IP操作，無法直接定位。不過也知道了是數(shù)據(jù)庫用戶glogowner在下午3:53分執(zhí)行了delete命令導(dǎo)致，也不算一無所獲。大家如果有什么更好的辦法抓住兇手，可以在下方留言一起探討哦!
