分析Oracle數據庫日志文件(2)

四、如何利用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過程創建字典信息文件?，F在我們就可以把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';

　　

原文轉自：http://www.kjueaiud.com