SQL Server 2005 Beta 2 快照隔离

来源：这里教程网时间：2026-03-02 10:00:16 作者：

Ref: http://www.microsoft.com/china/technet/prodtechnol/sql/2005/sql05b.mspx[@more@]

SQL Server 和 Oracle 在快照上的不同之处

Microsoft SQL Server 2005

Oracle

不需要进行表修改

在使用 SERIALIZABLE 前需要使用 INITRANS >= 3 & MAXTRANS on CREATE/ALTER TABLE DDL 来启用页面上事务信息的空间。

版本存储被保存在 TempDB 中。DBA 必须确保基于版本存储工作负载为改进的 i/o 带宽优化 TempDB，因此必须监视 TempDB 数据库大小，很多版本的 SQL Server 都支持百分比和绝对数据库/日志自动增长设置，但这些显然受到磁盘物理可用性的限制。

要求 ROLLBACK SEGMENTS（定义和联机/脱机）的复杂配置和事务级别 USE ROLLBACK SEGMENT 语句以避免 ORA-01555：“长期运行”事务导致的“快照太旧。”覆盖它们在回滚部分的版本控制页。注意：Oracle 没有“长期运行”事务的定义。

TempDB 可以按照当前大小的 %（以便弹性地减少自动增长尝试的次数）或是按照某个绝对值来自动增长。

ROLLBACK SEGMENTS 不支持 PCTINCREASE，因此也不会“自动增长”，所以您必须在创建它们时取得大小。

基于行的数据版本控制 – 写入版本存储/从版本存储中读取的数据量更少，行级版本控制意味着事务化数据访问的真正行级顺序

基于页的数据版本控制 – Oracle 必须重新构建整个页。当其他事务使用 SERIALIZABLE 访问已更新页上的其他行时会导致 ORA-08177："Can't serialize access for this transaction."

Snapshot Isolation 和 Read Committed 在数据库级别上被启用。只有要求此选项的数据库需要启用它，并产生与它相关的开销。您必须使用快照隔离在各个将要参加交叉数据库事务的数据库中启用它。

数据版本控制不是可选的；它总是被启用。

大量的操作“性能计数器”，允许 DBA 监视版本存储的状态，包括：

•	TempDB 中的可用空间
•	版本存储的大小
•	增长率
•	冲突数
•	最长期运行活动事务

Perfmon 计数器

虚拟表允许 DBA 查看快照事务是否已产生，以及版本存储的大小和版本存储中的最早记录：

•	sys.dm_tran_active_snapshot_database_transactions()
•	sys.dm_tran_top_version_generators()
•	sys.dm_tran_transactions_snapshot()
•	sys.dm_tran_current_transaction()

sys.dm_tran_version_store()

虚拟表

Oracle 和 SQL Server 2005 之间既有如上所述的不同之处（这些不同是为了方便数据库管理员的工作），也有相同之处（为了方便开发人员将应用程序从 Oracle 端接到 Microsoft SQL Server 2005）。

SQL Server 和 Oracle 在快照上的相同之处

Microsoft SQL Server 2005	Oracle
SELECT ( WITH (UPDLOCK) 等价项，立即执行冲突检查	SELECT( FOR UPDATE 用于锁定事务中的记录以防止冲突
READ COMMITTED（带有行版本控制）	READ COMMITTED
SNAPSHOT	SERIALIZABLE
SNAPSHOT	READ ONLY
READ UNCOMMITTED（访问未提交的数据）	没有等价项
READ COMMITTED（锁定）	没有等价项
REPEATABLE READ	没有等价项
SERIALIZABLE	没有等价项
可以在乐观隔离级别中使用锁定或必须处理冲突（数据行在事务外更新）并重新尝试已经失败的事务。行级版本控制减少了冲突的机会。	必须处理冲突（ORA-08177：数据页在事务外更新）并重新尝试已经失败的事务。
应用程序可以选择合适的并发模式。	应用程序总是看见可能的陈旧数据，因为在并发模式之间没有选择。
Transact-SQL TRY/CATCH 逻辑处理冲突错误，但不会处理 TempDB 的空间问题。	PL/SQL 具有错误处理，它支持 ORA-08177（冲突）错误处理，但不能处理 ORA-01555（回滚部分空间问题）。

理解并发控制

就像在使用情境中看到的，在控制并发时主要使用两种模型：悲观并发和乐观并发。在基于悲观并发控制的系统下，锁定被用于阻止用户以影响其他用户的方式修改数据。一旦应用了锁定，其他用户就不能执行可能与锁定冲突的操作，直到所有者释放锁定。这种级别的控制通常用于存在较多数据争用的环境，以及如果/当并发突出产生时使用锁定来保护数据的成本小于回滚事务的成本的环境中。相反，在基于乐观并发控制的系统中，用户在读取数据时并不锁定数据。在执行更新时，系统会检查是否有另一个用户在数据被读取后更改了数据。如果另一个用户更改了数据，就会产生一个错误。通常，用户收到错误后会回滚事务，重新提交（应用程序/环境相关）和/或启动。这被称为乐观并发，因为它主要用于低数据争用的环境中，以及读取时偶然回滚事务的成本超过锁定数据的成本的环境中（请注意，在 Read Committed 下执行的更新和 Snapshot Isolation 下执行的更新不会冲突，因此不会导致回滚成本）。

在 SQL Server 2005 之前，事务是以悲观方式控制的，这意味着所有事务都获得锁定。尽管锁定是多数应用程序的最佳并发控制选择，但是它也会导致编写器阻止读取器。如果某个事务更改了某一行，那么在编写器提交之前另一个事务就不能读取该行。在一些情况下，等待更改完成是正确的响应；但在另一些情况下，以前的行事务一致性状态就足够了。

基于快照的隔离级别使得读取器能够取得先前提交的行值，代价是在修改行时必须保留此版本——即使“当前”没有人正在访问数据也是一样。这意味着所有选择、更新和删除（但不插入）语句可能都要付出版本控制的代价（进出版本存储的额外的 I/O）。您必须作出决定，使得这一交换可以在开销和性能的代价下获得更好的并发。要说明的很重要的一点是，尽管可能需要花费更多代价来执行每次查询（因为版本控制），但是最终的结果可能是您可以支持更多的吞吐量（因为争用降低了）。它可以应用在争用消耗吞吐量的环境中，这很重要；如果您使用这种技术作为不是由争用引起的性能问题的解决方案，那么您可能就是在解决错误的问题，并且实际上，会降低您的系统吞吐量。

一般说来，当数据库通过基于版本控制的隔离自动控制您的数据视图时，应用程序编程会比价容易。在这种环境中，您较少担心死锁和阻止，而是在管理性管理开销和性能上额外付出了一点代价。在很多情况下，对于 TempDB 来说可能更容易选择在管理性开销和提供更多磁盘吞吐量上付出代价。如果所有基于查询的快照都只能提供读取一致性，而不能提供后续修改的基础；那么就不需要任何应用程序重试逻辑。但是，您最终可能会在使用快照隔离级别并且后来执行了更新的事务中遇到冲突；如果版本是“陈旧的”，那么您可能需要使用重试逻辑进行更新。