本篇文章也是从各个网页上搜集汲取而来,做了一个综合整理
一、logminer的用途
这个就不说了,相信会搜索到本文章看的人应该都有一些事先的了解。
二、安装logminer
安装logminer相当的简单,sqlplus / as sysdba登入到oracle服务端,然后执行以下两条SQL就可以了
$ORACLE_HOME/rdbms/admin/dbmslm.sql
$ORACLE_HOME/rdbms/admin/dbmslmd.sql
这两个脚本必须均以SYS用户身份运行。其中第一个脚本用来创建DBMS_LOGMNR包,该包用来分析日志文件。第二个脚本用来创建DBMS_LOGMNR_D包,该包用来创建数据字典文件。
三、创建数据字典文件
在使用LogMiner工具分析redo log文件之前,可以使用DBMS_LOGMNR_D 包将数据字典导出为一个文本文件。该字典文件是可选的,但是如果没有它,LogMiner解释出来的语句中关于数据字典中的部分(如表名、列名等)和数值都将是16进制的形式,我们是无法直接理解的。例如,下面的sql语句:
INSERT INTO dm_dj_swry (rydm, rymc) VALUES (00005, '张三');
LogMiner解释出来的结果将是下面这个样子:
insert into Object#308(col#1, col#2) values (hextoraw('c30rte567e436'),hextoraw('4a6f686e20446f65'));
创建数据字典的目的就是让LogMiner引用涉及到内部数据字典中的部分时为他们实际的名字,而不是系统内部的16进制。数据字典文件是一个文本文件,使用包DBMS_LOGMNR_D来创建。如果我们要分析的数据库中的表有变化,影响到库的数据字典也发生变化,这时就需要重新创建该字典文件。另外一种情况是在分析另外一个数据库文件的重作日志时,也必须要重新生成一遍被分析数据库的数据字典文件。
字典文件用于存放表及对象ID号之间的对应关系。当使用字典文件时,它会在表名和对象ID号之间建立一一对应的关系。因此需要注意,如果用户建立了新表之后,并且将来可能会对该表进行日志分析,那么就需要重新建立字典文件,以将其对象名及对象ID号存放到字典文件。
创建数据字典文件前需要指定UTL_FILE_DIR参数
alter system set UTL_FILE_DIR='/oracle/admin/bi/udump' scope=spfile;
修改完成后就可以使用dbms_logmnr_d.build来创建数据字典文件了
exec dbms_logmnr_d.build(
dictionary_filename => 'dictionary.ora',
dictionary_location => '/oracle/admin/bi/udump' );
注意:参数dictionary_filename用以指定字典文件的文件名;参数 dictionary_location用于指定存放字典文件所在的目录,该目录必须与初始化参数UTL_FILE_DIR的值一致。
另外注意,生成字典文件的步骤可能会出现下标超出限制问题:
解决方法:将TYPE col_desc_array IS VARRAY(513) OF col_description;
改成:TYPE col_desc_array IS VARRAY(713) OF col_description;
保存文件,然后执行一遍脚本
四、添加要分析的日志
Oracle的重作日志分为两种,在线(online)和离线(offline)归档日志文件,下面就分别来讨论这两种不同日志文件的列表创建。
1、分析在线重作日志文件
A. 创建列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=> '+DATA1/dpbi/onlinelog/group_1.296.727458151',
Options=>dbms_logmnr.new);
B. 添加其他日志文件到列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=> '+DATA1/dpbi/onlinelog/group_2.295.727458153',
Options=>dbms_logmnr.addfile);
2、分析离线日志文件
A.创建列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=>'+DATA2/dpbi/archivelog/2010_12_09/thread_2_seq_2416.827.737277755',
Options=>dbms_logmnr.new);
B.添加另外的日志文件到列表
SQL> EXECUTE dbms_logmnr.add_logfile(
LogFileName=>'+DATA2/dpbi/archivelog/2010_12_09/thread_1_seq_4337.697.737278241',
Options=>dbms_logmnr.addfile);
可以通过动态性能视图v$logmnr_logs查看日志分析列表中有哪些待分析的日志文件。
五、开始分析log文件
1、无限制条件
SQL> EXECUTE dbms_logmnr.start_logmnr(
DictFileName=>'/oracle/admin/bi/udump/dictionary.ora' );
2、有限制条件
通过对过程DBMS_ LOGMNR.START_LOGMNR中几个不同参数的设置(参数含义见表1),可以缩小要分析日志文件的范围。通过设置起始时间和终止时间参数我们可以限制只分析某一时间范围的日志。如下面的例子,我们仅仅分析2001年9月18日的日志:
SQL> EXECUTE dbms_logmnr.start_logmnr(
DictFileName =>'/oracle/admin/bi/udump/dictionary.ora' ,
StartTime => to_date('2010-9-18 00:00:00','YYYY-MM-DD HH24:MI:SS')
EndTime => to_date(''2010-9-18 23:59:59','YYYY-MM-DD HH24:MI:SS '));
注意:此过程能否执行成功的关键是给出的starttime(起始时间)和endtime(终止时间)应在一个有效的范围内。特别是终止时间,应小于或等于归档日志的建立时间;如果大于归档日志的建立时间,则不能执行分析过程。分析多个归档日志时,这些归档日志最好是连续
也可以通过设置起始SCN和截至SCN来限制要分析日志的范围:
SQL> EXECUTE dbms_logmnr.start_logmnr(
DictFileName => '/oracle/admin/bi/udump/dictionary.ora' ,
StartScn => 20,
EndScn => 50);
六、观察分析结果
通过查询v$logmnr_contents视图来得到logminer的分析结果。
需要强调一点的是,视图v$logmnr_contents中的分析结果仅在我们运行过程'dbms_logmrn.start_logmnr'这个会话的生命期中存在。这是因为所有的LogMiner存储都在PGA内存中,所有其他的进程是看不到它的,同时随着进程的结束,分析结果也随之消失。
最后,使用过程DBMS_LOGMNR.END_LOGMNR终止日志分析事务,此时PGA内存区域被清除,分析结果也随之不再存在。