2011年2月28日星期一

Oracle的并发控制(锁)

根据保护对象的不同,Oracle数据库锁可以分为以下几大类:
(1) DML lock(data locks,数据锁):用于保护数据的完整性;
(2) DDL lock(dictionary locks,字典锁):用于保护数据库对象的结构(例如表、视图、索引的结构定义);
(3) Internal locks 和latches(内部锁与闩):保护内部数据库结构;
(4) Distributed locks(分布式锁):用于OPS(并行服务器)中;
(5) PCM locks(并行高速缓存管理锁):用于OPS(并行服务器)中。
在Oracle中最主要的锁是DML(也可称为data locks,数据锁)锁。从封锁粒度(封锁对象的大小)的角度看,Oracle DML锁共有两个层次,即行级锁和表级锁。
许多对Oracle不太了解的技术人员可能会以为每一个TX锁代表一条被封锁的数据行,其实不然。TX的本义是Transaction(事务),当一个事务第一次执行数据更改(Insert、Update、Delete)或使用SELECT… FOR UPDATE语句进行查询时,它即获得一个TX(事务)锁,直至该事务结束(执行COMMIT或ROLLBACK操作)时,该锁才被释放。所以,一个TX锁,可以对应多个被该事务锁定的数据行(在我们用的时候多是启动一个事务,然后SELECT… FOR UPDATE NOWAIT)。
在Oracle的每行数据上,都有一个标志位来表示该行数据是否被锁定。Oracle不像DB2那样,建立一个链表来维护每一行被加锁的数据,这样就大大减小了行级锁的维护开销,也在很大程度上避免了类似DB2使用行级锁时经常发生的锁数量不够而进行锁升级的情况。数据行上的锁标志一旦被置位,就表明该行数据被加X锁,Oracle在数据行上没有S锁。
3.2.1 意向锁的引出
表是由行组成的,当我们向某个表加锁时,一方面需要检查该锁的申请是否与原有的表级锁相容;另一方面,还要检查该锁是否与表中的每一行上的锁相容。比如一个事务要在一个表上加S锁,如果表中的一行已被另外的事务加了X锁,那么该锁的申请也应被阻塞。如果表中的数据很多,逐行检查锁标志的开销将很大,系统的性能将会受到影响。为了解决这个问题,可以在表级引入新的锁类型来表示其所属行的加锁情况,这就引出了"意向锁"的概念。
意向锁的含义是如果对一个结点加意向锁,则说明该结点的下层结点正在被加锁;对任一结点加锁时,必须先对它的上层结点加意向锁。如:对表中的任一行加锁时,必须先对它所在的表加意向锁,然后再对该行加锁。这样一来,事务对表加锁时,就不再需要检查表中每行记录的锁标志位了,系统效率得以大大提高。
3.2.2 意向锁的类型
由两种基本的锁类型(S锁、X锁),可以自然地派生出两种意向锁:
意向共享锁(Intent Share Lock,简称IS锁):如果要对一个数据库对象加S锁,首先要对其上级结点加IS锁,表示它的后裔结点拟(意向)加S锁;
意向排它锁(Intent Exclusive Lock,简称IX锁):如果要对一个数据库对象加X锁,首先要对其上级结点加IX锁,表示它的后裔结点拟(意向)加X锁。
另外,基本的锁类型(S、X)与意向锁类型(IS、IX)之间还可以组合出新的锁类型,理论上可以组合出4种,即:S+IS,S+IX,X+IS,X+IX,但稍加分析不难看出,实际上只有S+IX有新的意义,其它三种组合都没有使锁的强度得到提高(即:S+IS=S,X+IS=X,X+IX=X,这里的"="指锁的强度相同)。所谓锁的强度是指对其它锁的排斥程度。
这样我们又可以引入一种新的锁的类型:
共享意向排它锁(Shared Intent Exclusive Lock,简称SIX锁):如果对一个数据库对象加SIX锁,表示对它加S锁,再加IX锁,即SIX=S+IX。例如:事务对某个表加SIX锁,则表示该事务要读整个表(所以要对该表加S锁),同时会更新个别行(所以要对该表加IX锁)。
这样数据库对象上所加的锁类型就可能有5种:即S、X、IS、IX、SIX。
具有意向锁的多粒度封锁方法中任意事务T要对一个数据库对象加锁,必须先对它的上层结点加意向锁。申请封锁时应按自上而下的次序进行;释放封锁时则应按自下而上的次序进行;具有意向锁的多粒度封锁方法提高了系统的并发度,减少了加锁和解锁的开销。
Oracle的DML锁(数据锁)正是采用了上面提到的多粒度封锁方法,其行级锁虽然只有一种(即X锁),但其TM锁(表级锁)类型共有5种,分别称为共享锁(S锁)、排它锁(X锁)、行级共享锁(RS锁)、行级排它锁(RX锁)、共享行级排它锁(SRX锁),与上面提到的S、X、IS、IX、SIX相对应。需要注意的是,由于Oracle在行级只提供X锁,所以与RS锁(通过SELECT … FOR UPDATE语句获得)对应的行级锁也是X锁(但是该行数据实际上还没有被修改),这与理论上的IS锁是有区别的。 锁的兼容性是指当一个应用程序在表(行)上加上某种锁后,其他应用程序是否能够在表(行)上加上相应的锁,如果能够加上,说明这两种锁是兼容的,否则说明这两种锁不兼容,不能对同一数据对象并发存取。
下表为Oracle数据库TM锁的兼容矩阵(Y=Yes,表示兼容的请求; N=No,表示不兼容的请求;-表示没有加锁请求):

表五:Oracle数据库TM锁的相容矩阵

一方面,当Oracle执行SELECT…FOR UPDATE、INSERT、UPDATE、DELETE等DML语句时,系统自动在所要操作的表上申请表级RS锁(SELECT…FOR UPDATE)或RX锁(INSERT、UPDATE、DELETE),当表级锁获得后,系统再自动申请TX锁,并将实际锁定的数据行的锁标志位置位(指向该TX锁);另一方面,程序或操作人员也可以通过LOCK TABLE语句来指定获得某种类型的TM锁。下表是笔者总结了Oracle中各SQL语句产生TM锁的情况:

表六:Oracle数据库TM锁小结

我们可以看到,通常的DML操作(SELECT…FOR UPDATE、INSERT、UPDATE、DELETE),在表级获得的只是意向锁(RS或RX),其真正的封锁粒度还是在行级;另外,Oracle数据库的一个显著特点是,在缺省情况下,单纯地读数据(SELECT)并不加锁,Oracle通过回滚段(Rollback segment)来保证用户不读"脏"数据。这些都提高了系统的并发程度。
由于意向锁及数据行上锁标志位的引入,减小了Oracle维护行级锁的开销,这些技术的应用使Oracle能够高效地处理高度并发的事务请求。
为了监控Oracle系统中锁的状况,我们需要对几个系统视图有所了解:
v$lock视图列出当前系统持有的或正在申请的所有锁的情况,其主要字段说明如下:

表七:v$lock视图主要字段说明

其中在TYPE字段的取值中,本文只关心TM、TX两种DML锁类型;
v$locked_object视图列出当前系统中哪些对象正被锁定,其主要字段说明如下:

表八:v$locked_object视图字段说明

根据上述系统视图,可以编制脚本来监控数据库中锁的状况。
5.3.1 showlock.sql
第一个脚本showlock.sql,该脚本通过连接v$locked_object与all_objects两视图,显示哪些对象被哪些会话锁住:

/* showlock.sql */
column o_name format a10
column lock_type format a20
column object_name format a15
select rpad(oracle_username,10) o_name,session_id sid,
decode(locked_mode,0,'None',1,'Null',2,'Row share',
3,'Row Exclusive',4,'Share',5,'Share Row Exclusive',6,'Exclusive') lock_type,
object_name ,xidusn,xidslot,xidsqn
from v$locked_object,all_objects
where v$locked_object.object_id=all_objects.object_id;
5.3.2 showalllock.sql

第二个脚本showalllock.sql,该脚本主要显示当前所有TM、TX锁的信息;

/* showalllock.sql */
select sid,type,id1,id2,
decode(lmode,0,'None',1,'Null',2,'Row share',
3,'Row Exclusive',4,'Share',5,'Share Row Exclusive',6,'Exclusive')
lock_type,request,ctime,block
from v$lock
where TYPE IN('TX','TM');

总的来说,DB2的锁和Oracle的锁主要有以下大的区别:
1.Oracle通过具有意向锁的多粒度封锁机制进行并发控制,保证数据的一致性。其DML锁(数据锁)分为两个层次(粒度):即表级和行级。通常的DML操作在表级获得的只是意向锁(RS或RX),其真正的封锁粒度还是在行级;DB2也是通过具有意向锁的多粒度封锁机制进行并发控制,保证数据的一致性。其DML锁(数据锁)分为两个层次(粒度):即表级和行级。通常的DML操作在表级获得的只是意向锁(IS,SIX或IX),其真正的封锁粒度也是在行级;另外,在Oracle数据库中,单纯地读数据(SELECT)并不加锁,这些都提高了系统的并发程度,Oracle强调的是能够"读"到数据,并且能够快速的进行数据读取。而DB2的锁强调的是"读一致性",进行读数据(SELECT)时会根据不同的隔离级别(RR,RS,CS)而分别加S,IS,IS锁,只有在使用UR隔离级别时才不加锁。从而保证不同应用程序和用户读取的数据是一致的。
2. 在支持高并发度的同时,DB2和Oracle对锁的操纵机制有所不同:Oracle利用意向锁及数据行上加锁标志位等设计技巧,减小了Oracle维护行级锁的开销,使其在数据库并发控制方面有着一定的优势。而DB2中对每个锁会在锁的内存(locklist)中申请分配一定字节的内存空间,具体是X锁64字节内存,S锁32字节内存(注:DB2 V8之前是X锁72字节内存而S锁36字节内存)。
3. Oracle数据库中不存在锁升级,而DB2数据库中当数据库表中行级锁的使用超过locklist*maxlocks会发生锁升级。
4. 在Oracle中当一个session对表进行insert,update,delete时候,另外一个session仍然可以从Orace回滚段或者还原表空间中读取该表的前映象(before image); 而在DB2中当一个session对表进行insert,update,delete时候,另外一个session仍然在读取该表数据时候会处于lock wait状态,除非使用UR隔离级别可以读取第一个session的未提交的值;所以Oracle同一时刻不同的session有读不一致的现象,而DB2在同一时刻所有的session都是"读一致"的。



ロックの種類

表ロック時に発生する TM エンキューをトレースするには、V$LOCK パフォーマンスビューを理解する必要がある。まず、TMの種類と関係について

1+5 の表ロックモード

LMODEの数字が大きいほど、重度なロックとなる。
LMODEロックの名称呼称旧呼称(別名)?
1なしNULL
2行共有ロックRS/SSRow ShareSub Share
3行排他ロックRX/SXRow eXclusiveSub eXclusive
4共有ロックSShare
5共有行排他ロックSRX/SSXShare Row eXculsiveShare Sub eXculsive
6排他ロックXeXclusive

表ロック同士の関係マトリックス

SELECT / INSERT / UPDATE / DELETE / LOCK TABLE の排他
L*1表ロック先に行なっているコマンドの例別セッションの後続処理に許可されるロックモード(操作)
行共有行排他共有共有
行排他
排他
1なしSELECT ... FROM table ...
2行共有SELECT ... FOR UPDATE [OF ...]×
LOCK TABLE ...
ROW SHARE MODE
×
3行排他INSERT INTO table ...×××
UPDATE table ...×××
DELETE FROM table ...×××
LOCK TABLE ...
ROW EXCLUSIVE MODE
×××
4共有LOCK TABLE ...
SHARE MODE
×××
5共有
行排他
LOCK TABLE ...
SHARE ROW EXCLUSIVE MODE
××××
6排他LOCK TABLE ...
EXCLUSIVE MODE
×××××
 ロックを取得可能
× ロックの取得は不可能
 ロックを取得可能であるが別セッションからの同一行へのアクセスは待機させられる(TX待機)
 ロックを取得可能であるが別セッションからの プライマリキー制約、ユニーク制約 に該当する行の INSERT は待機させられる(TX待機)
▲ ▼ に関して:トランザクションが分散トランザクションの場合には初期化パラメータによってタイムアウトが発生する。
参考 ⇒ ORA-02049: タイムアウト: 分散トランザクションがロックを待機しています。

共有ロックと排他ロック

  • 共有ロック
    共有ロックとは主に参照を行う際に掛けるロックであり複数設定することも可能。しかし SELECT の度にロックを掛けているわけではなく、データや表定義が変更されると困る操作のときにだけ掛けられる。
    例: 更新予定の行を宣言して SELECT する(RSロック)、インデックスの作成中に本体である表定義が変更されないようにロックするなどである。(Sロック)

    簡単に言うと、読み取りが終了(もしくは終わりと宣言 COMMIT,ROLLBACK)するまで  または テーブル定義 は変更しないでねフラグを立てる。
  • 排他ロック
    排他ロックとは更新を行なう際に掛けるロックであり 1リソース(行や表)に対して 1つだけ設定できる。
    こちらは同じリソースを同時に更新させないようにするためのもの。

行共有ロック(RS / SS)

SELECT ...FOR UPDATE 文により「表」に掛けられるロック。
注意: SELECT FOR UPDATE WAIT による WAIT の秒数指定は排他ロック(X) された表に対しては無効になってしまう。
DDL: DROP TABLE(Xロック)、ダイレクト・パス・インサート(X) などが実行できなくなる。

行排他ロック(RX / SX)

INSERT,UPDATE,DELETE 文により、「表」に掛けられるロック。
ALTER INDEX ~ REBUILD ONLINE; (Sロック)が待機する。
インデックスを張っていない外部制約のケースでは行排他ロックから共有ロックや共有行排他ロックへエスカレートする可能性があるので注意が必要(簡単に回避できる:関連事項 ガイドライン参照)

共有ロック(S)

LOCK TABLE table IN SHARE MODE
一部のDDL CREATE INDEX /VIEW/PROCEDURE/SYNONYM などにより「表」に掛けられるロック。
ALTER INDEX ~ REBUILD ONLINE ; (Sロック) では待機状態になる。(CREATE INDEX は NOWAIT)

共有行排他ロック(SRX / SSX)

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE により「表」に掛けられるロック。
身近で、どのSQLコマンドが該当するか、わかりませんでした。
インデックスを張っていない外部制約のケース で CASCADE 設定時に間接的に発生する。

排他ロック(X)

LOCK TABLE table IN EXCLUSIVE MODE
DROP TABLE / ALTER TABLE などにより「表」に掛けられるロック。
一部のDML(ダイレクト・パス・インサート)でも発生する。

2011年2月26日星期六

java线程unchecked 异常的处理UncaughtExceptionHandler(转)

 Thread的run方法是不抛出任何检查型异常(checked exception)的,但是它自身却可能因为一个异常而被终止,导致这个线程的终结。最麻烦的是,在线程中抛出的异常即使在主线程中使用try...catch也无法截获,因此可能导致一些问题出现,比如异常的时候无法回收一些系统资源,或者没有关闭当前的连接等等。 

    主线程之所以不处理子线程抛出的RuntimeException,是因为线程是异步的,子线程没结束,主线程可能已经结束了。 

    UncaughtExceptionHandler名字意味着处理未捕获的异常。更明确的说,它处理未捕获的运行时异常。Java编译器要求处理所有非运行时异常,否则程序不能编译通过。这里“处理”的是方法里throws子句声明的异常或在try-catch块里的catch子句的异常。 

Java代码 
  1. package demo;  
  2.   
  3. import java.lang.Thread.UncaughtExceptionHandler;  
  4.   
  5. public class ThreadTest  
  6. {  
  7.     public static void main(String[] args)  
  8.     {  
  9.         ThreadA a = null;  
  10.         try  
  11.         {  
  12.             ErrHandler handle = new ErrHandler();  
  13.             a = new ThreadA();  
  14.             a.setUncaughtExceptionHandler(handle);// 加入定义的ErrHandler  
  15.             a.start(); // 线程的run抛出的RuntimeException异常无法抓到  
  16.             // a.run(); 普通方法抛出RuntimeException异常可以抓到  
  17.         }  
  18.         catch (Exception e)  
  19.         {  
  20.             System.out.println("catch RunTimeException a"); // 不起作用,但是Exception已经交给handle处理  
  21.         }  
  22.   
  23.         // 普通线程即使使用try...catch也无法捕获到抛出的异常  
  24.         try  
  25.         {  
  26.             ThreadB b = new ThreadB();  
  27.             b.start();  
  28.         }  
  29.         catch (Exception e)  
  30.         {  
  31.             System.out.println("catch RunTimeException b"); // 不起作用  
  32.         }  
  33.     }  
  34.   
  35. }  
  36.   
  37. /** 
  38.  * 自定义的一个UncaughtExceptionHandler 
  39.  */  
  40. class ErrHandler implements UncaughtExceptionHandler  
  41. {  
  42.     /** 
  43.      * 这里可以做任何针对异常的处理,比如记录日志等等 
  44.      */  
  45.     public void uncaughtException(Thread a, Throwable e)  
  46.     {  
  47.         System.out.println("This is:" + a.getName() + ",Message:" + e.getMessage());  
  48.         e.printStackTrace();  
  49.     }  
  50. }  
  51.   
  52. /** 
  53.  * 拥有UncaughtExceptionHandler的线程 
  54.  */  
  55. class ThreadA extends Thread  
  56. {  
  57.     public ThreadA()  
  58.     {  
  59.     }  
  60.   
  61.     public void run()  
  62.     {  
  63.         double i = 12 / 0;// 抛出ArithmeticException的RuntimeException型异常  
  64.     }  
  65. }  
  66.   
  67. /** 
  68.  * 普通线程 
  69.  */  
  70. class ThreadB extends Thread  
  71. {  
  72.     public ThreadB()  
  73.     {  
  74.     }  
  75.   
  76.     public void run()  
  77.     {  
  78.         try  
  79.         {  
  80.             double i = 12 / 0;// 抛出ArithmeticException的RuntimeException型异常  
  81.         }  
  82.         catch (RuntimeException e)  
  83.         {  
  84.             throw e;  
  85.         }  
  86.     }  
  87. }