Oracle LOGMNR挖掘日志与DUMP日志对比

而实际上根据业务分析确实是有UPDATE操作的(注意这里我也想过会有ROWID改变的情况,譬如发生行迁移等,但根据SCN及ROWID的检测发现

很多人都知道使用logmnr来分析日志,但是很少有人来使用dump来分析日志,具体是因为logmnr分析出来的信息方便查阅,也便于理解.

但是有些时候我们还是需要DUMP来分析日志文件,因为它记录的更详细,更真实。(其实一般的LOGMNR分析的日志不是很全的)

有次LOGMNR日志分析后,我发现挖掘的信息十分诡异,我是根据ROWID查询LOGMNR分析出来的记录的,发现某个ROWID有INSERT、DELETE,却没有UPDATE操作,

而实际上根据业务分析确实是有UPDATE操作的(注意这里我也想过会有ROWID改变的情况,譬如发生行迁移等,但根据SCN及ROWID的检测发现ROWID根本没有改变),于是我开始怀疑LOGMNR分析日志的正确性，我开始了一个小测验来验证我的想法,测验如下:

首先查到现在使用的日志文件

select a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;

得到当前活动(CURRENT)的日志文件为:G:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG

--创建测试表

00:41:20 scott@orcl> create table dump_a(id number,tt varchar2(20));

表已创建。

已用时间:  00: 00: 00.40

--当前的SCN号

00:41:22 scott@orcl> select dbms_flashback.get_system_change_number() a from dual;

              A
-------------
 1257368

已选择 1 行。

燕雀Logo

为用户提供LOGO免费设计在线生成服务

101

查看详情

--插入一条数据

00:42:47 scott@orcl> insert into dump_a values(1,'w');

已创建 1 行。

已用时间:  00: 00: 00.11

--更新一条数据
00:43:44 scott@orcl> update dump_a set id=2 where id=1;

已更新 1 行。

已用时间:  00: 00: 00.14

--现在的SCN号

00:43:52 scott@orcl> select dbms_flashback.get_system_change_number() a from dual;

              A
-------------
 1267898

已选择 1 行。

--以上记SCN号是为了DUMP日志用的