概述
上周下班时突然来了一件事...某个重要的表数据全没了!哎,有兄弟搞事情啊,虽然事后通过闪回恢复了两个小时前的数据,但是领导还是要求查一下日志看是谁操作的。。。这里主要用日志挖掘工具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命令导致,也不算一无所获。大家如果有什么更好的办法抓住凶手,可以在下方留言一起探讨哦!
首先给扑克牌中每张牌设定一个编号,下面算法实现的编号规则如下: u 红桃按照从...
今日国内领先的智能数据服务运营商觉非科技完成近亿元A轮融资。本轮融资由和高资...
大家好,今天我们来简单的聊一聊缓存问题。什么是缓存呢?它在系统设计中是在一个...
从功能测试、性能测试、界面测试、安全性测试、易用性、兼容性测试、震动测试七...
一、MVC MVC模式的意思是,软件可以分成三个部分。 视图(View):用户界面。 控...
前言 关于Window,你了解多少呢?看看下面这些问题你都能答上来吗。 如果你遇到这...
我们知道微软将会在今年给Windows10更换全新设计的UI,让Windows10的界面更加整...
git工作区,暂存区,版本库之间的关系: 我们建立的项目文件夹就是工作区,在初...
本文实例讲述了jsp中page指令用法。分享给大家供大家参考。具体如下: 一、JSP ...
一、简介 本设计为硬币图像识别统计装置通过数码相机获取平铺无重叠堆积的硬币的...