1818IP-服务器技术教程,云服务器评测推荐,服务器系统排错处理,环境搭建,攻击防护等

当前位置:首页 - 数据库 - 正文

君子好学,自强不息!

概述

上周下班时突然来了一件事…某个重要的表数据全没了!哎,有兄弟搞事情啊,虽然事后通过闪回恢复了两个小时前的数据,但是领导还是要求查一下日志看是谁操作的。。。这里主要用日志挖掘工具logmnr来跟踪。

01.查看日志基本信息

先了解数据库日志情况

select*fromv$logfile;
select*fromv$log;
select*fromv$archived_logwherestatus='A'ORDERBYFIRST_TIMEDESC

「Oracle」善用日志挖掘,找出罪魁祸首

这里根据故障时间点拿了这段时间的归档日志。

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.建立日志分析列表

本来需要先开补充日志的,但是因为是事后了,所以开了也没意义。

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

「Oracle」善用日志挖掘,找出罪魁祸首

04.开启logmnr

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

05创建临时表

createtablelogmnr_tempnologgingasselect*fromv$logmnr_contents;

小技巧:因为一直开着logmnr很耗资源,所以先创建个临时表收集信息后就可以关闭logmnr了

06.结束logmnr

executedbms_logmnr.end_logmnr;

「Oracle」善用日志挖掘,找出罪魁祸首

07.分析相关操作

SELECTscn,
timestamp,
sql_redo,
sql_undo,
operation,
seg_name,
table_name,
username,
os_username,
session_info
FROMsys.logmnr_temp
WHERETABLE_NAME='FSL_RDC_PLANT_MAPPING'orderbytimestamp;

「Oracle」善用日志挖掘,找出罪魁祸首

好吧,到这里功亏一篑,只记录到操作的用户,但是没有具体的IP信息(之前没有开补充日志)。因为之前没alter database add supplemental log data所以session_info是没有信息的。

08.根据logmnr的时间字段,间接查审计

selectsessionid,userid,userhost,comment$text,spare1,cast(/*TIMESTAMP*/(from_tz(ntimestamp#,'00:00')atlocal)asdate)fromsys.aud$whereOBJ$NAME='FSL_RDC_PLANT_MAPPING'

「Oracle」善用日志挖掘,找出罪魁祸首

这里尝试了下还是不行,获取不到更多有价值信息,只能放弃了。

严格来说,是一次比较失败的日志挖掘,毕竟获取不到相关的IP操作,无法直接定位。不过也知道了是数据库用户glogowner在下午3:53分执行了delete命令导致,也不算一无所获。大家如果有什么更好的办法抓住凶手,可以在下方留言一起探讨哦!

本文来源:1818IP

本文地址:https://www.1818ip.com/post/10875.html

免责声明:本文由用户上传,如有侵权请联系删除!

发表评论

必填

选填

选填

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。