@$ORACLE_HOME\rdbms\admin\dbmslm.sql;
@ $ORACLE_HOME\rdbms\admin\dbmslmd.sql;
第一个脚本用来创建DBMS_LOGMNR包,该包用来分析日志文件。
第二个脚本用来创建DBMS_LOGMNR_D包,该包用来创建数据字典文件。
二、使用LogMiner工具
下面将详细介绍如何使用LogMiner工具。
1、创建数据字典文件(data-dictionary)
1).首先在init.ora初始化参数文件中,指定数据字典文件的位置,也就是添加一个参数UTL_FILE_DIR,该参数值为服务器中放置数据字典文件的目录。如:UTL_FILE_DIR = ($ORACLE_HOME\logs) ,重新启动数据库,使新加的参数生效:
2).然后创建数据字典文件
SQL> connect /as sysdba
SQL> execute dbms_logmnr_d.build(dictionary_filename => 'dict.ora',dictionary_location => 'G:\oracle\logs');
PL/SQL procedure successfully completed
2、创建要分析的日志文件列表
1).创建分析列表,即所要分析的日志
SQL> execute dbms_logmnr.add_logfile(LogFileName => 'G:\ORACLE\ORADATA\ORADBSP\REDO04.LOG',Options => dbms_logmnr.new);
PL/SQL procedure successfully completeds
2).添加分析日志文件,一次添加1个为宜
SQL> execute dbms_logmnr.add_logfile(LogFileName => 'G:\ORACLE\ORADATA\ORADBSP\REDO05.LOG',Options => dbms_logmnr.ADDFILE);
PL/SQL procedure successfully completed
3、使用logMiner进行日志分析
1).无限制条件,即用数据字典文件对要分析的日志文件所有内容做分析
SQL> execute dbms_logmnr.start_logmnr(DictFileName => 'G:\oracle\logs\dict.ora');
PL/SQL procedure successfully completed
2).带限制条件,可以用scn号或时间做限制条件,也可组合使用
--分析日志列表中时间从07.02.28从10:00到15:00的内容
SQL> execute dbms_logmnr.start_logmnr(startTime => to_date('20070228100000','yyyy-mm-dd hh24:mi:ss'),endTime => to_date('20070228150000','yyyy-mm-dd hh24:mi:ss'),DictFileName => 'G:\oracle\logs\dict.ora');
PL/SQL procedure successfully completed
dbms_logmnr.start_logmnr函数的原型为:
PROCEDURE start_logmnr(
startScn IN NUMBER default 0 ,
endScn IN NUMBER default 0,
startTime IN DATE default '',
endTime IN DATE default '',
DictFileName IN VARCHAR2 default '',
Options IN BINARY_INTEGER default 0 );
4.分析后释放内存
SQL> execute dbms_logmnr.end_logmnr;
PL/SQL procedure successfully completed
5.其它
1).删除日志分析文件
exec dbms_logmnr.add_logfile('G:\ORACLE\ORADATA\ORADBSP\REDO04.LOG',dbms_logmnr.removefile);
三、查看LogMiner工具分析结果
SQL> select * from dict t where t.table_name like '%LOGMNR%';--看所有与logmnr相关的视图
TABLE_NAME COMMENTS
------------------------------ --------------------------------------------------------------------------------
GV$LOGMNR_CALLBACK Synonym for GV_$LOGMNR_CALLBACK
GV$LOGMNR_CONTENTS Synonym for GV_$LOGMNR_CONTENTS
GV$LOGMNR_DICTIONARY Synonym for GV_$LOGMNR_DICTIONARY
GV$LOGMNR_LOGFILE Synonym for GV_$LOGMNR_LOGFILE
GV$LOGMNR_LOGS Synonym for GV_$LOGMNR_LOGS
GV$LOGMNR_PARAMETERS Synonym for GV_$LOGMNR_PARAMETERS
GV$LOGMNR_PROCESS Synonym for GV_$LOGMNR_PROCESS
GV$LOGMNR_REGION Synonym for GV_$LOGMNR_REGION
GV$LOGMNR_SESSION Synonym for GV_$LOGMNR_SESSION
GV$LOGMNR_STATS Synonym for GV_$LOGMNR_STATS
GV$LOGMNR_TRANSACTION Synonym for GV_$LOGMNR_TRANSACTION
V$LOGMNR_CALLBACK Synonym for V_$LOGMNR_CALLBACK
V$LOGMNR_CONTENTS Synonym for V_$LOGMNR_CONTENTS
V$LOGMNR_DICTIONARY Synonym for V_$LOGMNR_DICTIONARY
V$LOGMNR_LOGFILE Synonym for V_$LOGMNR_LOGFILE
V$LOGMNR_LOGS Synonym for V_$LOGMNR_LOGS
V$LOGMNR_PARAMETERS Synonym for V_$LOGMNR_PARAMETERS
V$LOGMNR_PROCESS Synonym for V_$LOGMNR_PROCESS
V$LOGMNR_REGION Synonym for V_$LOGMNR_REGION
V$LOGMNR_SESSION Synonym for V_$LOGMNR_SESSION
TABLE_NAME COMMENTS
------------------------------ --------------------------------------------------------------------------------
V$LOGMNR_STATS Synonym for V_$LOGMNR_STATS
V$LOGMNR_TRANSACTION Synonym for V_$LOGMNR_TRANSACTION
GV$LOGMNR_LOGS 是分析日志列表视图
分析结果在GV$LOGMNR_CONTENTS 视图中,可按以下语句查询:
select scn,timestamp,log_id,seg_owner,seg_type,table_space,data_blk#,data_obj#,data_objd#,
session#,serial#,username,session_info,sql_redo,sql_undo
from logmnr3 t
where t.sql_redo like 'create%';
如果不能正常查询GV$LOGMNR_CONTENTS视图,并报以下错误,ORA-01306: 在从 v$logmnr_contents 中选择之前必须调用 dbms_logmnr.start_logmnr() 。可采用如下方法:
create table logmnr3 as select * from GV$LOGMNR_CONTENTS;
FAQ:
1.创建数据字典的目 : 让LogMiner引用涉及到内部数据字典中的部分时为他们实际的名字,而不是系统内部的16进制。数据字典文件是一个文本文件,使用包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'));
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
2 1 100 52428800 1 NO CURRENT 12729697 01-JUL-09
SQL> SELECT MEMBER from v$logfile where group#=2;
MEMBER
------------------------------------------------------------------------------------------------------------------------
/opt/oracle/oradata/mmstest/redo02.log
SQL> exec dbms_logmnr.add_logfile('/opt/oracle/oradata/mmstest/redo02.log',dbms_logmnr.new);
PL/SQL procedure successfully completed.
SQL> exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
PL/SQL procedure successfully completed.
SQL> select count(*) from v$logmnr_contents;
COUNT(*)
----------
136
SQL> select sql_redo from v$logmnr_contents;
SQL_REDO
------------------------------------------------------------------------------------------------------------------------
set transaction read write;
insert into "SYS"."OBJ$"("OBJ#","DATAOBJ#","OWNER#","NAME","NAMESPACE","SUBNAME","TYPE#","CTIME","MTIME","STIME","STATUS
","REMOTEOWNER","LINKNAME","FLAGS","OID$","SPARE1","SPARE2","SPARE3","SPARE4","SPARE5","SPARE6") values ('25847','25847'
,'31','EYGLE','1',NULL,'2',TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-MON-RR'),TO_DATE('01-JUL-09', 'DD-
MON-RR'),'1',NULL,NULL,'0',NULL,'6','1',NULL,NULL,NULL,NULL);
Unsupported
update "SYS"."TSQ$" set "TS#" = '0', "GRANTOR#" = '43080', "BLOCKS" = '0', "MAXBLOCKS" = '0', "PRIV1" = '0', "PRIV2" = '
0' where "TS#" = '0' and "GRANTOR#" = '43072' and "BLOCKS" = '0' and "MAXBLOCKS" = '0' and "PRIV1" = '0' and "PRIV2" = '
0' and ROWID = 'AAAAAKAABAAAABbAAF';
commit;
set transaction read write;
SQL> exec dbms_logmnr.end_logmnr
PL/SQL procedure successfully completed.
很早以前就碰到这个问题,一直以为是由于没有设置FORCE_LOGGING的问题,今天才发现不是这个问题。
问题起源是在10g的版本上使用LOGMNR找不到刚刚执行的DML操作:
SQL> SELECT GROUP#, SEQUENCE#, STATUS FROM V$LOG;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 245 INACTIVE
2 246 INACTIVE
3 247 CURRENT
SQL> SELECT GROUP#, MEMBER FROM V$LOGFILE;
GROUP# MEMBER
---------- --------------------------------------------------
3 E:ORACLEORADATAYTK102REDO03.LOG
2 E:ORACLEORADATAYTK102REDO02.LOG
1 E:ORACLEORADATAYTK102REDO01.LOG
SQL> DROP TABLE T PURGE;
表已删除。
SQL> CREATE TABLE T (ID NUMBER);
表已创建。
SQL> INSERT INTO T VALUES (1);
已创建 1 行。
SQL> COMMIT;
提交完成。
SQL> ALTER SYSTEM SWITCH LOGFILE;
系统已更改。
SQL> EXEC SYS.DBMS_LOGMNR.ADD_LOGFILE('E:ORACLEORADATAYTK102REDO03.LOG', SYS.DBMS_LOGMNR.NEW)
PL/SQL 过程已成功完成。
SQL> EXEC SYS.DBMS_LOGMNR.START_LOGMNR(OPTIONS => SYS.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG)
PL/SQL 过程已成功完成。
SQL> SELECT SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = USER AND TABLE_NAME = 'T';
SQL_REDO
------------------------------------------------------------------
CREATE TABLE T (ID NUMBER);
SQL> EXEC SYS.DBMS_LOGMNR.END_LOGMNR
PL/SQL 过程已成功完成。
SQL> SELECT * FROM V$VERSION;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
本来一直是认为是没有设置FORCE_LOGGING,导致部分记录没有在REDO文件中被记录,结果查询V$DATABASE确发现当前正是FORCE LOGGING状态:
SQL> SELECT FORCE_LOGGING FROM V$DATABASE;
FOR
---
YES
同样的问题从没有在9i上发生过,说明应该是Oracle10g的某些改变导致了问题的产生。
查询了metalink,Oracle在文档Doc ID: Note:291574.1中对这个问题进行了详细说明,如果希望LOGMNR可以得到记录,应该设置SUPPLEMENTAL LOG DATA PRIMARY KEY和UNIQUE INDEX,这样Oracle才能确保LOGMNR可以获取SQL语句:
SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI FROM V$DATABASE;
SUP SUP
--- ---
NO NO
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
数据库已更改。
SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI FROM V$DATABASE;
SUP SUP
--- ---
YES YES
SQL> SELECT GROUP#, SEQUENCE#, STATUS FROM V$LOG;
GROUP# SEQUENCE# STATUS
---------- ---------- ----------------
1 248 CURRENT
2 246 INACTIVE
3 247 INACTIVE
SQL> DROP TABLE T PURGE;
表已删除。
SQL> CREATE TABLE T (ID NUMBER);
表已创建。
SQL> INSERT INTO T VALUES (1);
已创建 1 行。
SQL> COMMIT;
提交完成。
SQL> ALTER SYSTEM SWITCH LOGFILE;
系统已更改。
SQL> EXEC SYS.DBMS_LOGMNR.ADD_LOGFILE('E:ORACLEORADATAYTK102REDO01.LOG', SYS.DBMS_LOGMNR.NEW)
PL/SQL 过程已成功完成。
SQL> EXEC SYS.DBMS_LOGMNR.START_LOGMNR(OPTIONS => SYS.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG)
PL/SQL 过程已成功完成。
SQL> SELECT SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = USER AND TABLE_NAME = 'T';
SQL_REDO
----------------------------------------------------------------------------------
DROP TABLE T PURGE;
CREATE TABLE T (ID NUMBER);
insert into "YANGTK"."T"("ID") values ('1');
SQL> EXEC SYS.DBMS_LOGMNR.END_LOGMNR
PL/SQL 过程已成功完成。
可以看到,在10g中默认情况下LOGMNR已经不是一个可靠的数据获取的方式,希望通过这种方式获取丢失数据,则需要提前设置SUPPLEMENTAL LOG DATA。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22123669/viewspace-674845/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/22123669/viewspace-674845/