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