SQLServer 2014 控制事务持续性

2023-02-21 00:00:00 事务 磁盘 提交 日志 延迟

在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 的意外关闭和预期关闭/重新启动没有区别。

      相关文章