数据库事务

转自：http://www.itpub.net/thread-914687-1-1.html

一.  简介

事务处理是所有大型数据库产品的一个关键问题，各数据库厂商都在这个方面花费了很大精力，不同的事务处理方式会导致数据库性能和功能上的巨大差异。

事务处理也是数据库管理员与数据库应用程序开发人员必须深刻理解的一个问题，对这个问题的疏忽可能会导致应用程序逻辑错误以及效率低下。下面我们针对Oracle及SQL Server这两种当前广泛使用的大型数据库产品，探讨一下它们在事务处理方面的一些差异。如没有特殊说明，本文内容适用的数据库产品版本为Oracle9i及SQL Server 2000，其中的示例SQL语句，对于Oracle是在SQL*Plus中执行，而对于SQL Server 2000是在osql中执行。

二. 事务的概念

事务可以看作是由对数据库的若干操作组成的一个单元，这些操作要么都完成，要么都取消，从而保证数据满足一致性的要求。事务的一个典型例子是银行中的转帐操作，帐户A把一定数量的款项转到帐户B上，这个操作包括两个步骤，一个是从帐户A上把存款减去一定数量，二是在帐户B上把存款加上相同的数量。这两个步骤显然要么都完成，要么都取消，否则银行就会受损失。显然，这个转帐操作中的两个步骤就构成一个事务。

数据库中的事务还有如下ACID特征，ACID分别是四个英文单词的首写字母，这四个英文单词是Atomicity、Consistency、Isolation、Durability，分别翻译为原子性、一致性、隔离性、持久性。

• 原子性：指事务中的操作，或者都完成，或者都取消。
• 一致性：指事务中的操作保证数据库中的数据不会出现逻辑上不一致的情况，一致性一般会隐含的包括在其他属性之中。
• 隔离性：指当前的事务与其他未完成的事务是隔离的。在不同的隔离级别下，事务的读取操作，可以得到的结果是不同的。
• 持久性：指对事务发出COMMIT命令后，即使这时发生系统故障，事务的效果也被持久化了。与此相反的是，当在事务执行过程中，系统发生故障，则事务的操作都被回滚，即数据库回到事务开始之前的状态。

对数据库中的数据修改都是在内存中完成的，这些修改的结果可能已经写到硬盘也可能没有写到硬盘，如果在操作过程中，发生断电或系统错误等故障，数据库可以保证未结束的事务对数据库的数据修改结果即使已经写入磁盘，在下次数据库启动后也会被全部撤销；而对于结束的事务，即使其修改的结果还未写入磁盘，在数据库下次启动后会通过事务日志中的记录进行“重做”，即把丢失的数据修改结果重新生成，并写入磁盘，从而保证结束事务对数据修改的永久化。这样也保证了事务中的操作要么全部完成，要么全部撤销。

三. 事务设置及类型的区别

在SQL Server中有三种事务类型，分别是：隐式事务、显式事务、自动提交事务，缺省为自动提交。

• 自动提交：是指对于用户发出的每条SQL语句，SQL Server都会自动开始一个事务，并且在执行后自动进行提交操作来完成这个事务，也可以说在这种事务模式下，一个SQL语句就是一个事务。
• 显式事务：是指在自动提交模式下以Begin Transaction开始一个事务，以Commit或Rollback结束一个事务，以Commit结束事务是把事务中的修改永久化，即使这时发生断电这样的故障。例如下面是SQL Server中的一个显式事务的例子。       

Begin TranUpdate emp Set ename=’Smith’ Where empno=7369Insert Into dept Values(60,’HR’,’GZh’)Commit

• 隐式事务：是指在当前会话中用Set Implicit_Transactions On命令设置的事务类型，这时任何DML语句(Delete、Update、Insert)都会开始一个事务，而事务的结束也是用Commit或Rollback。

在Oracle中没有SQL Server的这些事务类型，缺省情况下任何一个DML语句都会开始一个事务，直到用户发出Commit或Rollback操作，这个事务才会结束，这与SQL Server的隐式事务模式相似。

四. 事务隔离级别

在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操作都是不允许的，即要等待事务结束，这样就保证了在一个事务中的两次读取操作的结果肯定是相同的。
• Read-only：read only是serializable的子集。它们都避免了非重复读和幻像。区别是在read only中是只读，不允许在本事务中进行DML操作。而在serializable中可以进行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就会在回滚段或撤销段中去寻找对应的原来未经更改的记录(而且是在读取操作所在的事务开始之前存放于回滚段或撤销段的记录)，这时读取操作也不会因为相应记录被更新而等待。

3.  不同隔离级别不同的效果

通过一些现象，可以反映出隔离级别的效果。这些现象有：

• 更新丢失（lost update）：当系统允许两个事务同时更新同一数据是，发生更新丢失。

• 脏读（dirty read）：当一个事务读取另一个事务尚未提交的修改时，产生脏读。

• 非重复读（nonrepeatable read）：同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。(A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data. )

• 幻像（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，每次返回不同的结果集，此时发生幻像读。(A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another committed transaction has inserted additional rows that satisfy the condition. )

下面是隔离级别及其对应的可能出现或不可能出现的现象

五. 事务传播特性

事务的传播特性主要分以下几种类别：

• PROPAGATION_REQUIRED：支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。

• PROPAGATION_SUPPORTS：支持当前事务，如果当前没有事务，就以非事务方式执行。

• PROPAGATION_MANDATORY：支持当前事务，如果当前没有事务，就抛出异常。

•  PROPAGATION_REQUIRES_NEW：新建事务，如果当前存在事务，把当前事务挂起。

•  PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。

•  PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

• PROPAGATION_NESTED：支持当前事务，新增Savepoint点，与当前事务同步提交或回滚。

用一个具体的例子来分别解释下以上的事务传播特性：

<pre name="code" class="java"><span style="font-size:14px;">    void methodA() {    try {        ServiceB.methodB();     } catch (SomeException) {    //TODO    }    }</span>

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也要回滚。

PROPAGATION_SUPPORTS

如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行。

PROPAGATION_MANDATORY

必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常。

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事务仍然可能提交。

PROPAGATION_NOT_SUPPORTE

当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。

PROPAGATION_NEVER

不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED， 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，那么ServiceB.methodB就要抛出异常了。

PROPAGATION_NEST

理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立， 而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。而Nested事务的好处是他有一个savepoint。也就是说ServiceB.methodB失败回滚，那么ServiceA.methodA也会回滚到savepoint点上，ServiceA.methodA可以选择另外一个分支，比如 ServiceC.methodC，继续执行，来尝试完成自己的事务。 但是这个事务并没有在EJB标准中定义。

六. DDL语句对事务的影响

1.Oracle中DDL语句对事务的影响

在Oracle中，执行DDL语句(如Create Table、Create View等)时，会在执行之前自动发出一个Commit命令，并在随后发出一个Commit或者Rollback命令，也就是说，DDL会象如下伪码一样执行：

Commit;DDL_Statement;If (Error) thenRollback;ElseCommit;End if;

我们通过分析下面例子来看Oracle中，DDL语句对事务的影响：

Insert into some_table values(‘Before’);Creaate table T(x int);Insert into some_table values(‘After’);Rollback;

由于在Oracle执行Create table语句之前进行了提交，而在Create table执行后也会自动发出Commit命令，所以只有插入After的行被回滚，而插入Before的行不会被回滚，Create table命令的结果也不会被回滚，即使Create table语句失败，所进行的Before插入也会被提交。如果最后发出Commit命令，因为插入Before及Create table的操作结果已经在之前提交，所以Commit命令影响的只有插入After的操作。

2.SQL Server中DDL语句对事务的影响

在SQL Server中，DDL语句对事务的影响与其他DML语句相同，也就是说，在DML语句发出之前或之后，都不会自动发出Commit命令。
在SQL Server 2000中，对于与上面Oracle同样的例子，最后发出Rollback后，数据库会回滚到插入Before之前的状态，即插入Before和After的行都会被回滚，数据表T也不会被创建。如果最后发出Commit操作，则会把三个操作的结果全部提交。

六. 用户断开数据库连接对事务的影响

另外，对应于Oracle的管理客户端工具SQL*Plus，在SQL Server 2000中是osql，两种管理工具都是命令行工具，使用方式及作用也类似，但是在SQL*Plus中，用户退出连接时，会自动先发出Commit命令，然后再退出，而在osql中，如果用户退出连接，会自动发出Rollback命令，这对于SQL Server的自动提交模式没有什么影响，但如果处于隐式事务模式，其影响是显而易见的。对于两种数据库产品的其他客户端管理工具也有类似的不同之处。