SQL Server 2014之后事務分為2種：完全持久，默認或延遲的持久。

完全持久，當事務被提交之后，會把事務日志寫入到磁盤，完成后返回給客戶端。

延遲持久，事務提交是異步的，在事務寫入到磁盤前，事務提交返回給客戶端。

以前都是完全持久，現在多了個延遲持久，延遲持久只有當日志緩存刷新的時候才會被寫入到磁盤保證事務完整性。

目錄

控制事務持久性... 1

完全持久事務和延遲持久事務持久性... 1

完全持久事務... 1

延遲持久性事務... 1

如何控制事務的持久性... 2

數據庫級別... 2

存儲過程級別... 2

語句級別... 2

如何強制日志刷新... 2

延遲持續性和其他 SQL Server 功能... 3

說白了，完成持久事務完全保證事務的持久性，延遲持久事務延遲保證事務的持久性。

只要存在以下情況，就應使用完全持久事務：

1.系統無法承受任何數據丟失

2.造成性能瓶頸的原因不是事務日志寫入延遲

完全持久事務保證：

1.事務提交后，修改對其他事務時可見的。

2.完全保證事務的持久性

延遲持久性事務，通過異步的把事務日志寫入到磁盤來實現，在寫入到磁盤之前，日志被保存在緩存區中，當緩沖區滿了或者刷新緩沖區了把日志寫入磁盤，依次來減少磁盤資源爭用：

1.事務提交不用等待寫入到磁盤完成

2.減少磁盤爭用從而提高，事務吞吐量。

使用場景：

1.可以忍受一定數據的丟失

2.在事務日志寫入的時候發現瓶頸

3.磁盤資源爭用率很高

延遲持久事務保證：

1.提交后，修改對其他事務可見

2.持久性只能靠緩存刷新來保證：

事務日志緩存在以下情況下刷新：

a.當同一個數據庫的完全持久性事務提交，并成功

b.成功執行存儲過程sp_flush_log

c.緩存區滿了，自動刷新

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

DISABLE:默認設置，不管如何保持完全持久性

ALLOWD:允許延遲持久性執行，要看存儲過程，或者TSQL級別的設置

FORCED:強制所有的事務都是延遲持久性的

DELAYED_DURABILITY = { OFF | ON }

OFF:默認設置，不使用延遲持久事務

ON:啟動延遲持久事務

CREATE PROCEDURE <procedureName> …

WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER

AS BEGIN ATOMIC WITH

(

DELAYED_DURABILITY = ON,

TRANSACTION ISOLATION LEVEL = SNAPSHOT,

LANGUAGE = N'English'

…

)

END

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

OFF:默認設置，不使用延遲持久事務

ON:啟動延遲持久事務

1.提交完全持久性事務

2.使用系統存儲過程sp_flush_log

更改跟蹤和變更數據捕獲

具有更改跟蹤屬性的所有事務都是完全持久事務。如果一個事務的所有寫入操作都對表進行，而這些表支持更改跟蹤或變更數據捕獲 (CDC)，則該事務具有更改跟蹤屬性。

崩潰恢復

一致性可得到保證，但已提交的延遲持久事務的一些更改可能會丟失。

跨數據庫和 DTC

如果事務跨數據庫或是分布式事務，則無論數據庫或事務提交設置如何，它都是完全持久事務。

AlwaysOn 可用性組和鏡像

延遲持久事務并不能保證主數據庫或任何輔助數據庫的持續性。此外，它們也不保證了解輔助數據庫的事務。提交后，在從同步輔助數據接收到 ACK 之前，控制權就會歸還客戶端。

故障轉移群集

某些延遲持久事務寫入可能會丟失。

事務復制

延遲持久事務并不保證其復制。只有在事務成為持久事務后才會得到復制。

日志傳送

傳送的日志中僅包含已成為持久事務的事務。

日志備份

備份中僅包含已成為持久事務的事務。