《MS SQL Server 2000管理員手冊》系列——25. 元件服務及 Microsoft 分布式交易協調員

25. 元件服務及 Microsoft 分布式交易協調員
元件服務概述
Microsoft 分布式交易協調員
本章總結
本章將學習 Microsoft 分布式交易協調員（Microsoft Distributed Transaction Coordinator，MS DTC），這項功能允許一個資料庫交易可以存取多個資料來源，並且還能確保資料的完整性。您在這一章會看到 MS DTC 有許多用途，很多類型的應用程式都必須用到 MS DTC 提供的服務。
MS DTC 是元件服務的一個部份。元件服務由 Microsoft Windows NT 服務衍生而來，是內建於 Windows 2000 產品與技術的集合。元件服務包含了 Component Object Model（COM）、Distributed COM（DCOM）、Microsoft Transaction Server、Microsoft Internet Information Server 及 Microsoft Message Queue Server。在 Windows 2000 元件服務中，COM 和 DCOM 的技術有了新的層級，所以稱 COM+。COM+ 應用程式和其它的系統服務組成 Windows 2000 元件服務這個項目。在正式介紹 MS DTC 之前，我們會先簡單介紹元件服務。
元件服務概述
　
 元件服務（Component Services） 是由數個不同的產品組合而成的工具，使用統一的 Microsoft 管理主控台（Microsoft Management Console，MMC）管理視窗。元件服務是主控台的一個嵌入式嵌入式管理單元，服務內容包括：
•  COM+ 應用程式服務
　
•  MS DTC
　
•  事件檢視器服務
　
•  系統服務
　
•  Microsoft 訊息隊列
　
要動作項目服務管理工具，按一下 開始 → 程式集 → 系統管理工具 ，然後選擇 元件服務 啟動主控台， 25-1。

　
 
圖25-1　「元件服務」主控台
COM+ 應用程式服務
　
 COM+ 應用程式服務 是指利用 Microsoft 的 COM+ 規格開發出來的應用程式。COM+ 是 COM 模組的延伸。COM 就是用於分布式應用程式的開發，發展到 COM+，讓安全性及隊列組件更容易在應用程式上開發。
您可以在元件服務 MMC 設定您的 COM+ 應用程式組件。依下列步驟進入您的 COM+ 應用程式（ 25-2）：展開 元件服務 → 電腦 → 我的電腦 → COM+ 應用程式 。
在螢幕上您會看到所有註冊過的 COM+ 應用程式。在展開您 COM+ 應用程式的資料夾後，就可以選擇進入這些應用程式。

　
 
圖25-2　元件服務主控台視窗內的 COM+ 應用程式
MS DTC
　
在剛剛看到的元件服務主控台視窗，COM+ 應用程式資料夾的下面的就是 MS DTC 的資料夾。我們會在下一節詳細討論 MS DTC，這一節就先不贅述。
事件檢視器服務
　
這項服務工具是由 Window NT 的事件檢視工具開發而來。在 Windows 2000 的事件檢視器服務和在 Windows NT 的事件檢視相同，允許您進入事件記錄中存取資料。所有的應用程式、安全性資料、系統錯誤及資訊資料都會存放在事件記錄中，我們必須隨時檢查這些記錄。您可以在元件服務的視窗中找到事件檢視資料夾，展開此資料夾（ 25-3），點選欲檢視的的事件記錄即可檢視資料。

　
 
圖25-3　事件檢視資料夾視窗
系統服務
　
系統服務工具是由 Windows NT 服務工具發展而來。系統服務可讓您檢視與管理安裝在系統上的所有服務工具。當您展開 服務 資料夾即可檢視系統服務（ 25-4）。

　
 
圖25-4　展開 服務 資料夾檢視系統服務工具。
如果要啟動或是停止服務工具，點選服務工具後按滑鼠右鈕，在捷徑功能表中選取欲執行的選項（ 25-5）。

　
 
圖25-5　捷徑功能表
如果要檢視或修改服務工具的屬性，在中的捷徑功能表內選取 屬性 ，叫出服務工具的 屬性 視窗（ 25-6）。

　
 
圖25-6　服務屬性中「一般」頁簽的視窗
在 一般 的視窗，可以改變服務工具設定內容，也可以停止或暫停服務工具。其它的標籤頁允許更改該項服務登入 Windows 2000 的方式。 屬性 對服務工具來說很重要。在這個設定內，可以選擇當系統開啟是否自動啟動服務工具，或是變更 SQL Server 和 MS DTC 所使用的賬戶。此外，也可以指定當服務工具出現問題時該執行什麼動作。在這個視窗中您還可以檢視各服務間的依存性。
Microsoft 訊息隊列
　
雖然服務元件 MMC 沒有顯示 Microsoft訊息隊列（MSMQ），但因為它也利用到 MS DTC 作外部交易，因此可視為元件服務的一部份。Microsoft 訊息隊列允許訊息在不同的應用程式或系統間傳遞交易或非交易式的訊息。應用程式利用訊息隊列，在伺服器間遞送 耐久 訊息（durable message）。耐久訊息的意思是這個訊息不會因系統失敗（如因斷電而故障）而消失。假設系統突然斷電，當系統回複時，MSMQ 會繼續執行訊息隊列。Microsoft 訊息隊列利用 儲存並轉送（store-and-forward） 的方式來遞送訊息，這種方式即使是在網路產生問題時，訊息依然會儲存在隊列中。訊息隊列的其它功能如下：
•   可不聯機送訊 ：要利用訊息隊列組件遞送訊息，不代表必須聯機；此外，訊息可以路由，這樣就可以在不同通訊協議間建立連結。
　
•   可動態隊列管理 ：在新增或更改隊列時不需重新啟動訊息隊列。
　
•   可排列訊息優先順序 ：訊息隊列可依優先順序將訊息排序，可以設定先傳送高優先順序訊息。
　
•   可以支援叢集 ：訊息隊列可偵測叢集，支援主動／主動（active/active）和主動／被動（active/passive）叢集。
　
•   可與 Active Directory 目錄整合 ：訊息隊列可以利用在 Active Directory 中的目錄服務。
　
•   可與 MSMQ 1 溝通 ：訊息隊列可與 MSMQ 1 溝通，MSMQ 1 是訊息隊列前身。
　
•   可與 Windows 2000 安全性功能整合 ：可利用 Windows 2000 強化後的安全功能。
　
•   訊息備份與回複 ：可以將訊息備份，當系統發生問題也可以回複訊息。
　
•   使用 MMC 進行管理 ：現在訊息隊列管理功能和其它很多管理工具相同，都內嵌在主控台進行。
　
如您所見，Microsoft 訊息隊列系統支援很多功能。不過本章會將學習重點放在訊息隊列中的交易訊息組件，也就是 MS DTC。
Microsoft 分布式交易協調員
　
之前曾經提到，MS DTC 是 Windows 2000 元件服務的一部份。（MS DTC 這個觀念在 SQL Server 7 就已經存在。）元件服務也包含 COM+。COM+ 是用於有非交易式通訊需求時，而 MS DTC 則用於有交易式訊息通訊需求時。
MS DTC 主要用來處理分布式交易。所謂 分布式交易 ，就是跨越兩個或多個資料庫的單一 SQL Server 內部的交易，這些資料庫可以放在相同或分別放在不同的電腦系統內。而在同一個資料庫內不同資料表間的交易，則不能稱作分布式交易。在同一個系統上，資料庫與資料庫間的前端交易可利用一般（非分布式）處理；但是 SQL 在執行時仍會以分布式交易處理。
MS DTC 概觀
　
當一筆交易包含許多不同來源的資料時，就必須協調這些提供資料的應用程式。協調的重要性在於確保交易必須是不可部份完成。換句話說，資料的修改不是全部執行，就是全部不執行。如果一筆交易部份完成，部份失敗，就會造成交易邏輯沒有一致性，還可能使資料流失。MS DTC 執行 兩階段交易認可（Two-Phase Commit） 確認交易邏輯。
兩階段交易認可近年來在技術上有很大的改革，這並不是新的技術，也非 SQL Server 專屬。事實上，因 SQL Server 和 Oracle 兩種資料庫皆支援兩階段交易認可的模式及 ODBC，因此兩種資料庫間還可利用兩階段交易認可進行分布式交易。
兩階段交易認可的兩個階段分別為：準備階段與認可階段。在應用程式中以 COMMIT 指令初始化 MS DTC 執行兩階段交易認可。一台 SQL Server 上的 MS DTC，與另一個系統上的 MS DTC 協調處理一筆分布式交易。MS DTC 中處理兩段交易認可的組件稱作 資源管理員 。
當您執行了認可（COMMIT）指令，MS DTC 通知資源管理員開始 準備階段 。第一階段（也就是準備階段），會執行所有認可所需要的動作，包括排清緩衝區和寫入交易記錄檔案等動作。這個階段所執行的步驟和一般的標準認可步驟類似，唯一不同的是在這裡，SQL Server 不會真的認可交易，也不會對證券交易所用到的資源解除鎖定。當所有認可交易的前置動作都完成時，資源管理員便傳送準備成功的訊號給交易管理員。在所有的資源管理員都傳出成功的訊號時，就進入認可階段。
 認可階段 在分布式系統中進行。在這個階段，如果所有的資源管理員都傳出成功訊號，應用程式端就會接受到認可成功的訊息；如果其中有一個資源管理員傳出失敗訊號，就會傳送 複原（rollback） 指令給每位資源管理員，這時應用程式端就會收到認可失敗的訊息。當系統交易時間過長，也會執行複原指令。當一個系統內的認可失敗，分布式交易中所有其它相關係統也會執行複原指令。
MS DTC 使用範例
　
在這一節，我們來參考兩個現實生活中用到 MS DTC 的範例，您可以看到 MS DTC 在分布式交易中的重要性，以及系統如何處理不成功的交易。
________________________________________
真實世界 銀行交易
以銀行間的匯款交易來說，當客戶要將 A 銀行賬戶 1 的錢匯入 B 銀行賬戶 2 時，就銀行的電腦來說就得執行兩項交易：把錢從賬戶 1 扣除，然後把錢加入賬戶 2。

　
 
先來談談如何匯款。如果兩個賬戶都在同一家銀行，系統只要更新一個資料庫的資料即可；但是如果兩個賬戶各為不同的銀行，就得啟動遠程交易，這筆交易對系統來說，就得處理兩個交易步驟，交易可在兩個系統中的其中一個系統進行，也可以在第三個系統（用戶端系統）上進行。

　
 
當銀行員在用戶端電腦的應用程式上執行交易，應用程式開始呼叫 SQL 執行任務，SQL 會開始執行下列項目：
1. 更新系統 A，把賬戶 1 的金額扣除
2. 認可交易
3. 更新系統 B，把金額加入賬戶 2
4. 認可交易
在確定每個系統運作都完全正常的情況下，這樣的運作方式是可以接受的，但卻並不是一個完全安全的運作方式。例如，如果只有一個系統完成了交易，但另一個系統交易失敗。以下是可能發生的情形：
•  系統 A 的交易步驟失敗，系統 B 的交易無法執行，轉帳失敗。
　
•  系統 A 的交易步驟成功，但系統 B 的交易失敗，金額就此消失。
　
這樣的交易情況當然不容發生。所以下列的交易步驟才算是安全的交易程式。
1. 更新系統 A，把賬戶 1 的金額扣除
2. 更新系統 B，把金額加入賬戶 2
3. 把上述兩個步驟當作一組交易程式來認可，全部認可或是全部不認可。
MS DTC 可以讓您將分布式交易的認可設定為一組來認可，也就是說您可以認可一組交易步驟，如果其中一個交易步驟出了問題，就執行複原指令，這樣就不會產生上述的錯誤。
________________________________________
________________________________________
真實世界 電子商務應用程式
電子商務的應用程式常需要同時處理大量同時發生的線上交易行為，因此需要數個系統應付龐大的交易量。一家公司如果只用一台電腦系統來應付所有的交易，並不適合，以下是一家公司可能遇到的各種狀況：
•   一個系統負載過重 ：每台電腦和系統都有一定的負荷量，太多的交易量容易造成單一的電腦及系統超載。
　
•   商業邏輯 ：以商業邏輯而言，將不同的功能分放在不同的系統上是較合理的做法。例如，可以把使用者資料放在一個系統，產品資料放在另一個系統。
　
•   委外 ：電子商務常運用委外的功能。例如，會計部分可能是委外至會計師事務所。
　
當交易需要跨越多個系統（或是一個系統裡的多個資料庫），就會運用分布式交易存取系統資料（或資料庫）。如果不運用 MS DTC，就無法確保系統交易的不可部分完成性。
現在來看看電子商務交易如何運用分布式交易。這個範例的客戶以信用卡在網路商家購物。我們來看看完成一筆交易要經過哪些步驟。
________________________________________
________________________________________
說明
電子商務的交易方式有很多種，我們這裡用到的範例僅供教學參考，不代表是最佳的交易方式。
________________________________________
________________________________________
1. 客戶透過網路連上網路商家的網站，還未正式進入商家的資料庫。
2. 客戶選擇商品 A，放入電子購物車中。
3. 要完成上述動作，電腦內部就必須進入資料庫執行兩項交易步驟。
a. 搜尋步驟，找出客戶是新客戶或是舊客戶，如果是舊客戶就取出其 Cust_ID 的相關資料。（有些應用程式在購買步驟時，才進行搜尋步驟。）
b. 把商品 A 放入購物車資料表。
4. 當客戶準備結帳，一筆交易或一組交易資料庫開始執行下列運作：
a. 讀取購物車資料表，找出客戶購買的商品項目。
b. 更新訂單資料表，確認新增的訂單已加入資料表。
c. 更新客戶資料庫，確認賬單會寄給客戶。在這個範例，客戶資料和訂單資料是在兩個不同的資料庫內，所以就會運用到分布式交易。
d. 在購物車資料表中，將此商品從屬記錄內刪除。（有些應用程式在批處理時才將記錄刪除。）
e. 當賬戶資料表和訂單資料表更新完成，才開始認可交易，完成分布式交易。
5. 現在，電子商家會進入貨倉的資料庫，備貨及準備出貨，完成這個程式的細節如下：
a. 查詢及取出訂單資料表。
b. 將查詢到的貨品裝箱準備出貨。
c. 電子商家的系統串連到信用卡處理器作付費要求。這樣的交易模式也算分布式交易，因為付費要求是記錄在本機端。（有些應用程式在客戶結算時就先作付費要求，這樣的方法並不是一般的正常程式，因為在結算時就和信用卡中心聯機要求授權，會拉長交易時間。）
d. 更新訂單資料表與資料庫後準備出貨。
6. 貨物成功到達客戶手中。
在這個交易中如果沒有使用 MS DTC 作兩階段交易認可，就可能會產生以下的問題：
o 付費要求步驟認可成功，但訂單資料表與資料庫的更新過程認可失敗，造成已付費但沒出貨。
　
o 付費要求步驟認可失敗，但訂單資料表與資料庫更新步驟認可成功，造成出貨卻沒收到錢。
　
o 出貨步驟認可成功，但其實貨還沒出。
　
所以分布式交易最重要的一點就是確認交易中的每個資料庫都要一併更新，不然就得一併不更新。若是交易過程沒有協調，資料庫之間就失去一致性，並造成很多錯誤。
________________________________________
MS DTC 屬性
　
之前提到 MS DTC 在交易過程中的重要性。這裡我們將討論啟動 MS DTC 的幾種方法。
•  呼叫包含於分布式交易中的遠程程式
　
•  利用 Transact-SQL（T-SQL）指令來啟動分布式交易
　
•  在多個 OLE DB 資料來源更新資料
　
•  在您的應用程式中內嵌 MS DTC 指令
　
這三種方法可以讓您在系統上執行分布式交易（ 25-7）。交易初始化端的 SQL Server 執行個體將會執行所有呼叫 MS DTC 的必要操作以執行分布式交易，這個動作不需手動執行，SQL Server 會幫您打理一切細節。

　
 
圖25-7　SQL Server 中初始化分布式交易
如果您用最後一種方法來啟動分布式交易，用戶端的應用程式介面及網路上的 SQL Server 介面會和 MS DTC 及 SQL Server 溝通。SQL Server 用戶端會協助協調分布式交易。圖 25-8 為分布式交易的架構。

　
 
圖25-8　在應用程式中內嵌 MS DTC 指令以初始化分布式交易
MS DTC 程式設計
　
本書不是針對程式設計者而寫，所以不會在如何運用及設計分布式交易方面著墨太多；不過，本節會簡單列出幾種可以啟動分布式交易的方法，並用簡單的交易測試 MS DTC。
下列幾種動作均可啟動分布式交易：
•   在一筆交易中存取遠端資料來源 ：這樣一來，這筆交易就會升級為分布式交易。在一筆交易內，任何分散式查詢都會將交易升級為分布式交易。
　
•   執行 BEGIN DISTRIBUTED TRANSACTION 指令 ：即可馬上產生分布式交易。
　
•   使用 SQL Server 安裝選項中的 REMOTE_PROC_TRAN-SACTION 選項 ：執行遠程呼叫程式會馬上將交易升級為分布式交易。
　
•   呼叫 OLE DB 或 ODBC 函數 ：OLE DB 和 SQL Server 有啟動分布式交易的文法。
　
透過 T-SQL 進行分布式交易，可以測試 MS DTC。您可以利用 T-SQL 的 BEGIN DISTRIBUTED TRANSACTION 指令啟動分布式交易，用 COMMIT 指令執行認可，程式如下：
BEGIN DISTRIBUTED TRANSACTION
SELECT EmployeeID FROM Northwind.dbo.Employees
SELECT emp_id FROM pubs.dbo.employee
GO
COMMIT
GO
先輸入前四行的程式碼，執行後再輸入最後兩行程式碼。這樣您可以先在分布式交易協調員（在元件服務 MMC）資料夾中的 異動清單 資料夾，檢視交易。要檢視這個資料夾，請展開 元件服務 → 電腦 → 我的電腦 ，最後展開 元件服務 主控台中的 Distributed Transaction Coordinator 。當交易檢視完成，再輸入上述 T-SQL 程式碼中的最後兩行。注意，現在交易認可後，在 異動清單 資料夾就找不到這筆交易。當然，大部分的分布式交易過程是很複雜的（包括更新和插入），並不如範例這麼簡單。這個範例僅在不變更任何資料表的情況下提供簡單的測試方式。
一般來說，分布式交易都會在一個程式中使用 ODBC 或 DB-LIB API 來呼叫啟動或停止交易。分布式交易的程式設計和其它交易有一點不同的地方，就是當交易建立時必須聯機，並將自動認可選項關閉，以避免 SQL 陳述式自動認可交易。當應用程式結束在 COMMIT 或 ROLLBACK 其中一個指令時，MS DTC 便開始進行兩階段交易認可。
________________________________________
相關資訊
有關 SQL Server 應用程式開發，可參閱 Ron Soukup 和 Kalen Delaney 合著的《Inside Microsoft SQL Server 7.0》（Microsoft Press, 1999）；如果您使用的程式語言是 Microsoft Visual Basic，可參考 William Vaughn 所著的《Hitchhiker's Guide to Visual Basic and SQL Server》（Microsoft Press, 1998）。
________________________________________
管理 MS DTC
　
MS DTC 是 Windows 2000 的安裝選項。如果需要用到這個服務，只要再安裝時點選即可。有兩種啟動 MS DTC 的方式：使用 SQL 服務管理員或利用系統服務元件中的元件服務（本章稍早有介紹）。要開啟 SQL Server 服務管理員工具，點選 開始 → 程式集 → Microsoft SQL Server → 服務管理員 ，圖 25-9 為服務管理員工具。

　
 
圖25-9　使用 SQL Server 服務管理員開啟 MS DTC
在 服務 下拉式選單選取 MS DTC 。按下 開始／繼續 就可啟動此服務項目，按下 停止 即可終止服務項目。您可在左下方的複選框中選擇是否在開機時自動啟動服務。
監控 MS DTC
　
欲監控 MS DTC，必須使用元件服務管理主控台。啟動主控台（如本章之前所示範），展開 元件服務 → 電腦 → 我的電腦 → Distributed Transaction Coordinator ， 25-10 所示。

　
 
圖25-10　元件服務中的「Distributed Transaction Coordinator」
在這個資料夾中可以看到兩個選項： 異動清單 和 異動統計 。
異動清單
　
 異動清單 （ 25-11 所示）為所有正在系統內執行分布式交易的清單，檢視一筆交易的屬性，並可以強制執行交易的認可或放棄。操作方式為在 異動清單 中按一下滑鼠右鈕，由捷徑功能表中選出適合的選項。

　
 
圖25-11　「異動清單」顯示 MS DTC 交易
異動統計
　
 異動統計 （ 25-12 所示）可檢視分布式交易的資訊，如進行中的交易筆數、最大使用量等，提供進行中分布式交易的概觀，對未來容量的規劃也有協助。如您所見，分布式交易的監控、建立與執行並不困難。

　
 
圖25-12　「異動統計」顯示 MS DTC 交易
本章總結
　
在本章中，學到 MS DTC 的運作與分布式交易的建立，也對 Windows 2000 所提供的元件服務和技術有基本的概念，此外還學到管理部分的元件服務。以下幾章將學習 SQL Server 複寫。