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