很多人都知道使用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:APPADMINISTRATORORADATAORCLREDO03.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 行。
--插入一条数据
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日志用的