前面的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