概述

上周下班时突然来了一件事...某个重要的表数据全没了!哎，有兄弟搞事情啊，虽然事后通过闪回恢复了两个小时前的数据，但是领导还是要求查一下日志看是谁操作的。。。这里主要用日志挖掘工具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命令导致，也不算一无所获。大家如果有什么更好的办法抓住凶手，可以在下方留言一起探讨哦!