前面的Guarded Suspension Pattern和Balking Pattern都比較極端。一個是“不讓？爺不玩了”，另一個是“不行！我一定要玩！”。而，Guarded Timeout Patter就中庸的多了，是“現在不讓玩？那我等等吧。如果超過我等待的時間了，我就不玩了”。 還是以代碼說話：

class A{     
    private long timeout; //等待的最長時間 
    public synchronized void changeState(){ 
        改變狀態 通知等待的線程不同再等了(notify/notifyAll) 
    } 
    public synchronized void guardedMethod() throws InterruptedException{ 
        long start = System.currentTimeMillis(); //開始時刻 
        while(條件成立不成立){ 
            long now = System.currentTimeMillis(); //現在時刻 
            long rest = timeout - (now -start); //還需要等待的時間 
            if(rest <= 0){throw new InterruptedException("...");} //如果為等待時間為0或者為負數，就不等了。 
            等著一段時間吧，如果超過我等待的最長時間了，我就不玩了（wait（rest）） //當wait的時間超過rest時，也會拋出InteruptedException。 
        } 
        進行處理 
    } 
} 

在通常情況下，會對if(rest<=0){...}中拋出的異常進行一下包裝，即繼承InterruptedException異常，是得調用者知道是超時了（wait(rest)，interrupt方法都可能會拋出InterruptedException，所以必須包裝一下，讓上層程序識別）。

參考： 《Java多線程設計模式》，中國鐵道出版社，2005，結城浩

文章來源:http://localhost/wp2/?p=88

Balking Pattern重在“balking”，balking的意思是“退縮不前”，在棒球運動的意思是“當跑壘員在壘時，投手在投手板但’中途放棄‘投球的動作”（呵呵，對棒球不懂...）。另外，這種模式和Guarded Suspension Pattern有點類似，也是有要檢測警戒條件是否成立，不過，如果不成立，就不用等待了，直接就放棄了。呵呵，這種模式還是想的比較開啊（不行？那爺不賠你玩了:)），相比之下，Guarded Suspension Pattern就執著的多了:)。 從代碼的角度看，如下： class A{ public synchronized void guardedMethod(){ if(警戒條件不成立){ return; } 進行處理 改變狀態 } } 下面給出參考書中列出的一個使用Balking Pattern的實例：即文本編輯器的自動保存功能。當在編輯文件的時候，后臺有個線程會定期的對文件進行保存，防止程序崩潰時文件內容的丟失。那么，文件是否被修改就是這里的警戒條件。當然，還得有另外一個字段，就是當前的數據。編輯程序會調用synchronized的方法對文件數據進行修改，并設置警戒條件（為什么用synchronized?是因為防止更改操作和保存的沖突，否則，可能保存的不是最新的數據）。那么，后臺的定時保存線程，會定時調用保存文件這個guardedMethod()，如果文件已經被（編輯程序）保存了，那么就balking了，否則，就保存。下面是代碼：

class Data{ 
    public synchronized void changeData(String content){ 
        this.content = content; changed = true; 
    }   
    public synchronized void guardedMethod(){ 
        if(!changed){ return; } 
            doSave(); 
            changed = false; 
    } 
    private vodi doSave(){} 
}

注意上面的doSave方法不是synchronized。 Balking Patter的適用場合：

1. 不需要可以去執行的時候。如上面說的自動保存的例子。
2. 不想等待警戒條件成立時。
3. 警戒條件只有一次成立時。比如僅僅需要進行一次初始化（不是在構造函數中）的共享資源類。

參考： 《Java多線程設計模式》，中國鐵道出版社，2005，結城浩

文章來源:http://localhost/wp2/?p=86

Guarded Suspension Pattern就是“當訪問的共享資源被保護（防衛）時，那么線程就掛起”，生活中的例子就是當你和女朋友準備出去玩，你給女朋友打電話說該走了，女朋友說還沒準備好，那你只能等在那里知道你女朋友收拾好了才能出去:)。 相對Single Threaded Pattern的任何線程對共享資源的訪問僅僅是多個線程不能同時訪問unsafeMethod，Guared Suspension Pattern就稍微復雜點了，它有個概念就是“條件”。當共享資源的條件準備好時，才能讓其他線程進行訪問，如果條件沒有準備好，對不起，先等著吧。所以，這個模式里面還必須有一個改變“條件”使其成立的方法，還得有一個通知等待的線程不用再等的方法，否則，那些線程就在那里死等了...。 Guarded Suspension Pattern中對共享資源叫做Guarded Object（被防衛的對象），unsafeMethod方法稱之為guardedMethod。當線程執行guardedMethod方法時，只要滿足警戒條件，就會馬上執行。當警戒條件不成立時，就要開始等待。警戒條件的成立與否，會隨著Guarded Object狀態的變化而變化。 從代碼的角度看，如下：

class A{ 
    public synchronized void changeState(){ 
        改變狀態 通知等待的線程不同再等了(notify/notifyAll) 
    } 
    public synchronized void guardedMethod(){ 
        while(條件成立不成立){ 
            //這里不能是if，至于原因就好好想想吧:)（需要重點理解wait/notify/notifyAll的處理過程） 
            等著吧（wait） 
        } 進行處理 
    } 
} 

這種模式有一些變形： busy wait，即忙碌的等待。即在while循環中不用wait，而用yield；在changeState中不用notify/notifyAll。但是，這種變形的缺點是等待的線程仍然在運行，只不過一直在檢測運行時間是否滿足。

參考： 《Java多線程設計模式》，中國鐵道出版社，2005，結城浩

文章來源:http://localhost/wp2/?p=82

Immutable Pattern的關鍵在于共享資源是immutable（不會改變的）。即在實例產生后，沒有改變字段的方法了，即只有只讀的方法（所有的方法都是safeMethod），那么任何線程對共享資源的訪問就不可造成沖突了。就算想破壞這個共享資源都沒有辦法，呵呵。 String類就是Immutable Pattern的典型。String類沒有提供任何改變字符串屬性的方法。當然就是Immutable Pattern了。 從代碼上來看，Immutable Pattern的形式如下：

class A{ 
    public void safeMethod1(){} 
    publi c void safeMethod2(){} 
} 

由于沒有用到synchronized關鍵字，那么訪問共享資源的效率是很高的。在某些情況下，如果某個共享資源用到了synchronized關鍵字，即不是immtable。那么，可以根據這個類的具體用處，分為兩個類，一個是immutable，另一個是mutable（可變的），如果這兩個類可以互相轉化，那么在不同的場合用不同的類就可以提高程序的效率了。Java中對字符串這個共享資源提供了兩個類：String類和StringBuffer類。他們就是對應的immutable和mutable，兩者可以通過構造函數（String有個構造函數的參數是StringBuffer，StringBuffer有個構造函數的參數String）轉化。

參考： 《Java多線程設計模式》，中國鐵道出版社，2005，結城浩

文章來源:http://localhost/wp2/?p=75

Single Threaded Execution模式的核心就是single，即某個共享資源同時只能被某一個線程訪問。可以做如下比喻來理解這個模式：門（共享資源），人（線程）。一個門一次只能由一個人通過。如果一個人正在通過這個門，那么其他人只能等待了。 當然，共享資源中某些方法是線程安全的（SafeMethod），就不用考慮多個線程同時調用的情況了。只有對不安全的方法（UnsafeMethod）才需要考慮多線程訪問的問題。 可以對Single Thread Execution模式這樣理解：如果另外的線程也行執行被保護的UnsafeMethod，那么就需要判斷是否有其他線程正在執行被保護的UnsafeMethod。如果有，則等待；沒有，則執行。 對Single Threaded Execution Pattern來說，代碼的典型表現形式就是對所有的UnsafeMethod方法加上synchronized關鍵字。如：

class A{ 
    public void safeMethod(){ } 
    public synchronized void unsafeMethod1(){ } 
    publi synchronized void unsafeMethod2(){ } 
}

當下面的情況發生時，可能會出現死鎖

1. 有多個共享資源
2. 線程鎖定了一個共享資源，但還沒有解除鎖定就鎖定了另外一個共享資源
3. 各個線程獲取共享資源的順序不固定

也就是說，打破上面的三個情況的任何一個，就可以避免死鎖的發生。 參考： 《Java多線程設計模式》，中國鐵道出版社，2005，結城浩

文章來源:http://localhost/wp2/?p=70

Oracle的數據庫驅動有兩種，oci和thin，沒有用過oci，這里用的是thin。 問題描述： 有一張表MESSAGE，里面有個字段是content varchar2(4000)。 如果直接用Statement來更新這個字段，是不會用任何問題的。因為Statement的原理就是直接將整個sql語句發到數據庫執行。 但是，如果用PreparedStatement的setString(）方法來設置這個字段，就有問題了，當設置的字符串長度大于2000時，就會報錯：”java.sql.SQLException: 數據大小超出此類型的最大值“。 問題分析： 這些天學著用iBatis，就遇到了上面的這個問題。因為如果在iBatis中使用內聯參數（#做占位符），底層實現的時候就是用的PreparedStatement來實現的，所以就遇到了上面的問題。 至于為什么用PreparedStatement會出先這個問題，JavaEye上的一篇文章《當PreparedStatement中的參數遇到大字符串》給出了很好的解釋（牛逼啊！）

(1)Using the JDBC thin driver (2)Using binds (not defines) (3)Using SQL CHAR datatypes (4)Connecting to a database whose character set is neither ASCII (US7ASCII) nor ISO Latin1 (WE8ISO8859P1) When the database character set is neither US7ASCII nor WE8ISO8859P1, the JDBC thin driver converts Java UTF-16 characters to UTF-8 encoding bytes for SQL CHAR binds. The UTF-8 encoding bytes are then transferred to the database, and the database converts the UTF-8 encoding bytes to the database character set encoding.” 原來是JDBC在轉換過程中對字符串的長度做了限制。這個限制和數據庫中字段的實際長度沒有關系。 所以，setCharacterStream()方法可以逃過字符轉換限制，也就成為了解決此問題的方案之一。 而JDBC對轉換字符長度的限制是為了轉換過程中的數據擴展。 問題解決： 根據上面的分析，可以用PreparedStatement的setCharacterStream()方法來解決問題。 在iBatis中，可以使用下面的自定義類型處理器來處理（參考文章《用ibatis向oracle數據庫的varchar2(4000)列寫值的問題》）

/**
 * String implementation of TypeHandler
 */
public class StringTypeHandler extends BaseTypeHandler implements TypeHandler {
 /**
 * 在使用oracle時，如果在一個varchar2(4000)的字段上插入的字符過長（一般只能插入666個漢字，視字符集不同會有所不同），
 * 會導致失敗，具體報錯會因驅動版本不同而不同。
 * 如果使用setCharacterStream則可以插入最多的字符。因此，我將這個方法改了一下。
 */
 public void setParameter(PreparedStatement ps, int i, Object parameter,
 String jdbcType) throws SQLException {
 //原來的代碼
 //ps.setString(i, ((String) parameter));

 //以下是我加的代碼，為了盡量提高效率，作了一下判斷
 String s = (String) parameter;
 if (s.length() < 667) { //以字符中全是漢字為底線。
 ps.setString(i, s);
 } else {
 ps.setCharacterStream(i, new StringReader(s), s.length());
 }
 }

 public Object getResult(ResultSet rs, String columnName) throws
 SQLException {
 Object s = rs.getString(columnName);
 if (rs.wasNull()) {
 return null;
 } else {
 return s;
 }
 }

 public Object getResult(ResultSet rs, int columnIndex) throws SQLException {
 Object s = rs.getString(columnIndex);
 if (rs.wasNull()) {
 return null;
 } else {
 return s;
 }
 }

 public Object getResult(CallableStatement cs, int columnIndex) throws
 SQLException {
 Object s = cs.getString(columnIndex);
 if (cs.wasNull()) {
 return null;
 } else {
 return s;
 }
 }

 public Object valueOf(String s) {
 return s;
 }
 }

 

其實，上面的解決方案是比較麻煩的，今天發現了一個更好的解決方案，就是將oracle jdbc驅動換成用于oracle10g第二版的驅動ojdbc14.jar。就行了，唉，前面折騰了幾天的問題竟然可以這么容易地解決...

文章來源:http://localhost/wp2/?p=63

這里對final關鍵字進行總結。 final類 當類聲明為final時，就不能定義這個類的子類。因為final類的類無法定義子類，所以final類聲明的所有方法不會被覆蓋（override）。 final方法 若將實例方法聲明為final時，這個方法無法被子類所覆蓋（override）。 若將類方法（static方法）聲明為final時，這個方法無法被子類所隱藏（hide）。對隱藏這個術語不熟，本文最后會加上。 final字段（final屬性） final字段的值只能指定一次。 final實例字段的值只能在定義時或者在構造器中指定。 如： class A{

final int i = 1;

} class A{

final int i;

public A(){

this.i = 2;

}

} final類字段的值只能在定義是或者在static塊（靜態初始化塊）中指定。 class A{

static final int i = 12;

} class A{

static final int i;

static{

i = 12;

}

} final局部變量和final參數 final局部變量的值只能指定一次。 final參數的值在方法被調用時，由實參指定，不能再次指定（實際上也滿足被指定一次的原則）。 下面對java中類的繼承中的覆蓋（override）和隱藏（hide）進行總結。 在《Java核心技術卷一》中對隱藏是采用的訪問限定符（如public，private，protected）來實現的。這里的隱藏不是采用訪問限定符來實現的，而是采用子類和父類有同名的類方法和字段（實例字段和靜態字段）來實現的。在實際編程中，隱藏一般只用于類方法，即父類的類方法被子類中同名（這里的同名指方法名和參數都一樣，其實返回值也必須一樣，可以試一試）的類方法隱藏。 這里繼續總結一下：

1. 子類可以覆蓋父類的實例方法（方法名、參數和返回值都一樣），另外，這里還有一個重載（overload）的概念，重載是一個靜態的概念，是在編譯時根據方法名和參數來確定的，重載是一個類自身的一個屬性，和繼承沒有關系。
2. 子類可以隱藏父類的類方法（方法名、參數和返回值都一樣）
3. 子類可以隱藏父類的字段（實例字段和靜態字段）（通過在子類中定義字段名相同（類型可和父類不一樣）的字段即可）。

覆蓋是動態的概念，是在運行時決定的。重載和隱藏是靜態的概念，是在編譯時決定的。 參考：

1. 《Java多線程設計模式》中國鐵道出版社 2005

文章來源:http://localhost/wp2/?p=61

編程時你需要考慮的不是內存的物理地址(memory address)，而是一種邏輯上的內存模型。 Java虛擬機將其管轄的內存大致分三個邏輯部分：

1. 方法區(Method Area)、
2. Java棧
3. Java堆。

方法區是靜態分配(static allocation)的，編譯器將變量在綁定在某個存儲位置上，而且這些綁定不會在運行時改變。Java方法區的一個重要部分，也是靜態分配最典型的例子，是常數池，源代碼中的命名常量、String常量和static 變量保存在其中。 Java Stack是一個邏輯概念，特點是后進先出，此外沒有特別的要求。Java Stack并不代表任何特定的內存區間，也不限制它的實現方式。一個棧的空間可能是連續的，也可能是不連續的。最典型的Stack應用是方法的調 用，Java虛擬機每調用一次方法就創建一個方法幀（frame），退出該方法則對應的方法幀被彈出(pop)。棧分配存在一些局限：Java棧所處理的方法幀和局部變量，都將隨著方法幀彈出而結束，顯然局部變量無法從一個幀保持到下一個幀，被調方法的幀不可能比調用方法的壽命更長。因此，從數據保存來看，棧分配適用于由作用域決定生命周期的局部變量。 Java堆(Heap)堆分配(heap allocation)意味著以隨意的順序，在運行時進行存儲空間分配和收回的內存管理模型。堆中存儲的數據常常是大小、數量和生命期在編譯時無法確定的。Java對象的內存總是在heap中分配。
文章來源:http://localhost/wp2/?p=59

在Java中，為了生成一個線程，有兩種方法：

1. 繼承Thread類，覆蓋run方法。在使用時，調用Thread實例的start方法即可啟動一個線程，此線程將執行run方法里面的代碼。
2. 實現Runnable接口，實現run方法。在使用時，調用Thread實例（傳入實現Runnable接口的類實例）的start方法，此線程將執行run方法里面的代碼。

啟動線程的方法只能用start方法，不能用run方法...start方法才會啟動一個線程去執行run方法，而run方法僅僅是一個類實例的方法！！！

在此，需要強調的是，線程和Thread類的區別。線程是一個動態的概念，而Thread類（或其實例）是靜態的概念。雖然說從代碼上看，執行Thread實例的start方法或者run方法（只能在實現Runnable接口時）好像把Thread實例當作了一個線程，當事實上，應該這樣理解：Thread類就是一個普通的類，和其他類沒有什么兩樣，但是他的start方法或者run方法比較特殊，可以啟動一個新的線程。當新線程啟動后，就馬上執行Thread類里面run方法的代碼或者Runnable接口的run方法。 在Java中，為了實現多線程之間的同步和互斥，提供了一個關鍵字，synchronized。這個關鍵字有兩個用法：

1. 用于方法聲明中。如： public synchronized void methd(){ .... } 把這種用法稱之為synchronized方法。
2. 用于方法體中。如： public void method(){ synchronized(this){ .... } }把這種方法稱為synchronized語句。

當不同的線程運行synchronized方法或者synchronized語句時，首先會獲得鎖，然后再執行，當退出時，會釋放鎖。當鎖還沒有被釋放時，如果有其他線程訪問，那么這些線程會阻塞。如果鎖被釋放，那么jvm會讓所有在此鎖上阻塞的所有線程競爭，將有一個線程得到鎖，其他線程將繼續阻塞。 其實，synchronized方法就是在方法體的最前面加了一個鎖，在方法體的最后面釋放掉了這個鎖。synchronized語句就是在被包含的語句 前加了一個鎖，在被包含的語句后釋放掉了鎖。這里需要強調鎖的概念，可以這么認為，Java中每一個對象都有一個鎖的，可以使用synchronized 方法和synchronized語句來獲得這些鎖。 下面通過實例來理解synchronized方法和synchronized語句。 1，下面的兩個方法是等價的： public synchronized void methd(){ .... } public void method(){ synchronized(this){ .... } } 怎么理解上面的等價？ synchronized方法（只能）獲得當前對象的鎖，那么，在synchronized語句中顯示的指明要獲得鎖的對象為this就可以使兩者等價了。 在synchronized方法中，多個線程同時只能訪問某個對象（可能含多個synchronized方法）的一個synchonized方法。 對下面這個銀行類來說，使用synchronized方法就可以達到線程的互斥。多個線程同時只能有一個線程訪問一個synchronized方法。 public class Bank{ public synchronized void deposite(){ 對某個帳戶進行增加 } public synchronized void withdraw(){ 對某個帳戶進行減少 } } 如果，我們想對某個對象的方法進行更靈活的線程互斥訪問，可以使用synchornized語句，顯示的聲明要獲得的鎖的對象。 2， public synchronized static  void methd(){ .... } 上面的方法都可以防止多個線程同時訪問這個類中的method方法。它可以對類的所有對象實例起作用。他等價于下面的方法。 public static  void method(){ synchronized(this.getClass()){ .... } } 這里還需要補充一下，synchronized方法被繼承后就不是synchronized的了，除非在子類中再次聲明方法為synchronized的。 Object類是Java所有對象的基類，Object類中有幾個方法，提供了對多線程編程的支持：

1. wait()方法將當前運行的線程阻塞，放置于當前線程鎖執行的對象的wait set中，然后取消此線程對鎖的獲得。
2. notify()/notifyAll()方法將把當前線程執行的對象的wait set中的某一個/所有線程拿出來。

注意，wait和notify/notifyAll方法只能在線程已獲得對象實例的鎖時才能調用，否則，將拋出java.lang.IllegalMonitorStateException。 這篇文章寫的好累啊，語言組織能力咋這么弱...

文章來源:http://localhost/wp2/?p=52

由于需要，學習了Oracle日志分析工具LogMiner的使用，在此記錄一下： 1，確定你的Oracle安裝的目錄，下面用%ORALCE_HOME%表示。 2，必須以DBA角色登錄，命令如下 SQL>sqlplus /nolog SQL>conn sys/manager@wymis as sysdba 3，（如果第一次做日志分析）安裝LogMiner SQL> @%ORALCE_HOME%\ora90\rdbms\admin\dbmslm.sql SQL> @%ORALCE_HOME%\ora90\rdbms\admin\dbmslmd.sql 4，設置UTL_FILE_DIR值，這個值表示存放日志分析相關文件的目錄，設置方法可以到Oracle的企業管理器下面設置，這個值的例子如c:\log，注意，最后沒有\符號。設置完后，需要重新啟動數據庫。 5，生成數據字典 SQL> execute dbms_logmnr_d.build(- > dictionary_filename => 'logminer_dict.dat',- > dictionary_location => 'c:\import'); 注意上面每行代碼后有一個'-'符號，表示輸入還沒有結束。 注意，dictionary_location的值必須與第4步中UTL_FILE_DIR的值一樣。 6，創建要分析的日志文件列表， 創建列表 SQL> EXECUTE dbms_logmnr.add_logfile(- LogFileName=>' e:\Oracle\oradata\sxf\redo01.log',- Options=>dbms_logmnr.new); 添加其他日志文件到列表 SQL> EXECUTE dbms_logmnr.add_logfile( LogFileName=>' e:\Oracle\oradata\sxf\redo02.log', Options=>dbms_logmnr.addfile); 注意，LogFileName的值可以到相應的數據庫實例文件夾下面的實例獲得。 7，使用LogMiner進行日志分析 SQL> execute dbms_logmnr.start_logmnr(- > dictfilename => 'c:\import\logminer_dict.dat',- > starttime => to_date('2001-9-18 00:00:00','YYYY-MM-DD HH24:MI:SS'),- > endtime => to_date('2009-10-30 00:00:00','YYYY-MM-DD HH24:MI:SS')); 注意，這里的starttime和endtime的范圍必須是你的日志文件涉及的范圍。如果實在拿不準，可以不用這兩個參數。 8，分析結果 LogMiner分析的結果存放在v$LogMnr_Contents表里面。具體的分析，網上有很多好的文章，就不再寫了。 再轉一篇比較好的文章，來自http://www.oracle.com.cn/viewthread.php?tid=22975的 robertmao_2003 作為Oracle DBA，我們有時候需要追蹤數據誤刪除或用戶的惡意操作情況，此時我們不僅需要查出執行這些操作的數據庫賬號，還需要知道操作是由哪臺客戶端（IP地址 等）發出的。針對這些問題，一個最有效實用而又低成本的方法就是分析Oracle數據庫的日志文件。本文將就Oracle日志分析技術做深入探討。 一、如何分析即LogMiner解釋 從目前來看，分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMiner來進行， Oracle數據庫的所有更改都記錄在日志中，但是原始的日志信息我們根本無法看懂，而LogMiner就是讓我們看懂日志信息的工具。從這一點上看，它 和tkprof差不多，一個是用來分析日志信息，一個則是格式化跟蹤文件。通過對日志的分析我們可以實現下面的目的： 1、查明數據庫的邏輯更改； 2、偵察并更正用戶的誤操作； 3、執行事后審計； 4、執行變化分析。 不僅如此，日志中記錄的信息還包括：數據庫的更改歷史、更改類型（INSERT、UPDATE、DELETE、DDL等）、更改對應的SCN號、以及執行 這些操作的用戶信息等，LogMiner在分析日志時，將重構等價的SQL語句和UNDO語句（分別記錄在V$LOGMNR_CONTENTS視圖的 SQL_REDO和SQL_UNDO中）。這里需要注意的是等價語句，而并非原始SQL語句，例如：我們最初執行的是“delete a where c1 <>'cyx';”，而LogMiner重構的是等價的6條DELETE語句。所以我們應該意識到V$LOGMNR_CONTENTS視圖中 顯示的并非是原版的現實，從數據庫角度來講這是很容易理解的，它記錄的是元操作，因為同樣是“delete a where c1 <>'cyx';”語句，在不同的環境中，實際刪除的記錄數可能各不相同，因此記錄這樣的語句實際上并沒有什么實際意義，LogMiner重 構的是在實際情況下轉化成元操作的多個單條語句。 另外由于Oracle重做日志中記錄的并非原始的對象（如表以及其中的列）名稱，而只是它們在Oracle數據庫中的內部編號（對于表來說是它們在數據庫 中的對象ID，而對于表中的列來說，對應的則是該列在表中的排列序號：COL 1, COL 2 等），因此為了使LogMiner重構出的SQL語句易于識別，我們需要將這些編號轉化成相應的名稱，這就需要用到數據字典（也就說LogMiner本身 是可以不用數據字典的，詳見下面的分析過程），LogMiner利用DBMS_LOGMNR_D.BUILD()過程來提取數據字典信息。 LogMiner包含兩個PL/SQL包和幾個視圖： 1、dbms_logmnr_d包，這個包只包括一個用于提取數據字典信息的過程，即dbms_logmnr_d.build()過程。 2、dbms_logmnr包，它有三個過程： add_logfile(name varchar2, options number) - 用來添加/刪除用于分析的日志文件； start_logmnr(start_scn number, end_scn number, start_time number,end_time number, dictfilename varchar2, options number) - 用來開啟日志分析，同時確定分析的時間/SCN窗口以及確認是否使用提取出來的數據字典信息。 end_logmnr() - 用來終止分析會話，它將回收LogMiner所占用的內存。 與LogMiner相關的數據字典。 1、v$logmnr_dictionary，LogMiner可能使用的數據字典信息，因logmnr可以有多個字典文件，該視圖用于顯示這方面信息。 2、v$logmnr_parameters，當前LogMiner所設定的參數信息。 3、v$logmnr_logs，當前用于分析的日志列表。 4、v$logmnr_contents，日志分析結果。 二、Oracle9i LogMiner的增強： 1、支持更多數據/存儲類型：鏈接/遷移行、CLUSTER表操作、DIRECT PATH插入以及DDL操作。在V$LOGMNR_CONTENTS的SQL_REDO中可以看到DDL操作的原句（CREATE USER除外，其中的密碼將以加密的形式出現，而不是原始密碼）。如果TX_AUDITING初始化參數設為TRUE，則所有操作的數據庫賬號將被記錄。 2、提取和使用數據字典的選項：現在數據字典不僅可以提取到一個外部文件中，還可以直接提取到重做日志流中，它在日志流中提供了操作當時的數據字典快照，這樣就可以實現離線分析。 3、允許對DML操作按事務進行分組：可以在START_LOGMNR()中設置COMMITTED_DATA_ONLY選項，實現對DML操作的分組，這樣將按SCN的順序返回已經提交的事務。 4、支持SCHEMA的變化：在數據庫打開的狀態下，如果使用了LogMiner的DDL_DICT_TRACKING選項，Oracle9i的 LogMiner將自動對比最初的日志流和當前系統的數據字典，并返回正確的DDL語句，并且會自動偵察并標記當前數據字典和最初日志流之間的差別，這樣 即使最初日志流中所涉及的表已經被更改或者根本已經不存在，LogMiner同樣會返回正確的DDL語句。 5、在日志中記錄更多列信息的能力：例如對于UPDATE操作不僅會記錄被更新行的情況，還可以捕捉更多前影信息。 6、支持基于數值的查詢：Oracle9i LogMiner在支持原有基于元數據（操作、對象等）查詢的基礎上，開始支持基于實際涉及到的數據的查詢。例如涉及一個工資表，現在我們可以很容易地查 出員工工資由1000變成2000的原始更新語句，而在之前我們只能選出所有的更新語句。 三、Oracle8i/9i的日志分析過程 LogMiner只要在實例起來的情況下都可以運行，LogMiner使用一個字典文件來實現Oracle內部對象名稱的轉換，如果沒有這個字典文件，則直接顯示內部對象編號，例如我們執行下面的語句： delete from "C"."A" where "C1" = ‘gototop’ and ROWID = 'AAABg1AAFAAABQaAAH'; 如果沒有字典文件，LogMiner分析出來的結果將是： delete from "UNKNOWN"."OBJ# 6197" where "COL 1" = HEXTORAW('d6a7d4ae') and ROWID = 'AAABg1AAFAAABQaAAH'; 如果想要使用字典文件，數據庫至少應該出于MOUNT狀態。然后執行dbms_logmnr_d.build過程將數據字典信息提取到一個外部文件中。下面是具體分析步驟： 1、確認設置了初始化參數：UTL_FILE_DIR，并確認Oracle對改目錄擁有讀寫權限，然后啟動實例。示例中UTL_FILE_DIR參數如下： SQL> show parameter utl NAME? ?? ?? ?? ?? ?? ?? ?? ? TYPE? ?? ???VALUE ------------------------ ----------- ------------------------------ utl_file_dir? ?? ?? ?? ?? ???string? ?? ?/data6/cyx/logmnr 這個目錄主要用于存放dbms_logmnr_d.build過程所產生的字典信息文件，如果不用這個，則可以不設，也就跳過下面一步。 2、生成字典信息文件： exec dbms_logmnr_d.build(dictionary_filename =>' dic.ora',dictionary_location => '/data6/cyx/logmnr'); 其中dictionary_location指的是字典信息文件的存放位置,它必須完全匹配UTL_FILE_DIR的值，例如：假設 UTL_FILE_DIR=/data6/cyx/logmnr/，則上面這條語句會出錯，只因為UTL_FILE_DIR后面多了一個“/”，而在很多 其它地方對這一“/”是不敏感的。 dictionary_filename指的是放于字典信息文件的名字，可以任意取。當然我們也可以不明確寫出這兩個選項，即寫成： exec dbms_logmnr_d.build('dic.ora','/data6/cyx/logmnr'); 如果你第一步的參數沒有設，而直接開始這一步，Oracle會報下面的錯誤： 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 需要注意的是，在oracle817 for Windows版中會出現以下錯誤： 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. 然后重新編譯DBMS_LOGMNR_D包： 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. 3、添加需要分析的日志文件 SQL>exec dbms_logmnr.add_logfile( logfilename=>' /data6/cyx/rac1arch/arch_1_197.arc', options=>bms_logmnr.new); PL/SQL procedure successfully completed. 這里的options選項有三個參數可以用： NEW - 表示創建一個新的日志文件列表 ADDFILE - 表示向這個列表中添加日志文件，如下面的例子 REMOVEFILE - 和addfile相反。 SQL> exec dbms_logmnr.add_logfile( logfilename=>' /data6/cyx/rac1arch/arch_2_86.arc', options=>bms_logmnr.addfile); PL/SQL procedure successfully completed. 4、當你添加了需要分析的日志文件后，我們就可以讓LogMiner開始分析了： SQL> exec dbms_logmnr.start_logmnr(dictfilename=>'/data6/cyx/logmnr/dic.ora'); PL/SQL procedure successfully completed. 如果你沒有使用字典信息文件（此時我們只需要啟動實例就可以了），那么就不需要跟dictfilename參數： SQL> exec dbms_logmnr.start_logmnr(); PL/SQL procedure successfully completed. 當然dbms_logmnr.start_logmnr()過程還有其它幾個用于定義分析日志時間/SCN窗口的參數，它們分別是： STARTSCN / ENDSCN - 定義分析的起始/結束SCN號， STARTTIME / ENDTIME - 定義分析的起始/結束時間。 例如下面的過程將只分析從 '2003-09-21 09:39:00'到'2003-09-21 09:45:00'這段時間的日志： 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 這里需要注意的是，因為我之前已經設置NLS_DATE_FORMAT環境變量，所以上面的日期可以直接按這個格式寫就行了，如果你沒有設，則需要使用to_date函數來轉換一下。 SQL> !env|grep NLS NLS_LANG=american_america.zhs16cgb231280 NLS_DATE_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')); STARTSCN 和ENDSCN參數使用方法類似。 5、好了，在上面的過程執行結束之后，我們就可以通過訪問與LogMiner相關的幾個視圖來提取我們需要的信息了。其中在v$logmnr_logs中 可以看到我們當前分析的日志列表，如果數據庫有兩個實例（即OPS/RAC），在v$logmnr_logs中會有兩個不同的THREAD_ID。 而真正的分析結果是放在v$logmnr_contents中，這里面有很多信息，我們可以根據需要追蹤我們感興趣的信息。后面我將單獨列出來講常見的追蹤情形。 6、全部結束之后，我們可以執行dbms_logmnr.end_logmnr過程退出LogMiner分析過程，你也可以直接退出SQL*PLUS，它會自動終止。 四、如何利用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）
文章來源:http://localhost/wp2/?p=50