delete from "C"."A" where "C1" = ‘gototop’ and ROWID = 'AAABg1AAFAAABQaAAH';
如果没有字典文件，LogMiner分析出来的结果将是：
delete from "UNKNOWN"."OBJ# 6197" where "COL 1" = HEXTORAW('d6a7d4ae') and ROWID
 = 'AAABg1AAFAAABQaAAH';

SQL> show parameter utl
NAME                         TYPE        VALUE
------------------------ ----------- ------------------------------
utl_file_dir                 string      /data6/cyx/logmnr

exec dbms_logmnr_d.build(dictionary_filename =>'
dic.ora',dictionary_location => '/data6/cyx/logmnr');

exec dbms_logmnr_d.build('dic.ora','/data6/cyx/logmnr');

ERROR at line 1:
ORA-01308: initialization parameter utl_file_dir is not set
ORA-06512: at "SYS.DBMS_LOGMNR_D", line 923
ORA-06512: at "SYS.DBMS_LOGMNR_D", line 1938
ORA-06512: at line 1

14:26:05 SQL> execute dbms_logmnr_d.build('oradict.ora','c:\oracle\admin\ora\log');
BEGIN dbms_logmnr_d.build('oradict.ora','c:\oracle\admin\ora\log'); END;
*
ERROR at line 1:
ORA-06532: Subscript outside of limit
ORA-06512: at "SYS.DBMS_LOGMNR_D", line 793
ORA-06512: at line 1

编辑"$ORACLE_HOME/rdbms/admindbmslmd.sql"文件，把其中的
TYPE col_desc_array IS VARRAY(513) OF col_description;
改成：
TYPE col_desc_array IS VARRAY(700) OF col_description;

15:09:06 SQL> @c:\oracle\ora81\rdbms\admin\dbmslmd.sql
Package created.
Package body created.
No errors.
Grant succeeded.

15:09:51 SQL> alter package DBMS_LOGMNR_D compile body;
Package body altered.
之后重新执行dbms_logmnr_d.build即可：
15:10:06 SQL> execute dbms_logmnr_d.build('oradict.ora','c:\oracle\admin\ora\log');
PL/SQL procedure successfully completed.

SQL>exec dbms_logmnr.add_logfile( logfilename=>'
/data6/cyx/rac1arch/arch_1_197.arc', options=>dbms_logmnr.new);
PL/SQL procedure successfully completed.

SQL> exec dbms_logmnr.add_logfile( logfilename=>'
/data6/cyx/rac1arch/arch_2_86.arc', options=>dbms_logmnr.addfile);
PL/SQL procedure successfully completed.

SQL> exec dbms_logmnr.start_logmnr(dictfilename=>'/data6/cyx/logmnr/dic.ora');
PL/SQL procedure successfully completed.

SQL> exec dbms_logmnr.start_logmnr();
PL/SQL procedure successfully completed.

SQL> exec dbms_logmnr.start_logmnr(dictfilename=>'/data6/cyx/logmnr/dic.ora' , -
starttime => '2003-09-21 09:39:00',endtime => '2003-09-21 09:45:00');
PL/SQL procedure successfully completed.

SQL> select distinct timestamp from v$logmnr_contents;
TIMESTAMP
-------------------
2003-09-21 09:40:02
2003-09-21 09:42:39

SQL> !env|grep NLS
NLS_LANG=american_america.zhs16cgb231280
NL2005-1-31_FORMAT=YYYY-MM-DD HH24:MI:SS
ORA_NLS33=/oracle/oracle9/app/oracle/product/9.2.0/ocommon/nls/admin/data
使用to_date的格式如下：
exec dbms_logmnr.start_logmnr(dictfilename=>'/data6/cyx/logmnr/dic.ora',-
starttime => to_date('2003-09-21 09:39:00','YYYY-MM-DD HH24:MI:SS'),-
endtime => to_date('2003-09-21 09:45:00','YYYY-MM-DD HH24:MI:SS'));

四、如何利用LogMiner分析Oracle8的日志文件

虽然说LogMiner是Oracle8i才推出来，但我们同样可以用它来分析Oracle8的日志文件，只不过稍微麻烦了一点，并且有一定的限制，下面是具体做法：

我们首先复制Oracle8i的$ORACLE_HOME/rdbms/admin/dbmslmd.sql脚本到Oracle8数据库所在主机的同样目录；这个脚本用于创建dbms_logmnr_d包（注意，Oracle9i中还将创建dbms_logmnr包），如果是8.1.5脚本名字为dbmslogmnrd.sql。然后在Oracle8的数据库上运行这个脚本，之后使用dbms_logmnr_d.build过程创建字典信息文件。现在我们就可以把Oracle8的归档日志连同这个字典信息文件复制到Oracle8i数据库所在的主机上，之后在Oracle8i数据库中从上面分析过程的第三步开始分析Oracle8的日志，不过

dbms_logmnr.start_logmnr()中使用的是Oracle8的字典信息文件。

按照我前面所说的那样，如果不是字典文件，我们则可以直接将Oracle8的归档日志复制到Oracle8i数据库所在主机，然后对它进行分析。

其实这里涉及到了一个跨平台使用LogMiner的问题，笔者做过试验，也可以在Oracle9i中来分析Oracle8i的日志。但这些都是有所限制的，主要表现在：

1、LogMiner所使用的字典文件必须和所分析的日志文件是同一个数据库所产生的，并且该数据库的字符集应和执行LogMiner数据库的相同。这很好理解，如果不是同一个数据库所产生就不存在对应关系了。

2、生成日志的数据库硬件平台和执行LogMiner数据库的硬件平台要求一致，操作系统版本可以不一致。笔者做试验时（如果读者有兴趣可以到我网站http://www.ncn.cn上下载试验全过程，因为太长就不放在这里了），所用的两个数据库操作系统都是Tru64 UNIX，但一个是 V5.1A，另一个则是V4.0F。如果操作系统不一致则会出现下面的错误：

ORA-01284: file /data6/cyx/logmnr/arch_1_163570.arc cannot be opened ORA-00308: cannot open archived log '/data6/cyx/logmnr/arch_1_163570.arc' ORA-27048: skgfifi: file header information is invalid ORA-06512: at "SYS.DBMS_LOGMNR", line 63 ORA-06512: at line 1

五、分析v$logmnr_contents

前面我们已经知道了LogMiner的分析结果是放在v$logmnr_contents中，这里面有很多信息，我们可以根据需要追踪我们感兴趣的信息。那么我们通常感兴趣的有哪些呢？

1、追踪数据库结构变化情况，即DDL操作，如前所述，这个只有Oracle9i才支持：

SQL> select timestamp,sql_redo from v$logmnr_contents2 where upper(sql_redo) like '%CREATE%'; TIMESTAMP ------------------- SQL_REDO ------------------------- 2003-09-21 10:01:55 create table t (c1 number);

2、追踪用户误操作或恶意操作：

例如我们现实中有这样需求，有一次我们发现一位员工通过程序修改了业务数据库信息，把部分电话的收费类型改成免费了，现在就要求我们从数据库中查出到底是谁干的这件事？怎么查？LogMiner提供了我们分析日志文件的手段，其中v$logmnr_contents的SESSION_INFO列包含了下面的信息：

login_username=NEW_97 client_info= OS_username=oracle8 Machine_name=phoenix1 OS_terminal=ttyp3 OS_process_id=8004 OS_program name=sqlplus@phoenix1 (TNS V1-V3)

虽然其中信息已经很多了，但在我们的业务数据库中，程序是通过相同的login_username登录数据库的，这样单从上面的信息是很难判断的。

不过我们注意到，因为公司应用服务器不是每个人都有权限在上面写程序的，一般恶意程序都是直接通过他自己的PC连到数据库的，这就需要一个准确的定位。IP追踪是我们首先想到的，并且也满足我们的实际要求，因为公司内部IP地址分配是统一管理的，能追踪到IP地址我们就可以准确定位了。但从面的SESSION_INFO中我们并不能直接看到IP，不过我们还是有办法的，因为这个SESSION_INFO里面的内容其实是日志从V$SESSION视图里提取的，我们可以在生产数据库中创建一个追踪客户端IP地址的触发器：

create or replace trigger on_logon_trigger after logon on database begin dbms_application_info.set_client_info(sys_context('userenv', 'ip_address')); end; /

现在，我们就可以在V$SESSION视图的CLIENT_INFO列中看到新登录的客户端IP地址了。那么上面的提出的问题就可以迎刃而解了。假如被更新的表名为HMLX，我们就可以通过下面的SQL来找到所需信息：

SQL > select session_info ,sql_redo from v$logmnr_contents 2 where upper(operation) = 'UPDATE' and upper(sql_redo) like '%HMLX%' 3 / SESSION_INFO ----------------------------------------- SQL_REDO ----------------------------------------- login_username=C client_info=10.16.98.26 OS_username=sz-xjs-chengyx Machine_name =GDTEL\SZ-XJS-CHENGYX update "C"."HMLX" set "NAME" = 'free' where "NAME" = 'ncn.cn' and ROWID = 'AAABhTAA FAAABRaAAE';

好了，到此为止，这篇文章就要结束了，如果读者朋友还有什么疑问，可以登录我的个人网站（www.ncn.cn）来获得最新消息，也可以通过MSN（gototop_ncn@hotmail.com）直接和我联系。

六、参考资料：

1、Technical White Paper Oracle9i LogMiner

2、Metalink文档：How to Setup LogMiner（文档ID：111886.1）