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）進行控制。
-
數據庫級別控制
您作為 DBA，可以控制用戶是否可通過以下語句對數據庫使用延遲事務持續性。 您必須使用 ALTER DATABASE 來設置延遲持續性設置。ALTER DATABASE … SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }DISABLE:默認設置，不管如何保持完全持久性
ALLOWD:允許延遲持久性執行，要看存儲過程，或者TSQL級別的設置
FORCED:強制所有的事務都是延遲持久性的
-
原子塊級別控制 - 本機編譯的存儲過程
下面的代碼面向原子塊內部。
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