本部分解释了在Oracle和Microsoft SQL Server事务是如何执行的，并且提供了所有数据库类型中锁定过程和并行问题之间的区别。

事务

在Oracle中，执行插入、更新或者删除操作时自动开始事务。一个应用程序必须给出一个COMMIT命令来保存数据库的所有修改。如果没有执行COMMIT，所有的修改都将后滚或者自动变成未完成的。

缺省情况下，Microsoft SQL Server在每次插入、更新或者删除操作之后自动执行一个COMMIT语句。因为数据是自动保存的，你不能后滚任何改变。你可以使用隐式的或者显式的事务模式来改变这个缺省行为。

隐式的事务模式允许SQL Server像Oracle一样运转，这种模式是用SET IMPLICIT_TRANSACTIONS ON语句激活的。如果该选项是ON并且当前没有突出的事务，则每一个SQL语句自动开始一个事务。如果有一个打开的事务，则不会有任何新的事务开始。打开的事务必须由用户用COMMIT TRANSACTION语句来显明的承诺，以使所有的改变生效并且释放所有的锁定。

一个显明的事务是一组由下述事务分隔符包围的SQL语句：

• BEGIN TRANSACTION [transaction_name]
• COMMIT TRANSACTION [transaction_name]
• ROLLBACK TRANSACTION [transaction_name | savepoint_name]

在下面这个例子中，英语系被改变为文学系。请注意BEGIN TRANSACTION和COMMIT TRANSACTION语句的用法。

所有显明的事务必须用BEGIN TRANSACTION...COMMIT TRANSACTION语句封闭。SAVE TRANSACTION语句的功能同Oracle中的SAVEPOINT命令是一样的，在事务中设置一个保存点，这样就可以进行部分后滚（roll back）了。

事务可以嵌套。如果出现了这种情况，最外层的一对创建并提交事务，内部的对跟踪嵌套层。当遇到一个嵌套的事务时，@@TRANCOUNT函数就增加。通常，这种显然的事务嵌套发生在存储程序或者有BEGIN…COMMIT对互相调用的触发器中。尽管事务可以嵌套，但是对ROLLBACK TRANSACTION语句的行为的影响是很小的。

在存储过程和触发器中，BEGIN TRANSACTION语句的个数必须和COMMIT TRANSACTION语句的个数相匹配。包含不匹配的BEGIN TRANSACTION和COMMIT TRANSACTION语句的存储过程和触发器在运行的时候会产生一个错误消息。语法允许在一个事务中调用包含BEGIN TRANSACTION和COMMIT TRANSACTION语句对的存储过程和触发器。

只要情况许可，就应该把一个大的事务分成几个较小的事务。确保每个事务都在一个单独的batch中有完整的定义。为了把可能的并行冲突减到最小，事务既不应该跨越多个batch，也不应该等待用户输入。把多个事务组合到一个运行时间较长的事务中会给恢复时间带来消极的影响，并且还会造成并行问题。

在使用ODBC编程的时候，你可以通过使用SQLSetConnectOption函数来选择显式或者隐式的事务模式。究竟该选择哪种模式要视AUTOCOMMIT连接选项的情况而定。如果AUTOCOMMIT是ON（缺省的），你就是在显式模式中。如果AUTOCOMMIT是OFF，则在隐式模式下。

如果你通过SQL Server Query Analyzer或者其他查询工具使用脚本，你可以显式的包括一个上面提到的BEGIN TRANSACTION语句，也可以利用SET IMPLICIT_TRANSACTIONS ON语句来开始脚本。BEGIN TRANSACTION的方法更灵活一些，而隐式的方法更适合Oracle。

锁定和事务孤立

Oracle和Microsoft SQL Server有着很不一样的锁定和孤立策略。当你把Oracle应用程序转化为SQL Server应用程序的时候，你必须考虑到这些不同以确保应用程序的可伸缩性。

Oracle对所有读数据的SQL语句隐式或者显式的使用一种多版本一致模型（multiversion consistency model）。在这种模型中，数据读者在读数据行以前，缺省的既不获得一个锁定也不等待其他的锁定解开。当读者需要一个已经改变但别的写入者还没有提交的数据时，Oracle通过使用后滚段来重建一个数据行的快照的方法来重新创建旧的数据。

Oracle中的数据写入者在更新、删除或者插入数据时要请求锁定。锁定将一直维持到事务结束，并且禁止别的用户覆盖尚未提交的修改。

Microsoft SQL Server使用多粒度锁定，该锁定允许用事务来锁定不同类型的资源。为了把锁定的开销降到最低，SQL Server自动在与任务相配的层次上锁定资源。以较小的间隔尺寸锁定，例如行，增强了并行，但是管理开销较大，因为如果有许多行锁定，就必须维持多个锁定。以较大的间隔尺寸锁定，例如表，在并行方面是昂贵的，因为对整个表的锁定限制了其他事务对表中任何一部分的访问，但是管理开销却比较小，因为只要维持少数几个锁定。SQL Server可以锁定这些资源（按照间隔尺寸递增的顺序排列）。

SQL Server使用不同的锁定模式锁定资源，使用哪种模式决定了当前事务访问如何访问资源。

对于任何RDBMS都很重要的一点是，快速释放锁定以提供最大的并行性。你可以通过尽可能短的保持一个事务来确保快速释放锁定。如果可能的话，事务不应该跨越多个往返行程到服务器，也不应该包括用户“思考”的时间。如果你使用游标，你也应该使你的应用程序很快提取数据，因为未提取数据的扫描将在服务器上占据共享锁定，因此将阻碍更新。欲了解更多信息，请参看本章后面的“使用ODBC”部分。

改变缺省的锁定行为

Microsoft SQL Server和Oracle都允许开发人员使用非缺省的锁定和孤立行为。在Oracle中，最普通的机制是SELECT 命令的FOR UPDATE子句，SET TRANSACTION READ ONLY命令，以及显式的LOCK TABLE命令。

因为两者的锁定和孤立策略如此不同，所以很难在Oracle和SQL Server之间直接映射锁定选择。要更好的理解这一过程，重要的一点是理解SQL Server提供的修改缺省锁定行为的选择。

在SQL Server中，修改缺省锁定行为最常用的机制是SET TRANSACTION ISOLATION LEVEL语句和在SELECT和UPDATE语句中支持的锁定暗示。SET TRANSACTION ISOLATION LEVEL语句为一个用户会话的持续时间设定事务孤立级别。除非在一个SQL语句的FROM子句中标明了表级别的锁定暗示，否则这将变成该会话的缺省行为。事务孤立是这样设定的：

• READ COMMITTED

缺省的SQL Server孤立级别。如果你使用这种选择，你的应用程序将不能读取其他事务还没有提交的数据。在这种模式下，一旦数据从页上读出，仍然要释放共享锁定。如果应用程序在同一个事务中重新读取同一个的数据区，将会看到别的用户做的修改。

• SERIALIZABLE

如果设定了这种选择，事务将同其他事务孤立起来。如果你不希望在查询中看到其他用户做的修改，你可以设置事务的孤立级别为SERIALIZABLE。SQL Server将占据所有的共享锁定，直到事务结束。你可以通过在SELECT语句中表名的后面使用HOLDLOCK暗示来在一个更小的级别上取得同样的效果。

• READ UNCOMMITTED

如果设定为这种选择，SQL Server读者将不会受到阻塞，就像在Oracle中一样。该选择实现了污损读取或者说是孤立级别为0的锁定，这意味着不使用任何共享锁定并且也不使用任何独占的锁定。当这个选项选定后，有可能会读到未提交的或者污损的数据；在事务结束以前，数据可能会改变，数据集中的行可能出现也可能消失。这个选项同一个事务中在所有SELECT语句中设定所有的表为NOLOCK的效果是一样的。这是四种孤立级别中限制性最小的一种。只有在你已经彻底的搞清楚了它将对你的应用程序结果的精确度有什么样的影响的前提下才能使用这种选择。

SQL Server有两种方法实现Oracle中的READ ONLY功能：

• 如果一个应用程序中的事务需要可重复读取的行为，你也许需要使用SQL Server提供的SERIALIZABLE孤立级别。
• 如果所有的数据库访问都是只读的，你可以设置SQL Server数据库选项为READ ONLY来提高性能。

SELECT…FOR UPDATE

当一个应用程序利用WHERE CURRENT OF 语法来在一个游标上实现定位更新或者删除时，首先使用Oracle中的SELECT…FOR UPDATE语句。在这种情况下，可以随意去掉FOR UPDATE子句，因为Microsoft SQL Server游标的缺省行为是“可更新的”。

缺省情况下，SQL Server游标在提取行下不占据锁定。SQL Server使用一种乐观的并行策略（optimistic concurrency strategy）来防止更新时相互之间的覆盖。如果一个用户试图更新或者删除一个读入游标后已经被修改过的行，SQL Server将给出一个错误消息。应用程序可以捕获该消息，并且重新进行适当的更新或者删除。要改变这个行为，开发人员可以在游标声明中使用SCROLL_LOCKS。

通常情况下，乐观的并行策略支持较高的并行性，所谓通常情况是指更新器之间冲突很少的情况。如果你的应用程序确实需要保证一行在被提取以后不会被修改，你可以在SELECT语句中使用UPDLOCK暗示。这个暗示不会阻碍别的读者，但是它禁止其他潜在的写入者也获得该数据的更新锁定。使用ODBC时，你可以通过使用SQLSETSTMTOPTION (…,SQL_CONCURRENCY)= SQL_CONCUR_LOCK来达到同样的目的。但是，其他的任何选择都将减少并行性。

表级别的锁定

Microsoft SQL Server可以用SELECT…table_name (TABLOCK)语句来锁定整个表。这和Oracle的 LOCK TABLE…IN SHARE MODE语句是一样的。该锁定允许其他人读取一个表，但是禁止他们修改该表。缺省情况下，锁定将维持到语句的结束。如果你同时加上了HOLDLOCK关键字（SELECT…table_name (TABLOCK HOLDLOCK)），表的锁定将一直维持到事务的结束。

可以用SELECT…table_name (TABLOCKX)语句在一个SQL Server表上设置一个独占的锁定。该语句请求一个表上的独占锁定。该锁定禁止其他人读取和修改该表，并且将一直维持到命令或者事务结束。这同Oracle中TABLE…IN EXCLUSIVE MODE语句的功能是一样的。

SQL Server没有为显式的锁定请求提供NOWAIT选项。

锁定升级

当一个查询向表请求行时，Microsoft SQL Server自动生成一个页级别的锁定。但是，如果查询请求表中的大部分行时，SQL Server将把锁定从页级别升级到表级别。这个过程叫做锁定升级。

锁定增加使那些产生较大结果集的表的扫描和操作更加有效，因为它减少了锁定的管理开销。缺少WHERE子句的SQL语句一般都要造成锁定增加。

在读取操作中，如果一个共享页级别的锁定增加为一个表锁定时，将应用一个共享表锁定（TABLOCK）。在下列情况下应用共享的表级别的锁定：

• 使用了HOLDLOCK或者SET TRANSACTION ISOLATION LEVEL SERIALIZABLE语句。
• 优化器选择了一个表的扫描。
• 表中积累的共享锁定的数目超过锁定升级的极限。

表中缺省的锁定升级的极限是200页，但是该极限可以用最小和最大范围定制为依赖于表尺寸的一个百分比。欲了解关于锁定升级极限的更多信息，请参看SQL Server联机手册。

在一个写操作中，当一个UPDATE锁定被升级为一个表锁定时，应用一个独占表锁定（TABLOCKX）。独占表锁定在下列情况下使用：

• 更新或者删除操作无索引可用。
• 表中有独占锁定的页的数目超过锁定升级上限。
• 创建了一个分簇的索引。

Oracle不能升级行级别的锁定，这将导致一些包含了FOR UPDATE子句的查询出问题。例如，假设STUDENT表有100，000行数据，并且一个Oracle用户给出下列语句：

这个语句强制Oracle RDBMS依次锁定STUDENT表的一行；这将花去一段时间。它永远也不会要求升级锁定到整个表。

在SQL Server同样的查询是：

当这个查询运行的时候，页级别的锁定升级为表级别的锁定，后者更加有效并且明显要快一些。