In-Memory：內(nèi)存優(yōu)化表的事務(wù)處理

1、In-Memory：內(nèi)存優(yōu)化表的事務(wù)處理內(nèi)存優(yōu)化表（Memory-Optimized Table，簡稱MOT）使用樂觀策略（optimistic approach）實現(xiàn)事務(wù)的并發(fā)控制，在讀取MOT時，使用多行版本化（Multi-Row versioning）創(chuàng)建數(shù)據(jù)快照，讀操作不會對數(shù)據(jù)加鎖，因此，讀寫操作不會相互阻塞。寫操作會申請行級鎖，如果兩個事務(wù)嘗試更新同一數(shù)據(jù)行，SQL Server檢測到寫-寫沖突，產(chǎn)生錯誤（Error 41302），將后后創(chuàng)建的事務(wù)作為失敗者，回滾事務(wù)的操作。雖然MOT事務(wù)使用無鎖結(jié)構(gòu)（Lock-Free），不會產(chǎn)生阻塞，但是，訪問MOT仍然會產(chǎn)生Wait，通常情況

2、下，等待時間是非常短暫的。一，MOT使用樂觀并發(fā)事務(wù)控制1，并發(fā)控制策略事務(wù)的并發(fā)控制策略分為樂觀策略和悲觀策略，SQL Server支持兩種并發(fā)策略。1.1，悲觀策略（Pessimistic Approach）悲觀策略認(rèn)為每一個數(shù)據(jù)更新都潛在地存在沖突，為了避免數(shù)據(jù)爭用，事務(wù)在讀取數(shù)據(jù)時申請共享鎖，在更新數(shù)據(jù)時對數(shù)據(jù)加互斥鎖（Locking）。在沖突發(fā)生時，通過加鎖阻塞其他事務(wù)；其他事務(wù)檢測到?jīng)_突后，等待擁有資源的事務(wù)釋放互斥鎖，其他事務(wù)只有獲取到資源上的加鎖，才能執(zhí)行讀寫操作。悲觀策略主要用于數(shù)據(jù)爭用激烈，并且發(fā)生發(fā)沖突時用鎖保護(hù)數(shù)據(jù)的成本低于回滾事務(wù)的成本的環(huán)境中。1.2，樂觀策略（Op

3、timistic Approach）樂觀策略認(rèn)為執(zhí)行的數(shù)據(jù)更新操作很少存在沖突，事務(wù)在讀取數(shù)據(jù)時，不鎖定數(shù)據(jù)；在更新數(shù)據(jù)時，事務(wù)只在提交時檢查更新的有效性，如果有其他事務(wù)更新該數(shù)據(jù)，將產(chǎn)生更新沖突的錯誤，那么事務(wù)不等待，SQL Server選擇一個事務(wù)作為失敗者，并回滾事務(wù)執(zhí)行的操作。樂觀策略效率更高，部分原因是在大多數(shù)情況下，更新沖突不經(jīng)常發(fā)生。當(dāng)沖突發(fā)生時，使用悲觀策略，事務(wù)需要等待；使用樂觀策略，SQL Server使事務(wù)失敗，回滾事務(wù)操作。樂觀策略主要用于數(shù)據(jù)爭用不大，并且偶爾回滾事務(wù)的成本低于讀取數(shù)據(jù)時鎖定數(shù)據(jù)的成本的環(huán)境中。樂觀估計效率更高，部分原因是在大多數(shù)情況下，事務(wù)沖突不經(jīng)常

4、發(fā)生。當(dāng)沖突發(fā)生時，使用悲觀估計法，事務(wù)需要等待；使用樂觀估計法，SQL Server使事務(wù)失敗，并回滾事務(wù)操作，因此，在發(fā)生更新沖突時，需要在客戶端進(jìn)行異常檢測，重新執(zhí)行事務(wù)。2，MOT使用樂觀并發(fā)控制（Optimistic Concurrency Control，簡稱OCC）樂觀策略使用行版本化（row versioning）實現(xiàn)并發(fā)控制，對于disk-based table，使用tempdb存儲行版本數(shù)據(jù)；對于MOT，在內(nèi)存中存儲行版本數(shù)據(jù)。樂觀策略認(rèn)為沖突和失敗是不常見的，OCC認(rèn)為訪問MOT的事務(wù)不會和其他并發(fā)執(zhí)行的事務(wù)產(chǎn)生沖突，任何操作都會執(zhí)行成功。在訪問MOT時，事務(wù)不會加鎖（L

5、ock或Latch）以保證讀操作的隔離性，因此，讀寫操作互不阻塞，也不會產(chǎn)生等待。一旦產(chǎn)生寫-寫沖突，SQL Server將選擇創(chuàng)建時間晚的事務(wù)作為失敗者，并回滾該事務(wù)操作。二，MOT支持的事務(wù)隔離級別（Transaction Isolation Level）在In-Memory OLTP系統(tǒng)中，存在兩種事務(wù)隔離級別，訪問硬盤表（Disk-Based Table，簡稱DBT）的事務(wù)，和訪問MOT的事務(wù)；和傳統(tǒng)的事務(wù)隔離級別不同，在一個事務(wù)中，存在兩個隔離級別。1，MOT的SNAPSHOT隔離級別實際上，訪問MOT，事務(wù)必須處在SNAPSHOT隔離級別下，SNAPSHOT隔離級別指定在讀操作執(zhí)行

6、時，數(shù)據(jù)在事務(wù)級別保持一致性，這意味著，在一個事務(wù)中的任何讀操作，讀取的數(shù)據(jù)是事務(wù)一致性的數(shù)據(jù)版本。事務(wù)一致性是指在事務(wù)開始時，創(chuàng)建數(shù)據(jù)快照：在事務(wù)開始時，已經(jīng)提交的事務(wù)更新，能夠被該事務(wù)識別；在事務(wù)開始之后，被其他事務(wù)提交的數(shù)據(jù)更新操作，不會被當(dāng)前事務(wù)識別。This isolation level specifies that data read by any statement in a transaction will be the transactionally consistent version of the data that existed at the start of th

7、e transaction. The transaction can only recognize data modifications that were committed before the start of the transaction. Data modifications made by other transactions after the start of the current transaction are not visible to statements executing in the current transaction. The statements in

8、 a transaction get a snapshot of the committed data as it existed at the start of the transaction.在SQL Server 2016中，有兩種方式指定隔離級別：當(dāng)在解釋性TSQL中訪問MOT時，使用Table Hint指定SNAPSHOT隔離級別；當(dāng)在Natively Compiled 存儲過程中訪問MOT時，必須在Atomic Block中指定隔離級別為SNAPSHOT。SNAPSHOT隔離級別只會影響讀操作，而寫操作不受隔離級別的影響，和其他事務(wù)完全隔離，因此，在Snapshot隔離級別下，當(dāng)并

9、發(fā)事務(wù)嘗試去更新同一行數(shù)據(jù)時，并發(fā)事務(wù)產(chǎn)生更新沖突，拋出錯誤 41302，41325，或41305，SQL Server選擇一個開始時間晚的事務(wù)作為失敗者，并回滾其操作，產(chǎn)生的Error是：Error 41302. The current transaction attempted to update a record in table X that has been updated since this transaction started. The transaction was aborted. When the current transaction attempts to inse

10、rt a row with the same primary key value as a row that was inserted by another transaction that committed before the current transaction, there will be a failure to commit with the following error message.Error 41325. The current transaction failed to commit due to a serializable validation failure.

11、 If a transaction writes to a table that is dropped before the transaction commits, the transaction terminates with the following error message:Error 41305. The current transaction failed to commit due to a repeatable read validation failure.2，提升事務(wù)的隔離級別在顯式事務(wù)（Explicit）模式中，如果默認(rèn)的事務(wù)隔離級別低于SNAPSHOT，那么必須提升

12、事務(wù)隔離級別，才能訪問MOT，有兩種實現(xiàn)方式： 設(shè)置數(shù)據(jù)庫選項 MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 為ON，該選項的作用是：當(dāng)事務(wù)隔離級別比SNAPSHOT低時（比如，READ COMMITTED or READ UNCOMMITTED），訪問MOT的事務(wù)都會自動升級到SNAPSHOT隔離級別：ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON 為MOT使用Table Hint：with(snapshot)因此，在顯式事務(wù)中，通過解釋性（Interpreted）TSQL訪問M

13、OT時，必須：使用Table Hint指定隔離級別：WITH(SNAPSHOT)，WITH(REPEATABLEREAD) 和 WITH(SERIALIZABLE) 設(shè)置數(shù)據(jù)庫選項：MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 為ON如果發(fā)生MSSQLSERVER_41333 錯誤，說明產(chǎn)生交叉事務(wù)隔離錯誤（CROSS_CONTAINER_ISOLATION_FAILURE），原因是當(dāng)前事務(wù)的隔離級別太高，解決方法是：將Session-Level的事務(wù)隔離級別降低到Read Committed。3，事務(wù)初始化模式（Transaction Initiation Mod

14、es）SQL Server 支持四種事務(wù)初始化模式：Autocommit：自動提交模式（默認(rèn)模式），將單個語句作為一個事務(wù)，在語句開始時，隱式開始一個事務(wù)；在語句結(jié)束時，隱式提交該事務(wù)；在autocommit模式下，訪問MOT不需要使用Table Hint指定事務(wù)隔離級別；SQL Server自動為MOT應(yīng)用SNAPSHOT隔離。Explicit：顯式模式，使用begin tran 顯式開始一個事務(wù)，使用commit tran 提交事務(wù)，或使用rollback tran 回滾事務(wù)。在顯式事務(wù)中，將事務(wù)中的一個，或多個查詢語句作為單個事務(wù)進(jìn)行處理；在顯式模式下，訪問MOT必須使用SNAPSHOT

15、隔離級別，通過使用Table Hint 指定SNAPSHOT 隔離級別，或設(shè)置數(shù)據(jù)庫選項 MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 為ON來實現(xiàn)；Implicit：隱式模式，查詢語句隱式開始一個事務(wù)，必須顯式使用commit tran 提交事務(wù)，或使用rollback tran回滾事務(wù)。使用該模式，必須設(shè)置選項：SET IMPLICIT_TRANSACTION ONAtomic block：原子塊模式，只能用于Natively Compiled SP中。在Atomic block中的所有查詢語句都作為單個事務(wù)提交或回滾。在Atomic block中，支持的事務(wù)隔

16、離級別是：TRANSACTION ISOLATION LEVEL = SNAPSHOT | REPEATABLE READ | SERIALIZABLE 在Natively Compiled SP中，使用BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, .) 定義Atomic block事務(wù)： View Code三，訪問MOT的事務(wù)隔離級別在訪問MOT時，最方便的做法是：使用默認(rèn)的隔離級別 Read Committed，并且設(shè)置數(shù)據(jù)庫選項：MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 為ON。1,

17、如果設(shè)置Session的隔離級別為Read Uncommitted，事務(wù)訪問MOT，將產(chǎn)生錯誤，MOT不支持Read Uncommitted隔離級別The transaction isolation level 'READ UNCOMMITTED' is not supported with memory optimized tables.2，如果設(shè)置Session的隔離級別為Read Committed：在Autocommit （單語句事務(wù)）模式下，能夠訪問MOT；在顯式和隱式模式下，不能訪問MOT；在顯式事務(wù)中，訪問MOT，將產(chǎn)生錯誤：Accessing memory op

18、timized tables using the READ COMMITTED isolation level is supported only for autocommit transactions. It is not supported for explicit or implicit transactions. Provide a supported isolation level for the memory optimized table using a table hint, such as WITH (SNAPSHOT).要想在顯式事務(wù)或隱式事務(wù)模式下訪問MOT，有兩種方式：

19、使用Table Hint：with(snapshot)，該hint只能用于MOT；WITH(REPEATABLEREAD) 和 WITH(SERIALIZABLE) ；設(shè)置數(shù)據(jù)庫選項：MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT 為ON；ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON3，如果設(shè)置Session的隔離級別為Snapshot，無法訪問MOTalter database current set allow_snapshot_isolation onset transact

20、ion isolation level snapshot訪問MOT，將產(chǎn)生錯誤，MOT 和 Natively Compiled模塊在Session的事務(wù)隔離為Snapshot時無法訪問或創(chuàng)建：Memory optimized tables and natively compiled modules cannot be accessed or created when the session TRANSACTION ISOLATION LEVEL is set to SNAPSHOT.4，如果設(shè)置Session的隔離級別為Repeatable Read or Serializable時，訪問MO

21、T必須使用snapshot隔離級別；如果Session的隔離級別是Repeatable Read 或 Serializable，那么訪問MOT必須使用Table Hint：with(snapshot)，在snapshot隔離級別下訪問MOT：The following transactions must access memory optimized tables and natively compiled modules under snapshot isolation: RepeatableRead transactions, Serializable transactions, and

22、transactions that access tables that are not memory optimized in RepeatableRead or Serializable isolation.綜上所述，訪問MOT時，需要設(shè)置兼容的事務(wù)隔離級別：四，行版本（Row Version）對硬盤表（Disk-Based Table，簡稱DBT），Snapshot隔離級別將行版本化的數(shù)據(jù)存儲在tempdb中；在其他隔離級別（例如，Read Committed，Repeatable，Serializable）下，事務(wù)通過加鎖避免沖突。對于MOT，事務(wù)不會加鎖，MOT使用多行版本實現(xiàn)事務(wù)的

23、并發(fā)控制，和Disk-Based Table不同的是，MOT的版本化數(shù)據(jù)存儲在MOT的內(nèi)存數(shù)據(jù)結(jié)構(gòu)中，而不是存儲在tempdb中。MOT的每一個數(shù)據(jù)行在內(nèi)存中可能存在多個版本，每一個版本都保存在相同的數(shù)據(jù)結(jié)構(gòu)中。實際上，MOT的數(shù)據(jù)結(jié)構(gòu)是Row Version的集合，相同Row的不同Version不需要存儲在連續(xù)的內(nèi)存地址中，每一個Row Version是分散地存儲在MOT中，每一個Row Version使用8B的內(nèi)存地址來尋址。 The table has three rows: r1, r2, and r3. r1 has three versions, r2 has two versio

24、ns, and r3 has four versions. Note that different versions of the same row do not necessarily occupy consecutive memory locations. The different row versions can be dispersed throughout the table data structure.1，MOT的多版本（Multi-Versioning）MOT的同一行數(shù)據(jù)可以有不同的版本，因此，并發(fā)執(zhí)行事務(wù)可能訪問同一行數(shù)據(jù)的不同版本，由于在同一時刻，任何數(shù)據(jù)行都有可能擁有不

25、同行版本，并且都是有效的；如果根據(jù)數(shù)據(jù)行的不同版本執(zhí)行數(shù)據(jù)更新操作，有可能產(chǎn)生邏輯錯誤。MOT維護(hù)的多行版本（Row-Version）不是存儲在tempdb中，而是直接存儲在MOT中，作為MOT數(shù)據(jù)結(jié)構(gòu)的一部分存儲在內(nèi)存中。2，使用行版本實現(xiàn)Snapshot事務(wù)隔離在單個事務(wù)中，訪問MOT的所有操作，都使用在事務(wù)上一致的快照（Transactionally-Consistent），所謂事務(wù)一致性是指在一個事務(wù)開始時，創(chuàng)建MOT的數(shù)據(jù)快照，在該事務(wù)活躍期間，事務(wù)的所有操作都是基于該數(shù)據(jù)行快照。如果其他事務(wù)修改數(shù)據(jù)，不會影響該事務(wù)讀取的數(shù)據(jù)，例如其他事務(wù)將數(shù)據(jù)由3更新成4，在當(dāng)前事務(wù)中，讀操作讀到

26、的數(shù)據(jù)仍然是3；如果在當(dāng)前事務(wù)中嘗試修改已被其他事務(wù)修改的數(shù)據(jù)，將產(chǎn)生更新沖突。訪問MOT的事務(wù)使用行版本化（row versioning）獲得一個事務(wù)一致性的數(shù)據(jù)快照（snapshot），在單個事務(wù)中，任何數(shù)據(jù)操作讀取的數(shù)據(jù)是：在事務(wù)開始時，其他事務(wù)已經(jīng)提交更新的數(shù)據(jù)版本，能夠被當(dāng)前事務(wù)識別；如果其他事務(wù)沒有提交更新，那么當(dāng)前事務(wù)讀取不到更新之后的數(shù)據(jù)，只能讀取到已經(jīng)存在，事務(wù)已經(jīng)提交更新的數(shù)據(jù)；在事務(wù)開始之后，其他事務(wù)所執(zhí)行的數(shù)據(jù)更新不會被當(dāng)前事務(wù)識別；例如：其他事務(wù)插入的新數(shù)據(jù)不會被當(dāng)前事務(wù)讀取到；其他食物刪除的舊數(shù)據(jù)，當(dāng)前事務(wù)仍然能夠讀取到；五，MOT的事務(wù)處理1，交叉事務(wù)（cross

27、-container transaction）交叉事務(wù)是指在一個事務(wù)中，解釋性TSQL語句同時訪問MOT和DBT。在交叉事務(wù)中，訪問MOT的操作和訪問DBT（Disk-Based Table）的操作都擁有自己獨立的事務(wù)序號，就像在一個大的交叉事務(wù)下，存在兩個單獨的子事務(wù)，分別用于訪問MOT和DBT；在sys.dm_db_xtp_transactions (Transact-SQL)中，訪問DBT的事務(wù)使用transaction_id標(biāo)識，訪問MOT的事務(wù)序號使用xtp_transaction_id標(biāo)識。2，訪問MOT的事務(wù)生命周期當(dāng)事務(wù)涉及到MOT時，處理事務(wù)的生命周期（lifetime）分為

28、三個phase：常規(guī)處理，驗證階段，提交處理，如圖：Phase1：常規(guī)處理階段，事務(wù)所有的查詢和更新操作都在這個階段執(zhí)行：在該階段，有時會產(chǎn)生更新沖突（Update Conflict），如果當(dāng)前事務(wù)更新的數(shù)據(jù)行，被其他事務(wù)更新，但未提交，那么會產(chǎn)生更新沖突；If any query tries to update a row that has already been updated by an active transaction, an update conflict error is generated.在該階段，有時會產(chǎn)提交依賴（Commit Dependence），這是因為事務(wù)讀取到

29、被其他事務(wù)更新，但是尚未提交（處于驗證或提交階段）；依賴失?。―ependency failure）：如果當(dāng)前事務(wù)依賴的事務(wù)提交失敗，那么當(dāng)前事務(wù)失敗，產(chǎn)生錯誤 41301;During regular processing, a transaction can read rows written by other transactions that are in the validation or commit phase, but have not yet committed. The rows are visible because the logical end time of the

30、 transactions has been assigned at the start of the validation phase.Phase2：驗證階段，從該階段開始時，在邏輯上事務(wù)已經(jīng)完成，只是沒有提交，其他事務(wù)能夠看到當(dāng)前事務(wù)更新之后的數(shù)據(jù)值；在驗證階段開始時，事務(wù)的更新操作已經(jīng)完成，認(rèn)為事務(wù)邏輯上完成，這使得事務(wù)更新對其他事務(wù)可見。在該階段，事務(wù)并沒有提交，SQL Server對事務(wù)更新進(jìn)行驗證；The validation phase begins by assigning the end time, thereby marking the transaction as log

31、ically complete. This makes all changes of the transaction visible to other transactions, which will take a dependency on this transaction, and will not be allowed to commit until this transaction has successfully committed. In addition, transactions which hold such dependencies are not allowed to r

32、eturn result sets to the client to ensure the client only sees data that has been successfully itted to the database.在驗證階段，對Repeatable Read 和 Serializable進(jìn)行驗證，檢查數(shù)據(jù)范圍是否有更新。對于Repeatable Read， 檢查行是否是重復(fù)讀的，如果有數(shù)據(jù)行被其他事務(wù)更新，那么事務(wù)提交失敗，拋出錯誤 41305；If any of the rows have been updated or changed, the transaction

33、fails to commit with error 41305 ("The current transaction failed to commit due to a repeatable read validation failure.").對于Serializable，檢查數(shù)據(jù)范圍是有更新，在數(shù)據(jù)范圍中，檢查是否有其他事務(wù)插入新的數(shù)據(jù)行，是否有數(shù)據(jù)行被其他事務(wù)刪除，如果數(shù)據(jù)范圍變化，那么事務(wù)驗證失敗，拋出錯誤 41325；The system validates that no phantom rows have been written to the databas

34、e. The read operations performed by the transaction are evaluated to determine that no new rows were inserted in the scan ranges of these read operations.This phase comprises the repeatable read and serializable validation. For repeatable read validation it checks whether any of the rows read by the

35、 transaction has since been updated. For serializable validation it checks whether any row has been inserted into any data range scanned by this transaction. Phase3：事務(wù)提交處理階段，事務(wù)日志記錄到日志文件，事務(wù)提交完成，一旦日志寫入到Disk，控制權(quán)返回到客戶端During the commit phase, the changes to durable tables are written to the log, and the

36、 log is written to disk. Once the log record for the transaction has been written to disk, control is returned to the client.After commit processing completes, all dependent transactions are notified that they can commit.3，等待（Waiting）訪問MOT使用樂觀多版本并發(fā)控制，不需要加鎖，不會產(chǎn)生阻塞，但是，仍然會產(chǎn)生等待（Waiting），但是，永遠(yuǎn)不可能等待Lock釋放

37、，而是等待：如果一個事務(wù)依賴其他事務(wù)，那么將產(chǎn)生提交依賴，必須等待其他事務(wù)提交成功，當(dāng)前事務(wù)才能提交；等待事務(wù)日志持久化寫入到Disk上的事務(wù)日志文件（.ldf）中；提交依賴等待不能避免，通常持續(xù)的時間非常短暫；在執(zhí)行數(shù)據(jù)更新操作，需要等待事務(wù)日志持久化寫入到Disk，雖然等待持續(xù)的時間通常非常短暫，但是，可以通過以下兩個方式來避免：使用Delayed Durability；創(chuàng)建Non-Durable的MOT，使用SCHEMA_ONLY將完全避免日志寫操作，對非持久化表執(zhí)行的任何更新操作都不會產(chǎn)生任何的日志IO操作；六，沖突檢測和重試邏輯（Conflict Detection and Retr

38、y Logic）1，沖突檢測跟事務(wù)相關(guān)的錯誤有兩類，這兩類錯誤都會導(dǎo)致事務(wù)失敗和回滾。大多數(shù)情況下，任意一個錯誤發(fā)生，都需要重新執(zhí)行事務(wù)：并發(fā)事務(wù)之間產(chǎn)生沖突，分為更新沖突（Update Conflict）和驗證失?。╒alidation Failure）：更新沖突：在同一時刻，有兩個并發(fā)事務(wù)嘗試更新同一數(shù)據(jù)行；錯誤代碼是41302；This error condition occurs if two concurrent transactions attempt to update or delete the same row at the same time. One of the two

39、 transactions receives this error message and will need to be retried. 驗證失?。候炞C事務(wù)更新是否滿足隔離級別Repeatable Read 和 Serializable的條件，檢查數(shù)據(jù)行是否重復(fù)讀，檢查數(shù)據(jù)范圍是否不變；錯誤代碼是41305，41325；依賴失敗：當(dāng)前事務(wù)依賴其他事務(wù)，而依賴的事務(wù)提交失??；錯誤代碼是 41301；2，重試邏輯（Retry Logic）如果事務(wù)失敗是由于上述兩種情況，那么這個事務(wù)應(yīng)該重新執(zhí)行，重試邏輯可以實現(xiàn)在Client或Server端，通常推薦在Client實現(xiàn)重試邏輯，因為在Clien

40、t端執(zhí)行重試邏輯更高效，并能對事務(wù)失敗的異常進(jìn)行復(fù)雜處理。在Server端執(zhí)行重試邏輯，僅用于在事務(wù)失敗時，不向Client返回任何結(jié)果集，重試邏輯的示例代碼如下： View Code七，事務(wù)的懶提交（Lazy Commit）在SQL Server中，事務(wù)提交可以是完全持久化的（Full Durable，默認(rèn)），也可以是延遲持久化的（Delayed Durable），也叫做Lazy Commit。完全持久化（Full Durable）事務(wù)是指：只有當(dāng)事務(wù)日志記錄寫入到Disk上的事務(wù)日志文件(.ldf)之后，事務(wù)才提交成功，并將控制權(quán)返回到客戶端（Client）；而延遲持久化（Delayed

41、Durable）事務(wù)是指：寫事務(wù)日志的操作是異步，事務(wù)在事務(wù)日志寫入Disk之前，提交成功，就是說，一旦查詢語句執(zhí)行成功，事務(wù)就提交成功，并將控制權(quán)返回到Client，但是數(shù)據(jù)更新可能并沒有記錄到事務(wù)日志文件（.ldf）中，直到事務(wù)更新的日志被持久化記錄到Disk上的事務(wù)日志文件之后，數(shù)據(jù)更新才變成持久，存儲數(shù)據(jù)更新丟失的可能性。懶提交事務(wù)持久化使用異步寫模式，將事務(wù)日志異步地寫入到事務(wù)日志文件（.ldf）中。在異步寫日志模式下，SQL Server把產(chǎn)生的事務(wù)日志先保存在緩存中，直到填滿緩存空間，或發(fā)生緩存刷新事件，事務(wù)日志才被寫入到事務(wù)日志文件（.ldf）中。懶提交之所以能夠減少IO操作的

42、延遲和競爭，是因為有以下三點優(yōu)勢：事務(wù)提交不需要等待寫日志操作的完成，一旦查詢語句執(zhí)行完成，就把控制權(quán)返回給Client，提高了數(shù)據(jù)更新的響應(yīng)速度；減少并發(fā)的事務(wù)產(chǎn)生寫日志競爭的可能性；在懶提交模式下，日志被緩存起來，系統(tǒng)一次能夠?qū)⒏髩K的日志記錄寫入到Disk，減少了Disk IO競爭，提高了數(shù)據(jù)更新的性能；在SQL Server 2016中，有以下三種方式使用懶提交模式：1，將數(shù)據(jù)庫設(shè)置為懶提交模式ALTER DATABASE DatabaseNameSET DELAYED_DURABILITY = DISABLED | ALLOWED | FORCED 2，在Natively Compi

43、led SP中，將Atomic Block設(shè)置為懶提交復(fù)制代碼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復(fù)制代碼3，在Commit子句中，指定懶提交選項COMMIT TRAN | TRANSACTION

44、transaction_name WITH ( DELAYED_DURABILITY = OFF | ON ) 參考文檔Applies To: Azure SQL Database, SQL Server 2016 PreviewRow versioning on disk-based tables (using SNAPSHOT isolation or READ_COMMITTED_SNAPSHOT) provides a form of optimistic concurrency control. Readers and writers do not block each other.

45、 With memory-optimized tables, writers do not block writers. With row versioning on disk-based tables, one transaction locks the row and concurrent transactions attempting to update the row are blocked. There is no locking with memory-optimized tables. Instead, if two transactions attempt to update

46、the same row, a write/write conflict (error 41302) will occur.Unlike disk-based tables, memory-optimized tables allow optimistic concurrency control with the higher isolation levels, REPEATABLE READ and SERIALIZABLE. Locks are not taken to enforce the isolation levels. Instead, at the end of the tra

47、nsaction validation ensures the repeatable read or serializability assumptions. If the assumptions are violated, the transaction is terminated. For more information, see Transaction Isolation Levels.The important transaction semantics for memory-optimized tables are:Multi-versioningSnapshot-based tr

48、ansaction isolationOptimisticConflict detectionEach of these semantics is explained in the following sections.Multi-Versioning in Memory-Optimized TablesRows in memory-optimized tables can have different versions. Concurrent transactions access potentially different versions of the same row.Memory-o

49、ptimized table data is version-based. For any row there may be different row versions that are valid at different points in time. Disk-based tables maintain different row versions when READ_COMMITTED_SNAPSHOT or ALLOW_SNAPSHOT_ISOLATION is ON. Memory-optimized tables maintain different row versions,

50、 even if READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION are OFF. The row versions of memory-optimized tables are not maintained in tempdb. Instead, the row versions are maintained in-line, as part of the memory-optimized data structures storing the rows in memory.Snapshot-Based Transaction Iso

51、lation for Memory-Optimized TablesAll operations in a single transaction use the same transactionally-consistent snapshot of the memory-optimized tables. All transaction isolation for memory-optimized tables is snapshot-based. For example, a transaction using the serializable isolation level to acce

52、ss memory-optimized tables will perform all operations on the same transactionally consistent snapshot.Transactions that access memory-optimized tables use this row versioning to obtain a transactionally sistent snapshot of the rows in the tables. The data read by any statement in the transaction wi

53、ll be the transactionally consistent version of the data that existed at the time the transaction started. Therefore, any modifications made by concurrently running transactions are not visible to statements in the current transaction.Optimistic Concurrency Control for Memory-Optimized TablesConflic

54、ts and failures are rare and transactions on memory-optimized tables assume there are no conflicts with concurrent transactions and operations succeed. Transactions do not take locks or latches on memory-optimized table to guarantee transaction isolation. Writers do not block readers. Writers do not

55、 block writers. Instead, transactions proceed under the (optimistic) assumption that there will be no conflicts with other transactions. Not using locks and latches and not waiting for other transactions to finish processing the same rows improves performance.In addition, if a transaction (TxA) read

56、s rows that have been inserted or modified by another transaction (TxB) that is in the process of committing, it will optimistically assume the other transaction will commit rather than wait for the commit to occur. In this case, transaction TxA will take a commit dependency on transaction TxB.Confl

57、ict Detection, Validation, and Commit Dependency ChecksSQL Server detects conflicts between concurrent transactions, as well as isolation level violations, and will doom one of the conflicting transactions. This transaction will need to be retried. (For more information, see Guidelines for Retry Log

58、ic for Transactions on Memory-Optimized Tables.)The system optimistically assumes there are no conflicts and no violations of transaction isolation. If any conflicts occur that may cause inconsistencies in the database or that may violate transaction isolation, these conflicts are detected, and the transaction is terminated.If a co