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