LOGMNR挖掘日志与DUMP日志对比
很多人都知道使用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
[sql]
--创建测试表
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日志用的
/*********************使用LOGMNR 分析日志****************************/
begin dbms_logmnr.add_logfile('G:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG',dbms_logmnr.new); end;
/
begin dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog); end;
/
--查询日志信息
select timestamp,scn,sql_redo
from v$logmnr_contents
where lower(sql_redo) like '%dump_a%' order by scn;
--查询结果如下:
TIMESTAMP SCN SQL_REDO
2013-4-26 23:30:14 1260172 insert into "SYS"."WRH$_SEG_STAT_OBJ"("SNAP_ID","DBID","TS#","OBJ#","DATAOBJ#","OWNER","OBJECT_NAME","SUBOBJECT_NAME","PARTITION_TYPE","OBJECT_TYPE","TABLESPACE_NAME","INDEX_TYPE","BASE_OBJ#","BASE_OBJECT_NAME","BASE_OBJECT_OWNER") values ('54','1341399145','4','70974','70974','SCOTT','DUMP_A',NULL,'NONE','TABLE','USERS',NULL,NULL,NULL,NULL);
只有这么一条记录吗？是的,确实在LOGMNR之后只有这么一条记录,即INSERT、UPDATE的操作都没有记录到.
忘记说了我的测试库是没有开归档的。开归档后redo日志写的多一点,可能LOGMNR得到的信息会多一些.
现在我们来分析这个INSERT、UPDATE到底有没有记录到REDO呢？我们来使用DUMP看看
[sql]
--先停止LOGMNR的日志分析
BEGIN dbms_logmnr.end_logmnr(); END;
/
--查询表的object_Id(后面分析日志时会用到)
00:45:52 sys@orclselect object_id a from dba_objects where object_name='DUMP_A';
A
-------------
70974
已选择 1 行。
--利用之前的SCN, 进行指定范围日志文件的DUMP操作
00:54:18 SYS@orcl> alter system dump logfile 'G:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG' scn min 1257368 scn max 1267898;
系统已更改。
已用时间: 00: 00: 00.10
进入trace目录,找到最近的trc文件(我这里是orcl_ora_172.trc)
打开之后,直接搜索上面查询到的object_id
部分内容如下:
CHANGE #1 TYP:0 CLS: 4 AFN:4 DBA:0x0100018b OBJ:70974 SCN:0x0000.00132a36 SEQ: 1 OP:13.28
High HWM
Highwater:: 0x01000191 ext#: 0 blk#: 8 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 5
mapblk 0x00000000 offset: 0
lfdba: 0x01000189 CHANGE #2 TYP:0 CLS: 8 AFN:4 DBA:0x01000189 OBJ:70974 SCN:0x0000.00132a36 SEQ: 1 OP:13.22
Redo on Level1 Bitmap Block
Redo to set hwm
Opcode: 32 Highwater:: 0x01000191 ext#: 0 blk#: 8 ext size: 8
#blocks in seg. hdr's freelists: 0
#blocks below: 5
mapblk 0x00000000 offset: 0
CHANGE #3 TYP:1 CLS: 1 AFN:4 DBA:0x0100018c OBJ:70974 SCN:0x0000.00133d95 SEQ: 1 OP:13.21
ktspbfredo - Format Pagetable Datablock
Parent(l1) DBA: 0x01000189 typ: 1 objd: 70974 itls: 2 fmt_flag: 0 poff: 0
CHANGE #4 TYP:1 CLS: 1 AFN:4 DBA:0x0100018d OBJ:70974 SCN:0x0000.00133d95 SEQ: 1 OP:13.21
ktspbfredo - Format Pagetable Datablock
Parent(l1) DBA: 0x01000189 typ: 1 objd: 70974 itls: 2 fmt_flag: 0 poff: 0
CHANGE #5 TYP:1 CLS: 1 AFN:4 DBA:0x0100018e OBJ:70974 SCN:0x0000.00133d95 SEQ: 1 OP:13.21
ktspbfredo - Format Pagetable Datablock
Parent(l1) DBA: 0x01000189 typ: 1 objd: 70974 itls: 2 fmt_flag: 0 poff: 0
CHANGE #6 TYP:1 CLS: 1 AFN:4 DBA:0x0100018f OBJ:70974 SCN:0x0000.00133d95 SEQ: 1 OP:13.21
ktspbfredo - Format Pagetable Datablock
Parent(l1) DBA: 0x01000189 typ: 1 objd
