分布式事務筆記

SQLSERVER分布式事務的使用

--BEGIN DISTRIBUTED TRANSACTION [transactionname]
--標志一個由分布式事務處理協調器MSDTC管理的TSQL分布式事務開始
--SERVER A服務器為主控服務器。當連接發出后續COMMIT TRANSACTION或
--ROLLBACK TRANSACTION語句時，主控服務器請求MSDTC在所涉及的服務器間管理
--分布式事務的完成

--SQLSERVER使用鏈接服務器或者遠程服務器作為分布式事務處理的平台，提供
--遠程存儲過程調用和分布式查詢


--當使用分布式事務進行一個遠程存儲過程調用和一個分布式查詢時，在SERVER A
--上發出BEGIN DISTRIBUTED TRANSACTION ，該連接調用SERVER B上的存儲過程
--和SERVER C上的另一個存儲過程，並且SERVER C上的存儲過程對SERVER D執行一個
--分布式查詢，則四個SQLSERVER服務器進入分布式事務中，SERVER A是該事務的創建者
--和控制服務器

--創建分布式事務，在本地和遠程數據庫同時刪除一條記錄，其中，遠程SQLSERVER
--的實例名稱為RemoteServer。本地和遠程數據庫同時提交或同時回滾該事務。
--注意，執行分布式查詢或調用存儲過程時，使用4部分名稱限定規則

--前提：本機的MSDTC和遠程機器的MSDTC服務要打開
--本機和遠程機器能互相ping通
--數據庫端口能互相telnet通
--創建一個鏈接服務器到遠程機器WIN7U-20130414Z 
USE [GPOSDB]
GO
SELECT * FROM [SystemPara] WHERE [Name]='HDTPort'
SELECT * FROM [WIN7U-20130414Z].[GPOSDB].dbo.[SystemPara] WHERE [Name]='HDTPort'



USE [GPOSDB]
GO
BEGIN DISTRIBUTED TRANSACTION
--從本地數據庫刪除一條記錄
DELETE FROM [JOE].[GPOSDB].[DBO].[SystemPara]
WHERE [Name]='HDTPort'

--從遠程數據庫中刪除一條記錄
DELETE FROM [GPOSDB].[dbo].[SystemPara]
WHERE [Name]='HDTPort'

COMMIT TRAN
GO


--其他會話正在使用事務的上下文的解決方法
--http://blog.csdn.net/lucas1573/article/details/12104389
--個人嘗試了下是由於在雙向的sql server訪問中采用了鏈式方式訪問（LinkedServer方式），
--遇到這種情況只需要將原來訪問對方數據庫的語句：
--select  *  from  linkedServerA.dbo.table1
--修改為：
--select  *  from  dbo.table1即可。
--標記下，以便以后解決。

轉載： http://blog.csdn.net/wufeng4552/article/details/4796846

SQL Server之分布式事務
--http://blog.csdn.net/wufeng4552/article/details/4796846

--> 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    發起服務器名