游标并发（数据库引擎）

Microsoft SQL Server 支持四个用于服务器游标的并发选项：

• READ_ONLY

• OPTIMISTIC WITH VALUES

• OPTIMISTIC WITH ROW VERSIONING

• SCROLL LOCKS

• READ_ONLY
  不允许通过游标进行定位更新，并且不持有针对组成结果集的行的锁。

• OPTIMISTIC WITH VALUES
  乐观并发控制是事务控制理论的一个标准部分。如果在打开游标与行被更新的间隔内，只有很短的时间可以让另一个用户或进程更新该行，那么这种情况下就可以使用乐观并发控制。当用此选项打开某个游标时，将不持有针对基础行的锁，这有助于最大化吞吐量。如果用户试图修改某一行，则该行中的当前值将与最后一次提取该行时检索到的值进行比较。如果任何一个值发生了更改，服务器就会知道另一个用户或进程已经更新了该行，并返回一个错误。如果所有值都是一样的，服务器就会执行修改。

  选择此并发选项将强制使用户或程序员承担责任，以处理那些指明另一个用户已对行进行修改的偶然错误。应用程序收到这种错误时通常采取的措施就是刷新游标，获取新值，然后让用户决定是否对新值进行修改。在 SQL Server 6.5 版或早期版本中，text、ntext 和 image 列不用于并发比较。

• OPTIMISTIC WITH ROW VERSIONING
  此乐观并发控制选项基于行版本控制。使用行版本控制，基础表必须具有某种版本标识符，服务器可用该标识符来确定行被读入游标之后是否有所更改。在 SQL Server 中，此性能由 timestamp 数据类型提供，它是一个二进制数字，用于指明数据库中所做的修改的相对顺序。每个数据库都有一个全局当前时间戳值：**@@**DBTS。每次以任意方式修改带有 timestamp 列的行时，SQL Server 都会先将当前的 **@@**DBTS 值存储在 timestamp 列中，然后增加 **@@**DBTS 值。如果某个表具有 timestamp 列，则时间戳会被记到行级。然后，服务器就可以将某一行的当前时间戳值与上次提取该行时存储的时间戳值进行比较，从而确定该行是否已被更新。服务器不必比较所有列中的值，而只需比较 timestamp 列即可。如果应用程序对没有 timestamp 列的表请求基于行版本控制的乐观并发，则游标将默认为基于数值的乐观并发控制。

  注意
  对于通过远程数据源打开的游标，如果远程源不包含 timestamp 列，则不支持通过该游标进行更新。

• SCROLL LOCKS
  此选项用于实现悲观并发控制，在这种控制中，当把基础数据库行读入游标结果集时，应用程序将尝试锁定这些行。使用服务器游标时，将行读入游标时会在该行上放置一个更新锁。如果游标是在某个事务内打开的，则该事务更新锁将一直保持到事务被提交或回滚为止；当提取了下一行后，将删除游标锁。如果游标是在事务外打开的，则当提取了下一行后，就会删除锁。因此，每当用户需要进行完全悲观并发控制时，都应该在事务内打开游标。更新锁将阻止其他任何任务获取更新锁或排他锁，从而阻止其他任何任务更新该行。但更新锁并不阻止共享锁，因此它不会阻止其他任务读取该行，除非第二个任务也在请求带有更新锁的读取。