SQL 2014新功能介绍系列4 - 延迟事务持续性(Delayed Durability Transactions)

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

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

       虽然，DTD能提高系统的性能，但是，可以看到，它的缺点也是显而易见的。由于数据是以内存为载体，如果SQL Server crash，那部分还没有来得及写入到磁盘的日志数据就会丢失。导致之前提交的记录在数据库重启之后消失。这样，会使得前端应用（用户）产生不好的体验。同时，这个也从违反了ACID中的Durability这个特性。因此，我们需要根据业务的实际需要来确定是否启用该功能。通常，我们建议在以下几种情况下来使用这个功能：

1. 可以容忍部分的数据丢失
2. 系统中存在极为严重的Log Write等待

     在SQL Server 2014中，我们有3种方式来控制什么时候使用DTD：

1. Database level control——数据库级别来控制所有的事务是否需要启用DTD
2. Atomic block level control——Native SP级别来控制是否需要启用DTD
3. COMMIT level control ——T-SQL级别来控制是否需要启用DTD

      当三种级别混合使用的时候，会有不同的结果：

       最后，我们再来介绍一下“sp_flush_log”，该存储过程是SQL Server 2014引入的一个新的系统存储过程。它的作用是将当前数据库的事务日志刷新到磁盘上，可以保证所有之前提交的DTD事务都是持久的，以此确保数据不会丢失。由于，从内存的Buffer写入到磁盘上的日志文件这个动作都是由SQL Server来自动控制的，所以，如果我们想保证日志最多只丢失多少时间的数据，也可以创建一个Job来定时的执行这个存储过程。这样可以人为来控制这个写入动作。

       这就是今天的分享，更多SQL 2014新功能介绍请持续关注本博客。 下周我们将会介绍SQL 2014 I/O资源调控器这个新特性。