在SQL Server 2014之前， SQL Server提交事务是一个同步的过程，也就是说，只有当SQL Server将该事务相对应的日志记录写入到了磁盘文件之后，才会返回事务提交成功的信号。延迟持久事务提交是异步的，无需等待事务日志写入磁盘就直接返回事务提交成功的信号，I/O操作在后台会以异步的方式写入到数据库事务日志文件中。
数据丢失不能容忍，只要存在以下情况，就应使用完全持久事务：
系统无法承受任何数据丢失。
造成瓶颈的原因不是事务日志写入延迟
延迟事务持续性可能会减少系统中的延迟和争用，因为：
事务提交处理不会等待日志 IO 完成就将控制权归还给客户端。
并发事务争用日志 IO 的可能性更小；日志缓冲区现在可以更大的区块刷新到磁盘，从而减少争用和提高吞吐量。
适合使用延迟事务持续性的部分情况如下：
可以容忍一定的数据丢失。
在事务日志写入时遭遇瓶颈。
工作负载有很高的争用率。
事务持续性只能通过将内存中事务日志刷新到磁盘来保证。内存中事务日志在以下情况下刷新到磁盘：
同一个数据库中完全持久的事务在数据库中做出更改并成功提交。
用户成功执行系统存储过程 sp_flush_log。
内存中事务日志缓冲区填充并自动刷新到磁盘。
事务的持久性有3个地方设置：
--在数据库级别设置（右键数据库>> 属性>> 选项 >> 延迟持久性）
ALTER DATABASE <Database> SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }
--原子块级别控制 - 本机编译存储流程
DELAYED_DURABILITY = { OFF | ON }
--提交级别控制
COMMIT [ { TRAN | TRANSACTION } ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ]
在数据库级别设置 DELAYED_DURABILITY = { DISABLED | FORCED } 是全局的，完全覆盖 原子块级别 和 提交级别 的设置。
在数据库级别设置 DELAYED_DURABILITY = ALLOWED ，原子块级别 和 提交级别 的持久性由 DELAYED_DURABILITY = { OFF | ON }控制。
-- ALTER DATABASE [DemoDB] SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }
DISABLED ：[默认] 使用此设置时，数据库提交的所有事务都是完全持久事务。
ALLOWED ：使用此设置时，每个事务的持续性都在事务级别确定 DELAYED_DURABILITY = { OFF | ON }。
FORCED ：使用此设置，对数据库提交的每个事务都是延迟持久事务。
-- DELAYED_DURABILITY = { OFF | ON }
OFF ：[默认] 事务是完全持久事务
ON ：事务是延迟持久事务
笔者曾经用此方法优化系统。公司曾有些七八个MSSQL实例使用的是虚拟机，并且有几个中台相关的数据库，访问比较频繁。另一方面，这些系统的磁盘性能本身也不太好。导致的结果就是，SQL Server 错误日志报IO错误（SQL Server has encountered x occurrence(s) of I/O requests taking longer than 15 seconds to complete on file ）。操作系统日志也报磁盘块损坏。而跟踪SQL看到的都是非常简单的语句，无优化空间。临时处理方法就是设置事务延迟提交。
注意：对于高可用，大部分都是读取事务日志的，所以有些延迟事务不包括。如 AlwaysOn 可用性组和镜像 ，故障转移群集，事务复制，日志传送，日志备份。对于延迟的持久性，SQL Server 的意外关闭和预期关闭/重新启动没有区别。
