SQLServer 延迟事务持久性

SQL Server 2014新功能 -- 延迟事务持久性（Delayed Transaction Durability）

SQL Server事务提交默认是完全持久性的（Full Durable），从SQL Server 2014开始，增加了新的功能延迟事务持久性，使得事务提交可设置为延时持久性的（Delayed Durable，也叫做（Lazy Commit））。

• 完全事务持久性（Full Transaction Durability）

在SQL Server 2014之前， SQL Server提交事务是一个同步的过程，也就是说，只有当SQL Server将该事务相对应的日志记录写入到了磁盘文件之后，才会返回事务提交成功的信号。这也是为了体现事务4个基本特性中的持久性而实现的功能。只有 这样，我们才能保证当SQL Server因为某些原因突然Crash之后，再重启的时候，那些已经提交但还没有写入到数据文件上的记录可以通过日志文件进行恢复，或者那些还没有提 交，但已经有部分数据写入到数据文件上的记录进行回滚。所以，我们可以看到，对于传统的事务提交，由于必须要保证日志写入到磁盘上，这个I/O操作就有可 能成为性能的瓶颈。

• 应用场景

完全持久事务在将控制权归还给客户端之前把事务日志强制写入磁盘。 只要存在以下情况，就应使用完全持久事务：

1.系统无法承受任何数据丢失。

2.造成瓶颈的原因不是事务日志写入延迟。

通过在内存中保留事务日志记录并批量写入事务日志，延迟事务持续性可以缩短延迟，因而减少了所需的 I/O 操作。 延迟事务持续性可能会减少日志 I/O 争用，从而减少系统中的等待。

• 延迟事务持久性（Delayed Transaction Durability）

这个技术可以使得SQL Server在提交事务时，无需等待事务日志写入磁盘就直接返回事务提交成功的信号，I/O操作在后台会以异步的方式写入到数据库事务日志文件中。这样好 处是，事务可以去除等待I/O操作完成所带来的延时，以此来提高整个SQL Server的性能。在这整个过程中，SQL Server会在内存中专门开辟出一个特殊的Log Buffer来存放DTD所产生的日志，当这个Log Buffer一旦存满之后会马上写入日志文件，由此将零散的I/O操作变成了一块一块的操作来提高效率，增加吞吐量。

• 应用场景

适合使用延迟事务持续性的部分情况如下：

1.可以容忍一定的数据丢失。

    如果可以容忍一定的数据丢失，例如只要有大部分数据即可，个别记录不是非常重要，就值得考虑延迟持续性。 如果无法容忍任何数据丢失，则不要使用延迟事务持续性。

2.在事务日志写入时遭遇瓶颈。

    如果性能问题是由于事务日志写入延迟造成的，则应用程序可能适合使用延迟事务持续性。

3.工作负载有很高的争用率。

    如果系统工作负载争用级别很高，则会花费大量时间等待锁释放。 延迟事务持续性会缩短提交时间，因此能够更快地释放锁，从而实现更大的吞吐量。

• 控制事务持久性

持久性可以在数据库级别（Database Level）、提交级别（COMMIT Level）或原子块级别（ATOMIC Block Level）进行控制。

1. 数据库级别控制
   您作为 DBA，可以控制用户是否可通过以下语句对数据库使用延迟事务持续性。 您必须使用 ALTER DATABASE 来设置延迟持续性设置。

   ALTER DATABASE … SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }

   DISABLE:默认设置，不管如何保持完全持久性

   ALLOWD:允许延迟持久性执行，要看存储过程，或者TSQL级别的设置

   FORCED:强制所有的事务都是延迟持久性的

2. 原子块级别控制 - 本机编译的存储过程

          下面的代码面向原子块内部。

         

DELAYED_DURABILITY = { OFF | ON }

　　 3. 提交级别控制 – T-SQL

　　COMMIT 语法已扩展，您可以强制实施延迟事务持续性。 如果 DELAYED_DURABILITY 在数据库级别设置为 DISABLED 或 FORCED，则忽略此 COMMIT 选项。

　　

COMMIT [ { TRAN | TRANSACTION } ] [ transaction_name | @tran_name_variable ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ]

OFF:默认设置，不使用延迟持久事务

ON:启动延迟持久事务

• 如何强制执行事务日志刷新

　　有两种方法可以强制将事务日志刷新到磁盘。

1.执行任何可改变相应数据库的完全持久事务。 这会强制将之前提交的所有延迟持续性事务的日志记录刷新到磁盘。

2.执行系统存储过程 sp_flush_log。 此过程会强制将之前提交的所有延迟持久事务的日志记录刷新到磁盘。

 

• 其他相关功能与延迟持久性的关系和影响

更改跟踪和变更数据捕获
具有更改跟踪属性的所有事务都是完全持久事务。 如果一个事务的所有写入操作都对表进行，而这些表支持更改跟踪或变更数据捕获 (CDC)，则该事务具有更改跟踪属性。

崩溃恢复
一致性可得到保证，但已提交的延迟持久事务的一些更改可能会丢失。

跨数据库和 DTC
如果事务跨数据库或是分布式事务，则无论数据库或事务提交设置如何，它都是完全持久事务。

AlwaysOn 可用性组和镜像
延迟持久事务并不能保证主数据库或任何辅助数据库的持续性。 此外，它们也不保证了解辅助数据库的事务。 提交后，在从同步辅助数据接收到任何确认之前，控制权就会归还客户端。

故障转移群集
某些延迟持久事务写入可能会丢失。

事务复制
延迟持久事务并不保证其复制。 只有在事务成为持久事务后才会得到复制。

日志传送
传送的日志中仅包含已成为持久事务的事务。

日志备份
备份中仅包含已成为持久事务的事务。

在什么情况下会丢失数据？

如果你对表实施延迟持续性，则应了解某些情况会导致数据丢失。 如果无法容忍任何数据丢失，则不要对表使用延迟持续性。

灾难性事件

发生灾难性事件（如服务器崩溃）时，将丢失已提交但未保存到磁盘的所有事务的数据。 根据数据库中的任何表（持久内存优化或基于磁盘）执行完全持久的事务时，或调用 sp_flush_log 时，延迟的持久事务保存到磁盘。 如果你在使用延迟的持久事务，那么你可能想要在数据库中创建一个小型表，你可定期更新该表或调用 sp_flush_log，以保存所有未完成的已提交事务。 事务日志还会在变满时刷新，但这难以预测，也无法进行控制。

SQL Server 关闭和重新启动

对 于延迟的持久性，SQL Server 的意外关闭和预期关闭/重新启动没有区别。 与灾难性事件类似，应制定针对数据丢失的计划。 在进行计划的关闭/重新启动时，一些尚未写入磁盘的事务可能会首先保存到磁盘，但不应对其进行计划。 虽然计划了关闭/重启，但无论是否计划，都会像灾难性事件一样丢失数据。

参考：https://msdn.microsoft.com/zh-cn/library/dn449490%28v=sql.120%29.aspx