https://docs.microsoft.com/zh-cn/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver15 2/73
所处的状态,要么是另一并发事务修改它之前的状态,要么是第二个事务修改它之后的
状态,事务不会识别中间状态的数据。 这称为可串行性,因为它能够重新装载起始数
据,并且重播一系列事务,以使数据结束时的状态与原始事务执行的状态相同。
持续性
完成完全持久的事务之后,它的影响将永久存在于系统中。 该修改即使出现系统故障也
将一直保持。 SQL Server 2014 (12.x) 和更高版本将启用延迟的持久事务。 提交延迟的持
久事务后,该事务日志记录将保留在磁盘上。 有关延迟事务持续性的详细信息,请参阅
主题事务持续性。
SQL 程序员要负责启动和结束事务,同时强制保持数据的逻辑一致性。 程序员必须定义
数据修改的顺序,使数据相对于其组织的业务规则保持一致。 程序员将这些修改语句包
括到一个事务中,使 SQL Server 数据库引擎 能够强制该事务的物理完整性。
企业数据库系统(如SQL Server 数据库引擎实例)有责任提供一种机制,保证每个事务
的物理完整性。 SQL Server 数据库引擎提供:
锁定设备,使事务保持隔离。
通过记录设备,保证事务持久性。 对于完全持久的事务,在其提交之前,日志记录
将强制写入磁盘。 因此,即使服务器硬件、操作系统或 SQL Server 数据库引擎 实
例自身出现故障,该实例也可以在重新启动时使用事务日志,将所有未完成的事务
自动地回滚到系统出现故障的点。 提交延迟的持久事务后,该事务日志记录将强制
写入磁盘。 如果在日志记录强制写入磁盘前系统出现故障,此类事务可能会丢失。
有关延迟事务持续性的详细信息,请参阅主题事务持续性。
事务管理特性,强制保持事务的原子性和一致性。 事务启动之后,就必须成功完成
(提交),否则SQL Server 数据库引擎实例将撤消该事务启动之后对数据所做的所
有修改。 此操作称为回滚事务,因为它将数据恢复到那些更改发生前的状态。
控制事务
应用程序主要通过指定事务启动和结束的时间来控制事务。 可以使用 Transact-SQL 语句
或数据库应用程序编程接口 (API) 函数来指定这些时间。 系统还必须能够正确处理那些
在事务完成之前便终止事务的错误。 有关详细信息,请参阅事务、ODBC 中的事务以及
SQL Server Native Client (OLEDB) 中的事务。
默认情况下,事务按连接级别进行管理。 在一个连接上启动一个事务后,该事务结束之
前,在该连接上执行的所有 Transact-SQL 语句都是该事务的一部分。 但是,在多个活动
的结果集 (MARS) 会话中,Transact-SQL 显式或隐式事务将变成批范围的事务,这种事
务按批处理级别进行管理。 当批处理完成时,如果批范围的事务还没有提交或回滚,
SQL Server 将自动回滚该事务。 有关详细信息,请参阅使用多重活动结果集 (MARS)。
启动事务
评论