--> Title : SQL Server之分佈式事務
--> Author : wufeng4552
--> Date : 2009-11-11
SQL Server之分佈式事務
(一)概念:
分佈式事務是涉及來自兩個或多個源的資源的事務。Microsoft® SQL Server™ 2000支持分佈式事務，使用戶得以創建事務來更新多個SQL Server數據庫和其它數據源。
分佈式事務包括：
·資源管理器
控制分佈式事務所涉及的每個資源的軟件稱爲資源管理器。分佈式事務由各個資源管理器內的本地事務組成。每個資源管理器必須能夠與分佈式事務內的所有其它資源管理器相協調，以提交或回滾自己的本地事務。SQL Server 可以作爲分佈式事務內的資源管理器工作，並遵從用於分佈式事務處理的 X/Open XA 規範。
·事務管理器
提交或回滾分佈式事務由稱爲事務管理器的軟件組件控制。事務管理器與每個資源管理器相協調，確保一起提交或回滾所有組成分佈式事務的本地事務。Microsoft分佈式事務處理協調器 (MS DTC) 服務如事務管理器一樣工作。MS DTC 遵從用於分佈式事務處理的 X/Open XA 規範。
·兩階段提交 (2PC)
需要進行特殊的提交處理，以防止在管理跨越多個資源管理器的事務時出現問題。當刷新日誌緩衝區使其可用時，提交大事務可能需要相對較長的時間。提交進程本身還可能遇到錯誤，需要強行回滾。如果事務管理器只是請求每個資源管理器提交，則可能從一些資源管理器返回成功狀態，然後從某個資源管理器得到錯誤信息。這會導致衝突，因爲所有分佈式事務都應回滾，而部分事務已提交。兩階段提交通過將提交分成兩相可以解決此問題：
·準備
事務管理器給每個資源管理器發送一個準備提交的請求。然後，每個資源管理器執行完成提交進程所需的所有大量佔用資源的操作，如刷新所有日誌緩衝區。資源管理器只保留維護事務完整性所需的最少的鎖，然後給事務管理器返回成功狀態。
·提交
如果所有資源管理對發給它們的準備請求返回成功狀態，事務管理器將給每個資源管理器發送提交命令。然後，每個資源管理器快速將事務記錄爲已完成，並釋放上次控制的資源。如果有任何資源管理器對準備請求返回錯誤信息，事務管理器將給每個資源管理器發送回滾命令。
有幾種方法可以使應用程序在分佈式事務內包括 SQL Server 2000：
·如果應用程序有本地事務並且發出分佈式查詢，本地事務將升級到分佈式事務。
·發出 BEGIN DISTRIBUTED TRANSACTION 語句。
·如果應用程序有本地事務並且將 REMOTE_PROC_TRANSACTIONS 選項設置爲 ON，則調用遠程存儲過程將使本地事務升級到分佈式事務。
·使用用於 SQL Server 的 OLE DB 提供程序或 SQL Server ODBC 驅動程序的應用程序，可以使用 OLE DB 方法或 ODBC 函數讓 SQL Server 連接聯接由應用程序啓動的分佈式事務。
(二)案例
(2.1)問題描述
在執行分佈式事務時，在sql server 2005下收到如下錯誤：
消息 7391，級別 16，狀態 2，過程 xxxxx，第 16 行
無法執行該操作，因爲鏈接服務器 "xxxxx" 的 OLE DB 訪問接口 "SQLNCLI" 無法啓動分佈式事務。
在sql server 2000下收到如下錯誤：
該操作未能執行，因爲 OLE DB 提供程序 'SQLOLEDB' 無法啓動分佈式事務。
[OLE/DB provider returned message: 新事務不能登記到指定的事務處理器中。 ]
OLE DB 錯誤跟蹤［OLE/DB Provider 'SQLOLEDB' ITransactionJoin::JoinTransaction returned 0x8004d00a］。
(2.2)解決方案
(2.2.1)雙方啓動MSDTC服務
MSDTC服務提供分佈式事務服務，如果要在數據庫中使用分佈式事務，必須在參與的雙方服務器啓動MSDTC（Distributed Transaction Coordinator）服務。
(2.2.2) 打開雙方135端口
MSDTC服務依賴於RPC（Remote Procedure Call (RPC)）服務,RPC使用135端口，保證RPC服務啓動，如果服務器有防火牆，保證135端口不被防火牆擋住。使用“telnet IP 135 ”命令測試對方端口是否對外開放。也可用端口掃描軟件（比如Advanced Port Scanner）掃描端口以判斷端口是否開放。
(2.2.3)保證鏈接服務器中語句沒有訪問發起事務服務器的操作
在發起事務的服務器執行鏈接服務器上的查詢、視圖或存儲過程中含有訪問發起事務服務器的操作，這樣的操作叫做環回（loopback），是不被支持的，所以要保證在鏈接服務器中不存在此類操作。
(2.2.4)在事務開始前加入set xact_abort ON語句
對於大多數 OLE DB 提供程序（包括 SQL Server），必須將隱式或顯示事務中的數據修改語句中的 XACT_ABORT 設置爲 ON。唯一不需要該選項的情況是在提供程序支持嵌套事務時。
(2.2.5)MSDTC設置
管理工具―組件服務―計算機―我的電腦(右鍵)―MSDTC―安全配置
在安全配置窗口中做如下設置：
(2.2.5.1)選中“網絡DTC訪問”
(2.2.5.2)在客戶端管理中選中“允許遠程客戶端”“允許遠程管理”
(2.2.5.3)在事務管理通訊中選“允許入站”“允許出站”“不要求進行證” (2.2.5.4)保證DTC登陸賬戶爲：NT Authority/NetworkService
(2.2.6)鏈接服務器和名稱解析問題
建立鏈接sql server服務器，通常有兩種情況:
第一種情況，產品選”sql server”
EXEC sp_addlinkedserver
@server='linkServerName',
@srvproduct = N'SQL Server'
這種情況@server(linkServerName)就是要鏈接的sqlserver服務器名或者ip地址。
第二種情況訪問接口選“Microsoft OLE DB Provider Sql Server”或“Sql Native Client”
EXEC sp_addlinkedserver
@server='linkServerName',
@srvproduct='',
@provider='SQLNCLI',
@datasrc='sqlServerName'
這種情況，@datasrc（sqlServerName）就是要鏈接的實際sqlserver服務器名或者ip地址。
Sql server數據庫引擎是通過上面設置的服務器名或者ip地址訪問鏈接服務器，DTC服務只通過服務器名地址訪問鏈接服務器，所以要保證數據庫引擎和DTC都能通過服務器名或者ip地址訪問到鏈接服務器。
數據庫引擎和DTC解析服務器的方式不太一樣，下面分別敘述
數據庫引擎
第一種情況的@server或者第二種情況的@datasrc設置爲ip地址時，數據庫引擎會根據ip地址訪問鏈接服務器，這時不需要做名稱解析。
第一種情況的@server或者第二種情況的@datasrc設置爲sql server服務器名時，需要做名稱解析，就是把服務器名解析爲ip地址。
有兩個辦法解析服務器名：
一是在sql server客戶端配置中設置一個別名，將上面的服務器名對應到鏈接服務器的ip地址。
二是在“C:/WINDOWS/system32/drivers/etc/hosts”文件中增加一條記錄：
xxx.xxx.xxx.xxx 服務器名
作用同樣是把服務器名對應到鏈接服務器的ip地址。
DTC
不管哪一種情況，只要@server設置的是服務器名而不是ip地址，就需要進行名稱解析，辦法同上面第二種辦法，在hosts文件中增加解析記錄，上面的第一種辦法對DTC不起作用。
如果@server設置的是ip地址，同樣不需要做域名解析工作
(2.2.7)遠程服務器上的名稱解析
分佈式事務的參與服務器是需要相互訪問的，發起查詢的服務器要根據機器名或ip查找遠程服務器的，同樣遠程服務器也要查找發起服務器，遠程服務器通過發起服務器的機器名查找服務器，所以要保證遠程服務器能夠通過發起服務器的機器名訪問到發起服務器。一般的，兩個服務器在同一網段機器名能就行很好的解析，但是也不保證都能很好的解析，所以比較保險的做法是：在遠程服務器的在“C:/WINDOWS/system32/drivers/etc/hosts”文件中增加一條記錄：xxx.xxx.xxx.xxx 發起服務器名