SQL92事务的隔离级别
SQL 标准用三个必须在并行的事务之间避免的现象定义了四个级别的事务隔离。 这些不希望发生的现象是：
|
隔离级别
|
脏读 (Dirty Read)
|
不可重复读 (NonRepeatable Read)
|
幻读 (Phantom Read)
|
| 读未提交(Read uncommitted) |
可能
|
可能
|
可能
|
| 读已提交(Read committed) |
不可能
|
可能
|
可能
|
|
可重复读(Repeatable read)
|
不可能
|
不可能
|
可能
|
| 可串行化(Serializable) |
不可能
|
不可能
|
不可能
|
Oracle事务的隔离级别
数据库的锁（一般定义）
锁的2种最基本、最简单的类型：排他锁（eXclusive lock，即X锁）、共享锁（Share lock，即S锁）。 不同级别的锁定协议及其作用：
|
申请的锁 及其作用 锁定协议 |
修改时申请X锁 |
读取时申请S锁 |
作用 |
||||
|
操作 结束 释放 |
事务 结束 释放 |
操作 结束 释放 |
事务 结束 释放 |
不 丢失 修改 |
不 脏读 |
可 重复读 |
|
|
一级锁定协议 |
是 |
是 |
|||||
|
二级锁定协议 |
是 |
是 |
是 |
是 |
|||
|
三级锁定协议 |
是 |
是 |
是 |
是 |
是 |
||
锁定对象的大小被称为锁定的粒度（granularity）。 如果在一个数据库管理系统中，同时支持多种锁定粒度供事务选择，这种锁定方法就被称为多粒度锁定（multiple granularity locking）。 多粒度锁定协议是指，允许对多粒度树中的节点单独地加锁，另外，对一个节点加锁还意味着对这个节点的各级子节点也加同样的锁。因此，可以用两种方法对多粒度树中的节点加锁：显式锁定、隐式锁定。显式锁定是在事务中明确指定要加在节点上的锁；隐式锁定是由于在其上级节点中加显式锁时而使该节点获得的锁。
具有意向锁的多粒度锁定方法能提高系统的并发度，减少加锁和解锁的开销。 意向锁的含义是，如果对一个节点加某种意向锁，则表示对它的所有下级节点加这种锁的意向；如果对一个节点加某种锁，则必须先对该节点的各级上级节点加这种意向锁。 有如下几种意向锁。 一、IS锁（Intended Share lock，意向共享锁） 二、IX锁（Intended eXclusive lock，意向排他锁） 三、SIX锁（Share Intended eXclusive lock，共享意向排他锁） 如果对一个节点加SIX锁，则表示对它加S锁，然后再加IX锁，即SIX＝S＋IX。例如，如果事务T对表A加SIX锁，则表示事务T要读取整个表（S锁的作用），同时还会更新某些记录（IX锁的作用）。 包括意向锁的各种锁之间的相容规则：（NL表示没有锁定）
| T保持的锁 Ti想获取的锁 | NL | IS |
IX |
S | SIX | X |
| IS | 可以 | 可以 | 可以 | 可以 | 可以 | 不可以 |
| IX | 可以 | 可以 | 可以 | 不可以 | 不可以 | 不可以 |
| S | 可以 | 可以 | 不可以 | 可以 | 不可以 | 不可以 |
| SIX | 可以 | 可以 | 不可以 | 不可以 | 不可以 | 不可以 |
| X | 可以 | 不可以 | 不可以 | 不可以 | 不可以 | 不可以 |
死锁是一种比较严重的、特殊的锁争用类型。在这种锁争用中，两个或两个以上的用户正在等待对方锁定的资源。因此，如果不进行某种干预，任意一个事务都无法完成。 诊断死锁方法有： *超时法。如果一个事务的等待时间超过了规定的时限，就认为发生了死锁。 *等待图法。这是用离散数学的图论来诊断死锁的方法。事务的等待图是一个有向图G＝（T，U）。T为正在运行的各个事务的节点的集合，U为有向边。如果T1 事务等待T2事务，则在T1、T2节点之间就有一条从T1指向T2的有向边。DBMS的并发控制子系统周期性地（如每隔1分钟）检测事务等待图。如果发现图中存在回路，则表示系统中出现了死锁。
Oracle的锁
在数据库中有两种基本的锁类型：排它锁（Exclusive Locks，即X锁）和共享锁（Share Locks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改；加了共享锁的数据对象可以被其他事务读取，但不能修改。
根据保护对象的不同，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，数据锁）锁。DML锁的目的在于保证并发情况下的数据完整性。在Oracle数据库中，DML锁主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。
意向锁的含义是如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁；对任一结点加锁时，必须先对它的上层结点加意向锁。如：对表中的任一行加锁时，必须先对它所在的表加意向锁，然后再对该行加锁。这样一来，事务对表加锁时，就不再需要检查表中每行记录的锁标志位了，系统效率得以大大提高。
TM锁（表级锁）类型共有5种，分别称为共享锁（S锁）、排它锁（X锁）、行级共享锁（RS锁）、行级排它锁（RX锁）、共享行级排它锁（SRX锁）
当Oracle执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式，在数据库中用0－6来表示。不同的SQL操作产生不同类型的TM锁。如表1所示。
|
表1 Oracle的TM锁类型 |
|||
|
锁模式 |
锁描述 |
解释 |
SQL操作 |
|
0 |
none |
||
|
1 |
NULL |
空 |
Select |
|
2 |
SS(Row-S) |
行级共享锁，其他对象只能查询这些数据行 |
Select for update、Lock for update、Lock row share |
|
3 |
SX(Row-X) |
行级排它锁，在提交前不允许做DML操作 |
Insert、Update、Delete、Lock row share |
|
4 |
S(Share) |
共享锁 |
Create index、Lock share |
|
5 |
SSX(S/Row-X) |
共享行级排它锁 |
Lock share row exclusive |
|
6 |
X(Exclusive) |
排它锁 |
Alter table、Drop able、Drop index、Truncate table 、Lock exclusive |
1. 共享锁（Share Table Lock，S）：
加锁语法：Lock Table TableName In Share Mode;
允许的操作：一个共享锁由一个事务控制，仅允许其它事务查询被锁定的表。一个有效的共享锁明确地用Select … For update形式锁定行，或执行Lock Table TableName In Share Mode语法锁定整个表，不允许被其它事务更新。
禁止的操作：一个共享锁由一个事务来控制，防止其它事务更新该表或执行下面的语句：
LOCK TABLE TableName IN SHARE ROW EXCLUSIVE MODE;
LOCK TABLE TableName IN ROW EXCLUSIVE MODE;
2. 排它锁（Exclusive Table Lock，X）：
排它锁是在锁机制中限制最多的一种锁类型，允许加排它锁的事务独自控制对表的写权限。
加锁语法：Lock Table TableName In Exclusive Mode;
允许的操作：在一个表中只能有一个事务对该表实行排它锁，排它锁仅允许其它的事务查询该表。
禁止的操作：拥有排外锁的事务禁止其它事务执行其它任何DML类型的语句或在该表上加任何其它类型的锁。
定义排它锁的语法：
LOCK TABLE TableName IN EXCLUSIVE MODE;
3. 行级锁（Row Share Table Lock，RS）：
一个行级锁（有时称为Subshare Table Lock，简称SS，子共享锁）需要该事务在被锁定行的表上用update的形式加锁。当有下面语句被执行的时候行级锁自动加在操作的表上。
SELECT . . . FROM TableName. . . FOR UPDATE OF . . . ;
LOCK TABLE TableName IN ROW SHARE MODE;
行级锁（Row Share Table Lock）在锁类型中是限制最少的，也是在表的并发程度中使用程度最高的。
允许的操作：行级共享锁由一个事务控制，允许其它事务查询、插入、更新、删除或同时在同一张表上锁定行。因此其它事务可以同时在同一张表上得到行级锁、共享行级排它锁、行级排它锁、排它锁。
禁止的操作：拥有行级锁的事务不允许其它事务执行排它锁，即：
Lock Table TableName In Exclusive Mode;
4. 行级排它锁（Row Exclusive Table Lock，RX）：
行级排它锁（亦称为Subexclusive Table Lock，简称SX，子排它锁）通常需要事务拥有的锁在表上被更新一行或多行。当有下面语句被执行的时候行级排它锁被加在操作的表上。
INSERT INTO TableName. . . ;
UPDATE TableName. . . ;
DELETE FROM TableName. . . ;
LOCK TABLE TableName IN ROW EXCLUSIVE MODE;
行级排它锁比行级锁稍微多一些限制。
允许的操作：行级排它锁由一个事务拥有允许其它事务执行查询、修改、插入、删除或同时在同一张表上锁定行。执有行级排它锁的事务允许其它事务在同一张表上同时得到共享锁和行级排它锁。
禁止的操作：行级排它锁由一个事务拥有防止其它事务手动锁定表来排除其它事务的读写权。因此，其它事务不允许在同一张表上使用以下的语句来执行锁事务。
LOCK TABLE table IN SHARE MODE;
LOCK TABLE table IN SHARE EXCLUSIVE MODE;
LOCK TABLE table IN EXCLUSIVE MODE
5. 共享行级排它锁（Share Row Exclusive Table Lock，SRX）：
共享行级排它锁有时也称共享子排它锁（Share Subexclusive Table Lock，SSX），它比共享锁有更多限制。定义共享行级排它锁的语法为：
Lock Table TableName In Share Row Exclusive Mode;
允许的操作：仅允许一个事务在某一时刻得到行级排它锁。拥有行级排它锁事务允许其它事务在被锁定的表上执行查询或使用Select … From TableName For update…来准确在锁定行而不能更新行。
禁止的操作：拥有行级排它锁的事务不允许其它事务有除共享锁外的其它形式的锁加在同一张表上或更新该表。即下面的语句是不被允许的：
LOCK TABLE TableName IN SHARE MODE;
LOCK TABLE TableName IN SHARE ROW EXCLUSIVE MODE;
LOCK TABLE TableName IN ROW EXCLUSIVE MODE;
LOCK TABLE TableName IN EXCLUSIVE MODE;
当Oracle数据库发生TX锁等待时，如果不及时处理常常会引起Oracle数据库挂起，或导致死锁的发生，产生ORA-60的错误。
TX锁等待的分析
Oracle数据库中一般使用行级锁。
当Oracle检测到死锁产生时，中断并回滚死锁相关语句的执行，报ORA-00060的错误并记录在数据库的日志文件alertSID.log中。同时在user_dump_dest下产生了一个跟踪文件，详细描述死锁的相关信息。
在日常工作中，如果发现在日志文件中记录了ora-00060的错误信息，则表明产生了死锁。这时需要找到对应的跟踪文件，根据跟踪文件的信息定位产生的原因。
|
表2 数据字典视图说明 |
||
|
视图名 |
描述 |
主要字段说明 |
|
v$session |
查询会话的信息和锁的信息。 |
sid,serial#：表示会话信息。 program：表示会话的应用程序信息。 row_wait_obj#：表示等待的对象，和dba_objects中的object_id相对应。 |
|
v$session_wait |
查询等待的会话信息。 |
sid：表示持有锁的会话信息。 Seconds_in_wait：表示等待持续的时间信息 Event：表示会话等待的事件。 |
|
v$lock |
列出系统中的所有的锁。 |
Sid：表示持有锁的会话信息。 Type：表示锁的类型。值包括TM和TX等。 ID1：表示锁的对象标识。 lmode,request：表示会话等待的锁模式的信 息。用数字0－6表示，和表1相对应。 |
|
dba_locks |
对v$lock的格式化视图。 |
Session_id：和v$lock中的Sid对应。 Lock_type：和v$lock中的type对应。 Lock_ID1： 和v$lock中的ID1对应。 Mode_held,mode_requested：和v$lock中 的lmode,request相对应。 |
|
v$locked_object |
只包含DML的锁信息，包括回滚段和会话信息。 |
Xidusn,xidslot,xidsqn：表示回滚段信息。和 v$transaction相关联。 Object_id：表示被锁对象标识。 Session_id：表示持有锁的会话信息。 Locked_mode：表示会话等待的锁模式的信 息，和v$lock中的lmode一致。 |
解锁及Kill Session:
使用下面的语法查出锁并杀掉Session。
SELECT A.SID,A.SERIAL#,A.USERNAME,B.TYPE FROM V$SESSION A,V$LOCK B WHERE A.SID=B.SID;
ALTER SYSTEM KILL SESSION 'SID,SERIAL#';
Oracle的并发控制
Spring事务的传播性
********************sample***********************
ServiceA {
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
ServiceB.methodB();
}
}
ServiceB {
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodB() {
}
}
*************************************************
1： PROPAGATION_REQUIRED
加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务
比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，
ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA
的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。
这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被
提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚
2： PROPAGATION_SUPPORTS
如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行
3： PROPAGATION_MANDATORY
必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常
4： PROPAGATION_REQUIRES_NEW
这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，
那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，
他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在
两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，
如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。
5： PROPAGATION_NOT_SUPPORTED
当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，
那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。
6： PROPAGATION_NEVER
不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED， 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，
那么ServiceB.methodB就要抛出异常了。
7： PROPAGATION_NESTED
理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，
而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。
而Nested事务的好处是他有一个savepoint。
*****************************************
ServiceA {
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
try {
//savepoint
ServiceB.methodB(); //PROPAGATION_NESTED 级别
} catch (SomeException) {
// 执行其他业务, 如 ServiceC.methodC();
}
}
}
********************************************
也就是说ServiceB.methodB失败回滚，那么ServiceA.methodA也会回滚到savepoint点上，ServiceA.methodA可以选择另外一个分支，比如
ServiceC.methodC，继续执行，来尝试完成自己的事务。
但是这个事务并没有在EJB标准中定义。
J2EE的事务控制策略概述
http://www.cnblogs.com/heartstage/p/3418667.html
Hibernate的事务控制
http://ch-space.iteye.com/blog/380419
http://tech.sina.com.cn/s/2005-08-19/1153698440.shtml
http://bbs.csdn.net/topics/380260812
http://blog.163.com/zhoutianwen_999/blog/static/96040562200801921247753/
http://www.iteye.com/topic/177988
Oracle中的事务和SQLServer中的事务的差异
在SQL92标准中，事务隔离级别分为四种，分别为：Read Uncommitted、Read Committed、Read Repeatable、Serializable，其中Read Uncommitted与Read Committed为语句级别的，而Read Repeatable与Serializable是针对事务级别的。
在Oracle和SQL Server中设置事务隔离级别的语句是相同的，都使用SQL92标准语法，即：
Set Transaction Isolation Level Read Committed
上面示例中的Read Committed可以被替换为其他三种隔离级别中的任意一种。
1.SQL Server中的隔离级别及实现机制
在SQL Server中提供了所有这四种隔离级别。
下面我们讨论在SQL Server中，这几种隔离级别的含义及其实现方式。
Read Uncommitted：一个会话可以读取其他事务未提交的更新结果，如果这个事务最后以回滚结束，这时的读取结果就可能是错误的，所以多数的数据库应用都不会使用这种隔离级别。
Read Committed：这是SQL Server的缺省隔离级别，设置为这种隔离级别的事务只能读取其他事务已经提交的更新结果，否则，发生等待，但是其他会话可以修改这个事务中被读取的记 录，而不必等待事务结束，显然，在这种隔离级别下，一个事务中的两个相同的读取操作，其结果可能不同。
Read Repeatable：在一个事务中，如果在两次相同条件的读取操作之间没有添加记录的操作，也没有其他更新操作导致在这个查询条件下记录数增多，则两次 读取结果相同。换句话说，就是在一个事务中第一次读取的记录保证不会在这个事务期间发生改变。SQL Server是通过在整个事务期间给读取的记录加锁实现这种隔离级别的，这样，在这个事务结束前，其他会话不能修改事务中读取的记录，而只能等待事务结 束，但是SQL Server不会阻碍其他会话向表中添加记录，也不阻碍其他会话修改其他记录。
Serializable：在一个事务中，读取操作的结果是在这个事务开始之前其他事务就已经提交的记录，SQL Server通过在整个事务期间给表加锁实现这种隔离级别。在这种隔离级别下，对这个表的所有DML操作都是不允许的，即要等待事务结束，这样就保证了在 一个事务中的两次读取操作的结果肯定是相同的。
2.Oracle中的隔离级别及实现机制
在Oracle中，没有Read Uncommitted及Repeatable Read隔离级别，这样在Oracle中不允许一个会话读取其他事务未提交的数据修改结果，从而避免了由于事务回滚发生的读取错误。Oracle中的 Read Committed和Serializable级别，其含义与SQL Server类似，但是实现方式却大不一样。
在Oracle中，存在所谓的回滚段(Oracle9i之前版本)或撤销段(Oracle9i版本)，Oracle在修改数据记录时，会把这些 记录被修改之前的结果存入回滚段或撤销段中，就是因为这种机制，Oracle对于事务隔离级别的实现与SQL Server截然不同。在Oracle中，读取操作不会阻碍更新操作，更新操作也不会阻碍读取操作，这样在Oracle中的各种隔离级别下，读取操作都不 会等待更新事务结束，更新操作也不会因为另一个事务中的读取操作而发生等待，这也是Oracle事务处理的一个优势所在。
Oracle缺省的设置是Read Committed隔离级别(也称为语句级别的隔离)，在这种隔离级别下，如果一个事务正在对某个表进行DML操作，而这时另外一个会话对这个表的记录进 行读取操作，则Oracle会去读取回滚段或撤销段中存放的更新之前的记录，而不会象SQL Server一样等待更新事务的结束。
在Serializable隔离级别(也称为事务级别的隔离)，事务中的读取操作只能读取这个事务开始之前已经提交的数据结果。如果在读取时， 其他事务正在对记录进行修改，则Oracle就会在回滚段或撤销段中去寻找对应的原来未经更改的记录(而且是在读取操作所在的事务开始之前存放于回滚段或 撤销段的记录)，这时读取操作也不会因为相应记录被更新而等待。