MSSQL-併發控制-1-Transaction

阿新 • • 發佈：2019-01-18

MSSQL併發控制原先打算分為兩個部分寫：隔離級別及鎖，寫的過程中，發現需要提及下事務的相關內容，故加多一篇博文，共3篇。併發控制，在於控制每一個事務的操作過程以及它們對資源的佔用情況，同時要保證事務的ACID特性。這裡簡單描述事務類別、ACID特性及對分散式事務的簡要說明。

1 事務類別

從提交方式：自動提交事務、手動提交事務從開啟方式：顯式事務、隱式事務其他：批範圍事務、分散式事務

1.1 顯式事務

通過API函式或者釋出T-SQL begin transaction、commit transaction、commit work、rollback transaction、rollback work 、save transaction等明確定義事務的開始和結束。這裡簡要說明commit、 save transaction 、rollback 、 xact_abort。

1.1.1 COMMIT

commit，提交最近一次未提交事務，這裡注意，commit transaction = commit work = commit tran [name]。每次commit，都需要把當前的@@trancount減去1。

 1 
 begin tran yu1
 2 select @@TRANCOUNT
 3        begin tran yu2
 4        insert into tbxin(name,age) select '第2層tran',100;
 5        select @@TRANCOUNT
 6              
 7                   begin tran yu3
 8                      insert into tbxin(name,age) select '第3層tran',100;
 9                      select 
 @@TRANCOUNT
10                      commit tran --等同於 commit tran anyname
11                      select @@TRANCOUNT
12                      commit tran --等同於 commit tran anyname
13                      select @@TRANCOUNT
14                      commit tran --等同於 commit tran anyname
15                      select 
 @@TRANCOUNT

1.1.2 ROLLBACK

rollback，回滾事務，有2中語法：

第一個，回滾當前所有未結束事務

rollback = rollback tran = rollback transaction = rollback work
無論嵌套了多少事務，@@trancount為多少，執行 rollback則直接回滾所有巢狀事務，設定@@trancount為0
常見錯誤案例：EXECUTE 後的事務計數指示 BEGIN 和 COMMIT 語句的數目不匹配。上一計數 = 1，當前計數 = 0。

第二個，回滾到某個儲存點的位置

rollback tran savepoint_name
不影響@@trancount計算，回滾到某個 save tran savepoint_name的位置

錯誤案例:

 1 CREATE PROC p_count
 2 AS
 3 begin transaction
 4 insert into tbxin(name,age) select '第一層tran',200;
 5 rollback transaction
 6 GO
 7 
 8 BEGIN TRAN
 9 EXEC p_count
10 select @@TRANCOUNT
11 
12 訊息 266，級別 16，狀態 2，過程 p_count，第 0 行
13 EXECUTE 後的事務計數指示 BEGIN 和 COMMIT 語句的數目不匹配。上一計數 = 1，當前計數 = 0。

1.1.3 SAVE TRANSACTION

save transaction，定義在按條件取消某個事務的一部分後，該事務可以返回的一個位置。如果將事務回滾到儲存點，則根據需要必須完成其他剩餘的 Transact-SQL 語句和 COMMIT TRANSACTION 語句，或者必須通過將事務回滾到起始點完全取消事務。若要取消整個事務，使用窗體 ROLLBACK TRANSACTION transaction_name。這將撤消事務的所有語句和過程。

save transaction [savepoint_name] 提供使用者在事務內設定儲存點或標記，所以 save transaction 只能在事務內部執行；
save transaction [savepoint_nmae] 不影響 @@trancount 計數；
注意 save transaction [savepoint_name] 只有對應 rollback transaction [savepoint_name]，並沒有對應 commit transaction [savepoint_name]，強調下：對應的rollback transaction [savepoint_name] 是有帶儲存點名字的，如果沒有帶名字，則會回滾整個最外部的事務；
save transaction 對應的 rollback transaction [savepoint_name]並不需要一一對應，可以多個save tran 對應0到多個rollback tran；
事務內，可以有多個 save transaction [savepoint_name]，可使用 rollback transaction [savepoint_name] 回滾到任意一個儲存點；
支援savepoint_name重複命名，但是不建議。在事務中允許有重複的儲存點名稱，但指定儲存點名稱的 ROLLBACK TRANSACTION savepoint_name 語句只將事務回滾到使用該名稱的最近的 SAVE TRANSACTION savepoint_name；
在使用 BEGIN DISTRIBUTED TRANSACTION 顯式啟動或從本地事務升級的分散式事務中，不支援 SAVE TRANSACTION。

 1 begin tran
 2 select @@TRANCOUNT
 3 
 4        save tran yu1
 5        insert into tbxin(name,age) select '第1層save',100;
 6        select @@TRANCOUNT
 7              
 8                   save tran yu2
 9                      insert into tbxin(name,age) select '第2層save',100;
10                      select @@TRANCOUNT
11                          
12                             save tran yu3
13                           insert into tbxin(name,age) select '第3層save',100;
14                           select @@TRANCOUNT
15 
16                                  save tran yu4
17                                insert into tbxin(name,age) select '第4層save',100;
18                                select @@TRANCOUNT
19 
20                             rollback tran yu3
21                             select @@TRANCOUNT
22 
23               commit tran yu2
24         select @@TRANCOUNT
25 
26 rollback tran

1.1.4 XACT_ABORT

xact_abort用於設定環境屬性，預設為關閉狀態。在關閉的狀態下，巢狀事務中，若某個巢狀事務異常，不影響整個事務的進行，需手動寫明錯誤後的處理方式（commit or rollback）；啟動狀態下，當某個巢狀事務異常，回滾整個巢狀事務。

1.2 隱式事務

為連線將隱性事務模式設定為開啟之後，當資料庫引擎例項首次執行下列任何語句時，都會自動啟動一個事務：當連線以隱式事務模式進行操作時，資料庫引擎例項將在提交或回滾當前事務後自動啟動新事務。無須描述事務的開始，只需提交或回滾每個事務。隱性事務模式生成連續的事務鏈。通過 API 函式或 Transact-SQL SET IMPLICIT_TRANSACTIONS ON 語句，將隱性事務模式設定為開啟。

ALTER TABLE
CREATE
DROP
OPEN
FETCH
GRANT
REVOKE
SELECT
UPDATE
DELETE
INSERT
TRUNCATE TABLE

1.3 自動提交事務

--例子
INSERT INTO ...
--資料庫預設的事務管理模式，在沒有被顯式事務及隱式事務覆蓋的情況下，自動在每個Tsql完成時，提交或者回滾

1.4 手動提交事務

--例子
BEGIN TRANINSERT INTO ...
 
COMMIT / ROLLBACK--資料庫預設的事務管理模式，顯式事務在完成時，手動指定SQL，說明提交或者回滾。

1.5 批範圍事務

只能應用於多個活動結果集 (MARS)，在 MARS 會話中啟動的 Transact-SQL 顯式或隱式事務變為批處理級事務。當批處理完成時沒有提交或回滾的批處理級事務自動由 SQL Server 進行回滾。

1.6 分散式事務

分散式事務跨越兩個或多個稱為資源管理器的伺服器，有同構分散式及異構分散式。在MSSQL中，可以通過 BEGIN DISTRIBUTED TRANSACTION 命令開啟分散式事務。這裡有一點需要注意一下：當事務內部操作跨越了多個伺服器，但是並沒有使用 BEGIN DISTRIBUTED TRANSACTION 命令開頭的事務，也會自動轉化為分散式事務！假設A伺服器上的資料庫 Orders 用於記錄訂單，B伺服器上的 Stock 用於記錄庫存（不考慮程式建立兩個DB連線，按照僅建立一個 DB連結到 A 上）。當 Stock有庫存，並減去一個庫存後，Orders 正常可以下一個訂單，則這個下單事務內，操作了兩個伺服器，屬於分散式事務，簡要操作如下：

BEGIN DISTRIBUTED TRANSACTION
SELECT ... FROM Stock... WHERE ...
UPDATE Stock ...
INSERT INTO ORDERS ...
COMMIT

在SQL SERVER中，如果沒有配置伺服器的DTC服務，使用分散式事務的時候，會報錯如下：

(1 行受影響)
訊息 8501，級別 16，狀態 3，第 4 行
伺服器 'XINYSU\MSSQL' 上的 MSDTC 不可用。
 
(1 行受影響)
連結伺服器"test_xinysu"的 OLE DB 訪問介面 "SQLNCLI11" 返回了訊息 "該夥伴事務管理器已經禁止了它對遠端/網路事務的支援。"。
訊息 7391，級別 16，狀態 2，第 4 行
無法執行該操作，因為連結伺服器 "test_xinysu" 的 OLE DB 訪問介面 "SQLNCLI11" 無法啟動分散式事務。

如果例項需要支援分散式事務，則需要在雙方的伺服器其上開啟DTC服務，執行XA事務。這裡注意一點，如果連結伺服器是MySQL資料庫，因為mysql的odbc不支援 XA事務，所以，會報錯無法啟動分散式事務。官網解釋如下：

MySQL OLE DB driver does not support MSDTC because it doesn’t support auto-enlistment in the ambient COM+ transaction. If you really want to, you can write your own XA.DLL to wrap MySQL OLEDB driver in an XA transaction. windows啟動DTC服務，配置如下： "管理工具" -> "元件服務" ，按照下圖操作，開啟本地的DTC配置，啟動網路DTC，啟動XA事務，如下圖。

配置結束後點擊應用，則會提示MSDTC服務會被重啟，同時，依賴DSDTC的應用程式可能需要重啟才能使用新的配置，這個時候就需要重啟 SQL SERVER的服務了。

如果是正在跑的資料庫，建議先從庫配置，切換主從，主庫配置的順序來啟用。最好是在搭建伺服器一開始，就瞭解程式層面是否會使用到這個功能。正常情況下，都是在程式中配置多個DB連線，由程式來控制分散式事務。這裡多說一個日常需要注意的事項，在使用連結伺服器對另外一個伺服器上的DB做增刪改操作的時候，都是一行一行傳遞過去做操作的。比如：

1 INSERT INTO mssql_xinysu.dbname.dbo.tbid(id) select id from sys.sysobjects
2 或者
3 INSERT INTO openquery([mysql_xinysu],'select id from tbid') select id from sys.sysobjects

假設 select id from sys.sysobjects 的結果有2k行，則在第一個SQL的 ODBC 是這麼處理的：

分為2000個INSERT 語句
(@Param000004 int)INSERT [dbname].[dbo].[tbid]([id]) VALUES(@Param000004)
一條一條INSERT

第二個SQL的ODBC是這麼處理的：

分為2000個INSERT 語句
INSERT INTO tbid ([id]) VALUES(單個的ID值)
一條條INSERT

通過這個操作說明，可想而知，連線伺服器操作是非常慢的過程，不建議在有效能要求的業務上進行這樣的使用操作。

2 ACID特性

2.1 Atomicity

簡稱為A，事務的原子性。要求在同個事務中，單個SQL或者多個SQL對資料進行的修改操作，要麼一起執行提交，要麼全部回滾不提交。儲存引擎中，通過undo log 來實現事務的原子性。例子：

2.2 Consistency

簡稱為 C，事務的一致性。事務在完成時，必須使所有的資料都保持一致狀態。在相關資料庫中，所有規則都必須應用於事務的修改，以保持所有資料的完整性。事務結束時，所有的內部資料結構（如 B 樹索引或雙向連結串列）都必須是正確的。一致性，可以分為兩個層次來說明。一個是儲存引擎層，一個是業務層。在儲存引擎層，當某個表格發現了資料修改，那麼修改的行資料應該符合表格的約束條件、外來鍵條件，涉及到索引頁資料也要做相應修改，保證資料修改後的完整性。在業務層，事務的一致性更多的在於程式設計，比如在一個事務內，賬號A給賬號B轉賬100元，那麼這個事務結束後，A的賬號需要少100元，B的賬號需要增加100元。

2.3 Isolation

簡稱為 I，事務的隔離性。由併發事務所做的修改必須與任何其他併發事務所做的修改隔離。在SQL SERVER中，通過設定隔離級別來保證。事務識別資料時資料所處的狀態，要麼是另一併發事務修改它之前的狀態，要麼是第二個事務修改它之後的狀態，事務不會識別中間狀態的資料。這稱為可序列性，因為它能夠重新裝載起始資料，並且重播一系列事務，以使資料結束時的狀態與原始事務執行的狀態相同。根據業務的實際情況和需求，可以對不同的業務選擇不同的隔離級別來控制該事務與其他併發事務之間的隔離關係，隔離級別越高，併發能力就相應越低。

2.4 Durability

簡稱為D，事務的永續性。完成完全持久的事務之後，它的影響將永久存在於系統中。該修改即使出現系統故障也將一直保持。儲存引擎中，通過redo log 來實現事務的永續性。

3 協議

在事務內，除了保持ACID的特性外，在MSSQL中，會遵循相應的兩階段鎖跟XA協議。

3.1 2PL

2-PL，也就是兩階段鎖，鎖的操作分為兩個階段：加鎖、解鎖。先加鎖，後解鎖，不相交。加鎖時，讀操作會申請並佔用S鎖，寫操作會申請並佔用X鎖，如果對所在記錄加鎖有衝突，那麼會處於等待狀態，知道加鎖成功才驚醒下一步操作。解鎖時，也就是事務提交或者回滾的時候，這個階段會釋放該事務中所有的加鎖情況，進行一一釋放鎖。假設事務對記錄A和記錄B都有操作，那麼，其加鎖解鎖按照逐行加鎖解鎖順序，如下：

BEGIN
LOCK A
READ A
A:A+100
WRITE A
UNLOCK A
LOCK B
READ B
UNLOCK B
COMMIT

兩階段鎖還有幾種特殊情況：conservative（保守）、strict（嚴格）、strong strict（強嚴格），這三種類型在加鎖和釋放鎖的處理有些不一樣。

conservative

在事務開始的時候，獲取需要的記錄的鎖，避免在操作期間逐個申請鎖可能造成的鎖等待，conservative 2PL 可以避免死鎖

strict

僅在事務結束的時候（commit or rollback），才釋放所有 write lock，read lock 則正常釋放

strong strict

僅在事務結束的時候（commit or rollback），才釋放所有鎖，包括write lock 跟 read lock 都是結束後才釋放。

3.2 XA

說XA協議，不得不提2PC、3PC協議，而提這兩個協議，又不得不說說CAP理論。

3.2.1 CAP理論

CAP分別是Consitency（一致性）、Availability（可用性）、Partition tolerance（分割槽容錯性），在分散式儲存系統裡邊，最多隻能同時滿足其中兩者。

Consitency

一致性，在分散式儲存系統中，對於每一次的讀操作，對於讀到的資料，要麼都是最新的，要麼則返回一個錯誤
這裡的CAP的C跟ACID的C雖然是一個單詞，但是含義不一樣哦，記得區分
在關係型資料庫裡邊，通常優先考慮到是一致性

Availability

可用性，保證每次請求都正常，但不要求返回的結果是最新的資料

Partition tolerance

分割槽容錯性，當各個分割槽之間因為網路發生訊息丟失或者延遲是，分散式儲存系統仍能正常執行。
則是在操作涉及多個伺服器的事務過程中，

3.2.2 2PC

兩階段提交，全程是 Two Phase Commitment Protocol。也就是將分散式事務分為了兩個階段：Prepare 跟 Commit/Rollback。在分散式系統中，如果其中一個伺服器上的操作失敗，則其他伺服器上的操作也需要回滾，即在一個事務內，多個跨伺服器的操作中，要麼所有都成功，要麼所有都失敗。但是呢，實際上每個節點都可以對自身的操作做控制，但是卻不能控制同個分散式系統的其他節點的操作，這也就導致了，同個事務中，如果A節點操作成功，但是B節點操作失敗，如果沒有相應的處理方式，則會出現，某些操作成功，某些操作失敗，造成資料不一致的情況。如何處理這個問題呢？這就需要引入一個第三方元件來統一接收各個節點的操作情況，然後再根據各個操作的結果來判斷各個節點的操作是否提交或者回滾。這個就是 2PC的雛形了。

2PC的簡要處理說明如下：

Prepare

事務協調器coordinator 對涉及到的節點發起操作申請；
各個節點獲取到操作後，直接在資料庫中執行，並存放相關的日誌到redo / undo log中，注意注意，這裡僅是操作，並沒有提交或者回滾該操作；
各節點將處理日誌寫入磁碟；
返回資訊給coordinnator

如果節點可以正常執行，則返回 Ready 通知 coordinator；
如果節點不可以正常執行，則該節點本地回滾該操作，並返回 Not Ready 通知 coordinator

Comiit/Rollback

coordinator 根據各個節點的反饋資訊，來決定該事務操作的結果
coordinator將操作結果記錄到日誌中
反饋操作結果給各個節點

如果出現一個或者一個以上的節點反饋回來 Not Ready的通知，則coordinator會通知正常執行操作的節點回滾事務
如果沒有出現 Not Ready 的反饋，則coordinator會通知所有節點 COMMIT 操作。

2PC如何處理異常？

事務協調器宕機

這裡需要引入一個新角色：coordinator watchdog，事務協調器看門狗
無論是coordinator 還是分散式系統的各個節點，在操作過程中，都會記錄當前操作的狀態日誌。當出現異常或者恢復時，可以通過日誌來判斷當前的情況。
當 coordinator 發起提議後宕機，而此時各個節點開始操作，然後反饋給 coordinator，但是遲遲沒有接收到 coordinator 的迴應，那麼各個節點的操作就無法回滾或者提交，處於堵塞情況。而 coordinator watchdog 則可以解決這個堵塞現象，當coordinator宕機一定時間後，看門狗會自動擔任 coordinator 的工作，接收各個節點的反饋情況，然後再根據反饋結果傳遞 COMMIT/ROLLBAK給各個節點。

節點宕機

prepare階段宕機，則coordinator接收到事務後傳送給各個節點需要做的操作時，節點發生宕機，這個時候，則該節點無法返回 Ready 的訊息，coordinator則預設接受該節點發出的 abort 資訊，coordinator通知其他各個節點 Rollback 操作；
Comiit/Rollback階段宕機，由於各個節點及coordinator都有日誌記錄，coordinator會記錄這個事務是會提交還是回滾，當節點宕機後，其他節點根據coordinator的通知執行ROLLBACK或者COMMIT，而宕機節點本地會記錄該事務操作未執行提交或者回滾，節點恢復後，會從 coordinator 日誌中讀取日誌，重新處理該操作。

3.2.3 XA協議

XA協議是 X/Open DTP Group 定義的兩階段提交協議，規定了事務管理器跟資源管理器的介面。事務管理器指的是二階段協議中的 coordinator ，而資源管理器則指的是各個資料庫系統。一般情況下，各個資料庫系統並不知道彼此之間做了什麼，這個時候，就需要一個第三方來做資訊的接受跟傳達，由它通知和協調相關資料庫的提交或回滾。XA就是用來定義這個第三方的協議，詳細定義了交易中介軟體與資料庫之間的介面規範（即介面函式），交易中介軟體用它來通知資料庫事務的開始、結束以及提交、回滾等。 XA介面函式由資料庫廠商提供。通常情況下，交易中介軟體與資料庫通過XA 介面規範，使用兩階段提交來完成一個全域性事務，XA規範的基礎是兩階段提交協議。注意，XA事務的效能相對較差。參考文件：