sql server 2014新功能 -- 延遲事務永續性（delayed transaction durability）
sql server事務提交預設是完全永續性的（full durable），從sql server 2014開始，增加了新的功能延遲事務永續性，使得事務提交可設定為延時永續性的（delayed durable，也叫做（lazy commit））。
在sql server 2014之前， sql server提交事務是乙個同步的過程，也就是說，只有當sql server將該事務相對應的日誌記錄寫入到了磁碟檔案之後，才會返回事務提交成功的訊號。這也是為了體現事務4個基本特性中的永續性而實現的功能。只有 這樣，我們才能保證當sql server因為某些原因突然crash之後，再重啟的時候，那些已經提交但還沒有寫入到資料檔案上的記錄可以通過日誌檔案進行恢復，或者那些還沒有提 交，但已經有部分資料寫入到資料檔案上的記錄進行回滾。所以，我們可以看到，對於傳統的事務提交，由於必須要保證日誌寫入到磁碟上，這個i/o操作就有可 能成為效能的瓶頸。
完全持久事務在將控制權歸還給客戶端之前把事務日誌強制寫入磁碟。 只要存在以下情況，就應使用完全持久事務：
1.系統無法承受任何資料丟失。
2.造成瓶頸的原因不是事務日誌寫入延遲。通過在記憶體中保留事務日誌記錄並批量寫入事務日誌，延遲事務持續性可以縮短延遲，因而減少了所需的 i/o 操作。 延遲事務持續性可能會減少日誌 i/o 爭用，從而減少系統中的等待。
這個技術可以使得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 =disable:預設設定，不管如何保持完全永續性
allowd:允許延遲永續性執行，要看儲存過程，或者tsql級別的設定
forced:強制所有的事務都是延遲永續性的
原子塊級別控制 - 本機編譯的儲存過程
下面的**面向原子塊內部。
delayed_durability =3. 提交級別控制 – t-sql
commit 語法已擴充套件，您可以強制實施延遲事務持續性。 如果 delayed_durability 在資料庫級別設定為 disabled 或 forced，則忽略此 commit 選項。
commit [ ] [ transaction_name | @tran_name_variable ] ] [ with ( delayed_durability = ) ]off:預設設定，不使用延遲持久事務on:啟動延遲持久事務
有兩種方法可以強制將事務日誌重新整理到磁碟。
1.執行任何可改變相應資料庫的完全持久事務。 這會強制將之前提交的所有延遲持續性事務的日誌記錄重新整理到磁碟。
2.執行系統儲存過程 sp_flush_log。 此過程會強制將之前提交的所有延遲持久事務的日誌記錄重新整理到磁碟。
更改跟蹤和變更資料捕獲
具有更改跟蹤屬性的所有事務都是完全持久事務。 如果乙個事務的所有寫入操作都對錶進行，而這些表支援更改跟蹤或變更資料捕獲 (cdc)，則該事務具有更改跟蹤屬性。
崩潰恢復
一致性可得到保證，但已提交的延遲持久事務的一些更改可能會丟失。
跨資料庫和 dtc
如果事務跨資料庫或是分布式事務，則無論資料庫或事務提交設定如何，它都是完全持久事務。
alwayson 可用性組和映象
延遲持久事務並不能保證主資料庫或任何輔助資料庫的持續性。 此外，它們也不保證了解輔助資料庫的事務。 提交後，在從同步輔助資料接收到任何確認之前，控制權就會歸還客戶端。
故障轉移群集
某些延遲持久事務寫入可能會丟失。
事務複製
延遲持久事務並不保證其複製。 只有在事務成為持久事務後才會得到複製。
日誌傳送
傳送的日誌中僅包含已成為持久事務的事務。
日誌備份
備份中僅包含已成為持久事務的事務。
在什麼情況下會丟失資料？
如果你對錶實施延遲持續性，則應了解某些情況會導致資料丟失。 如果無法容忍任何資料丟失，則不要對錶使用延遲持續性。
發生災難性事件（如伺服器崩潰）時，將丟失已提交但未儲存到磁碟的所有事務的資料。 根據資料庫中的任何表（持久記憶體優化或基於磁碟）執行完全持久的事務時，或呼叫 sp_flush_log 時，延遲的持久事務儲存到磁碟。 如果你在使用延遲的持久事務，那麼你可能想要在資料庫中建立乙個小型表，你可定期更新該錶或呼叫 sp_flush_log，以儲存所有未完成的已提交事務。 事務日誌還會在變滿時重新整理，但這難以**，也無法進行控制。
對 於延遲的永續性，sql server 的意外關閉和預期關閉/重新啟動沒有區別。 與災難性事件類似，應制定針對資料丟失的計畫。 在進行計畫的關閉/重新啟動時，一些尚未寫入磁碟的事務可能會首先儲存到磁碟，但不應對其進行計畫。 雖然計畫了關閉/重啟，但無論是否計畫，都會像災難性事件一樣丟失資料。
SQLServer 延遲事務永續性
sql server 2014新功能 延遲事務永續性 delayed transaction durability sql server事務提交預設是完全永續性的 full durable 從sql server 2014開始，增加了新的功能延遲事務永續性，使得事務提交可設定為延時永續性的 dela...
Redis 事務 持久化
redis對事務的支援比較簡單，或者說它的事務是有缺陷的。它只能保證乙個client發起的事務中的命令可以連續執行，中間不會插入其它client端的命令。缺陷在於，如果乙個client將兩條命令放到乙個事務了，執行的時候第二條命令傳送錯誤，但此時redis的事務不會回滾第一條命令。如下圖 redis...
SQL Server游標 延遲執行簡介
在專案測試中，我們可能會使用批量生成資料來測試程式的效能。這裡講乙個我遇到的問題，由於我們批量生成資料時基本上是瞬間完成，所以getdate 函式獲得的時間基本上也是一樣的，而我們又要求生成每條資料的時間不同，那麼如何來解決這個問題？網上搜尋了很多，這裡我是使用游標 waitfor來處理的 首先來講...