而实际上根据业务分析确实是有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: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日志用的
，
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：PHP中文网，转转请注明出处：https://www.chuangxiangniao.com/p/1892921.html
