而实际上根据业务分析确实是有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 行。
--插入一条数据
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日志用的
，