深入分析Oracle数据库日志文件(2)

2/9/2008来源:Oracle教程人气:4609


  四、如何利用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';