[Tandem ENCOMPASS DDBMS]
ENCOMPASS 是一種同構型分布式數據庫管理系統，它是根據 Tandem 公司的 Non Stop 計算機體系結構和 GUARDIAN OS 建立起來的。計算機的體系結構和 OS 兩者都具有對實現分布式數據庫管理系統極其有用的特性。
1、 系統體系結構的綜述： Tandem 公司的計算機的最好的特性在於它是由幾個（至少兩個）獨立CPU組成，這些獨立的CPU利用高吞吐量總線連接起來，共享對磁盤驅動器的訪問。就典型的多處理機來講，Tandem 公司的計算機的不同特點在於每個CPU都擁有獨立的存儲器，與相同多處理機的兩個處理機相比，兩個CPU更類似兩個獨立的通信計算機。因此，我們把 Tandem公司的計算機的結構叫做多計算機結構，以便與典型的多處理機區分開。 在Tandem公司的計算機中，不僅CPU是重復的，而且所有其他部件也是重復的，尤其是磁盤驅動器和總線。由這種獨立資源重復所實現的目標之一，是在單個模塊出現故障時仍具有高可用性。 因為Tandem公司的計算機的基本體系結構是分布式的，所以Guardian操作系統能在由不同CPU執行的各進程之間提供方便的通信。各進程之間的所有通信都通過信息進行。信息系統可使硬件各單元的分布對進程是透明的。通過其信息和文件系統，Guardian OS 可使多計算機結構作為較高級軟件的單個計算機出現。 可以把幾個Tandem公司的計算機連接起來，以建立LAN。對支持一種NOS進行擴展是基於信息目的地的形式，以包括駐留在不同計算機上的個進程。重要的是，兩個進程之間的基本通信是相同的，不管它們是駐留在相同CPU、同一多計算機系統的兩個不同的CPU、LAN的兩個不同地點，還是駐留在MAN的兩個不同地點上，都是如此。但是，因為上面各種通信性能極不相同，所以臨界段功能必須能區分這些情況。然而，應用程序員可免於使用不同的機構。這取決於各進程對計算機的分布。事實上，基本系統的組織機構能夠提供分布式透明性。 根據這種計算機體系結構和OS，分布式數據庫管理系統能夠提供數據分布查詢處理和分布式事務處理的管理。
2、 數據分布： ENCOMPASS 支持水平段存儲的段存儲透明性。可以把全局關系水平地劃分成數量有限的段。但是，全局關系只能由主關鍵字的不同值來分段。為此，段存儲屬性（或至少它的一部分）必須加到主關鍵字裡。主關鍵字上的段存儲謂詞必須是簡單的：關鍵字數值集能夠分解成不相交的間隔，在相同間隔中所有具有主關鍵字值的元組都屬於相同的段。 用於水平段存儲的這種方法的優點是，能在必須插入元組的地點用局部過程控制主關鍵字的唯一性。若新的關鍵字值是局部唯一的，則它也是全局唯一的，因為它采用了段存儲的屬性。然而這種方法也有缺點，即全局模式必須要控制段存儲的各個方面，數據的邏輯模型受定義段存儲需求的影響。 所有文件具有唯一的名字，其中包括地點名字。當把文件分段時，一個文件名字指的是該文件的第一個段。 將要訪問的記錄的主關鍵字能使系統正確地控制對適當地點的請求。
3、 查詢處理： Tandem 公司提供了一種叫做ENFORM的關系查詢語言，它也擁有一次一個記錄的接口（因此可把ENFORM查詢嵌入到宿主語言中）。ENFORM不理解數據分布，它根據數據庫的主目錄來訪問數據庫，就像一個程序員可能不知道文件的段存儲一樣，它也不知道文件的段存儲。 知道數據位置的用戶可能影響用下面方法進行處理的情況。ENFORM由兩部分組成。前端從語法上分析查詢和對報告格式化，後端進行實際的數據庫訪問（選擇和投影）。用戶可把後端分配給駐留有大量所需要數據的地點，這與前端運行的地點無關。
4、 分布式事務處理的管理： 在 Tandem系統中，事務處理的計算結構是基於請求者服務器方法。請求者進程執行下面的功能：終端接口、字段合法性、數據映射和事務處理控制。終端接口處理各個終端所采用的協議。字段合法性用來控制輸入數據（字段的類型檢查和所要求字段的存在等）。數據映射功能涉及到把數據從外部形式變換成內部形式或內部形式變換成外部形式的變換。事務處理控制包括高級應用邏輯：輸入的解釋、執行用於數據庫控制的服務器進程的請求和與終端的交互作用。 服務器進程負責數據庫訪問和執行計算，它們按照請求的要求完成詳細的應用邏輯。在Tandem系統中，這種事務處理由一個請求者進程和兩個服務器合理地加以實現。兩個服務器進程能分別負責更新TO-ACCOUNT和FROM-ACCOUNT。 請求者是根主角，服務器是該事務處理的其它主角。由於一個服務器可以請求執行另一個服務器，因此應用的計算結構是分層結構。Tandem的請求者—服務器結構精確地規定了請求者—服務器進程的特性。
--> 請求者進程能負責： - 接收來自終端的事務處理激活和輸入參數； - 檢查輸入參數（檢查帳號，即數字量的有效性和檢查有無丟失參數）； - 為進行數據庫更新調用兩個服務器； - 在終端顯示出答案。
--> Tandem請求者—服務器結構的特性： - 請求者進程應該是多流進程； - 服務器總是單流的，在開始一個新功能前，它完全執行單個功能； - 服務器進程應是上下文無關的； - 服務器和請求者進程可駐留在網絡的不同地點上； - 相同的服務器進程可以為不同的請求執行其功能； - 請求者和服務器之間的通信是利用信息完成的。 [注意] 請求者和服務器進程的分配應該盡量使數據通信的費用降至最低。存在三種數據能在上面通信的層次：終端與請求者進程之間、請求者與服務器進程之間和服務器與數據庫之間。在大多數應用中，比較方便的做法是把請求者分配在終端地點上，把服務器分配在數據庫地點上，因為請求者和服務器之間的通信一般是極少的。 由於開發多流請求者進程對應用程序員來說非常艱巨，因此，Tandem提供一個事務處理系統（PATHWAY）。該系統可簡化請求者—服務器事務處理的開發與維護。PATHWAY包括標准的TCP（終端控制進程），程序員必須定義專門的高級事務處理邏輯，不必考慮系統有關方面和多流。實際上，應用程序員的主要任務是定義TCP和終端的交互作用。這是采用Screen-COBOL實現的。 分布式事務處理的原子性和可串化性是由Tandem事務處理監控設備（TMF）支持的。TMF把2階段鎖定用於並發控制。鎖定或在單個記錄級上獲得，或在文件級上獲得。一般只采用排它鎖定。 TMF 不提供任何死鎖檢測，要求應用程序員采用超時檢測死鎖。可把超時插入在兩個不同的層面上：請求者和服務器。在第一種情況時，當TCP把請求信息送給一個服務器時，設定超時參數。當超時終止時，若TCP沒有直接收到服務器的回答，則TCP能使事務處理異常終止。在第二種情況下，當服務器發送磁盤READ時設置超時。 TMF能實現2階段提交協議，但采用兩種不同的機構，以便在單個多計算機地點，或在多地點網絡體內實現這種協議。在單個地點內，TMF假定通信是很便宜的，因此，對所有處理器進行廣播，不考慮它們是否是事務處理的參與者。相反，對於多地點事務處理來講，TMF執行只包括事務處理的實際參與者的2階段提交。 TMF能處理地點鼓掌和網絡的劃分。若一個地點與協調程序失去聯系和等待事務處理的結果，則提供手動裝置來終止事務處理。在所有其它情況下，TMF能自動判定事務處理。若一直沒有實現提交的第二階段，則事務被異常終止。
-------------------- 時間永是流駛，BBS依舊不太平。
文章選項： lhl (Pooh-Bah) 04-01-17 23:48 [精華] Re: 分布式數據庫系統概覽-[SDD-1 DDBMS 研究] [re: lhl]
[SDD-1 DDBMS 研究]
美國計算機公司（Computer Corporation of America）研制的 SDD-1 項目是第一個分布式數據庫管理系統的樣機。它是在1976年到1978年間設計的，並於1979年在DEC-10和DEC-20兩個型號的計算機上實現。各地點由ARPANET連接，並采用叫做數據計算機的當前DBMS。這個項目特別有助於理解分布式數據庫的重要問題和對其中某些問題的解決方法。
[SDD-1 DDBMS 研究（一）：體系結構]
SDD-1支持關系數據模型。全局關系能以兩個步驟分段（首先水平分段，然後垂直分段），能以冗余方式存儲各段。SDD-1能提供段存儲透明性（用戶不知道段和段的分配）利用數據語言，即適用於數據計算機的高級過程語言實現關系控制。 SDD-1的體系結構是基於三個相對獨立的虛擬機：數據模塊、事務處理模塊和可靠的網絡。這種體系結構允許把分布式數據庫管理問題分成三個系統，以限制相互的影響。
1、 數據模塊（DM）：管理局部數據。它們為事務處理模塊提供以下特征： - 把局部數據庫中的數據讀進分配給每個事務處理的局部工作區； - 在不同地點的工作區之間傳送數據； - 處理工作區的數據； - 把工作區的數據寫進局部數據庫。
2、 事務處理模塊（TM）：計劃和控制事務處理的執行。每個數據語言命令被看作是一個單個事務處理。TM負責： - 查詢變換和訪問計劃； - 並發控制； - 分布式查詢執行的控制。
3、 可靠的網絡（RelNet）：把TM與DM互連起來，以提供以下特征： - 保證發送（即使在發送器和接收器從未同時處於正常工作狀態，也能保證信息的傳送）； - 事務處理控制（以保證事務處理的原子性）； - 地點監控（以指明在一給定時間間隔內各地點是處於正常工作狀態還是發生了故障）； - 全局網絡時鐘（在所有地點上粗略地進行同步）。 同樣，SDD-1中的事務處理的執行是基於能使事務處理管理問題各不相同和在不同階段設解決問題的原理。事務處理的執行分成三個階段：讀、執行和寫。每個階段涉及一個單獨的問題：讀階段涉及並發控制，執行階段涉及分布式查詢的執行，寫階段涉及在已經修改過的數據的所有副本上執行更新。 在事務處理的讀階段，事務處理要讀的段（叫讀集合）由初始地點上的TM確定，TM起管理程序的作用，選擇讀集合各段物理副本的非冗余集合，叫實現。然後，把一個命令送給存儲實現某個部分的所有DM，以便把所需要的數據放入規定給該事務處理的工作區。在這個階段，要管理所有並發控制要求。采用不同的文件機構實現工作區，這樣就不必立即把數據從磁盤復制到工作區。進一步講，指明所需頁面的物理位置的頁面映射與事務處理有關；其它事務處理不能修改這些頁面，因為如果其它事務處理想修改它們，則它必須要分配新的物理存儲器，並把更新過的頁面寫入到新的物理存儲器中。 在執行階段，采用編譯並執行的編譯數據語言，以形成訪問計劃，然後立即執行。執行由初始地點上的TM進行控制。這樣SDD-1就擁有包括不同地點上的一個主TM和幾個DM的集中式計算。在該階段，所有的功能都在事務處理的局部工作區上完成。 在寫階段，把在一個DM上為每個修改過的段生成的更新分布到存在該段副本的所有DM上，然後把寫命令發送到所有相關的DM（這樣，副本利用寫方法編寫）。事務處理的原子性由一個專用的4階段提交協議來保證，即使有關的地點發生故障，該提交協議也允許事務處理的提交。這個協議采用RelNet的保證傳遞機構。
[SDD-1 DDBMS 研究（二）：並發控制（讀階段）]
SDD -1中的並發控制采用具有“忽略已廢棄的寫”規則的保守時標法。它允許在接收到寫命令後，立即對它們進行處理，並在讀階段實施全部並發控制的輔助操作。為了滿足正確執行保守時標方法的要求，DM以同一事務處理的名義自動進行所有讀（寫）動作（在事務處理開始時進行所有讀，在事務處理結束時進行所有寫）。包括在事務處理中的、從TM到DM的兩個信息規定要檢索的數據（在讀階段），執行事務處理之後，規定要進行的更新（在寫階段）。此外，TM按照時標次序發送由它們控制的事務處理的讀請求。在SDD-1中，已經為事先識別出事務處理不是沖突的和利用這種知識研究出一些專門的技術。 在設計事務處理時，應建立事務處理級別的靜態集。通過對事務處理指定讀集和寫集來定義事務處理的級別。不同級別的讀集和寫集可以重疊。當兩個級別中的任一個的寫集或者與另一個級別的讀集或寫集的交非空時，就說兩個級別發生了沖突。實際上，允許兩個沖突級別只在其讀集中具有非空的交。 若一個事務處理的讀集包括在C的讀集內，其寫集包括在C的寫集內，則說該事務處理適用於所給定的級別C。因此，相同的事務處理可以適用於一個以上的級別。級別的一個相當明顯的應用在於，若其級別不沖突，則兩個事務處理就不可能沖突。因此，並發控制機構中的級別的內部知識對避免等待是有用的。 為了實現這點，把每個級別分配給一個特殊的 TM，每個TM都只定位在一個地點上。當把一個事務處理提交給一個指定的TM時，可分析其讀集和寫集，並確定它適用的一個級別。若這個級別不是由局部TM 管理的，則把該事務處理送給具有能管理適當級別的TM的地點。每個事務處理必須至少適用於一個級別。 相同級別內的事務處理一定會發生沖突，因此要按照嚴格的時標次序執行事務處理。“流水線”規則規定可以處理讀和寫信息的次序，控制每一級別發生讀和寫請求的TM遵循流水線規則。我們可以認為這種規則在相同級別中采用了嚴格的事務處理串行化。 非沖突級別不需要串行化，尤其是在考慮到符合C級別的事務處理T時，若遠程地點的所有級別都不在與C沖突，則在發生T操作之前不需要等待來自那個地點操作。然而，通過更復雜的分析（沖突分析圖），采用級別概念能帶來很大的好處。 沖突圖是級別間沖突的綜合表示法。每個級別由兩個論點，r—Read，w—write進行設計，r和w表示該級別的讀集和寫集。一個邊連接相同級別的各結點。當兩個不同級別的兩個集相交時，除讀集之間的相交之外，在響應結點之間劃出一個邊。 沖突的重要特性是在它們中間存在循環。不要把沖突圖與串行圖混淆，其非循環性並不意味著兩種事務處理可按任意次序執行。然而，在一些參考文獻中表明，與非循環沖突圖相比，循環沖突圖要求更特殊的機構。這樣，沖突圖類型的級別化必然導致開發出各種不同的並發控制協議，每種協議只供一種沖突圖使用。這些並發控制協議多少要求一些限制。 用於具有非循環圖的各級別的協議： P1、P2&P3（用於具有循環圖的級別）、P4（用於不適用任一級別的那些非預期的事務處理）。 根據確定預期的非沖突事務處理的目標來分析沖突圖：沖突圖分析的主要缺點是要靜態地、而不是動態地評價各沖突。
[SDD-1 DDBMS 研究（三）：查詢的執行（執行階段）]
原貼此節是一個word附件，我未做修改(我的openoffice玩不轉它)，只是用gzip壓了一下，在此下載：
http://www.linuxforum.net/forum/files/470240-query.doc.gz
執行：gunzip 470240-query.doc.gz即可得到原貼的word附件。
[SDD-1 DDBMS 研究（四）：可靠性和事務處理提交（寫階段）]
SDD-1中的可靠性由RelNet虛擬機提供。該機器具有以下的分層軟件體系結構： 事務處理控制層 保證傳遞層 全局時間層（全局狀態、全局時鐘、局部狀態和局部時鐘） ARPANET消息傳輸層
在最高層上，事務處理控制層能保護事務處理原子性和實現事務處理提交。此層建立在保證傳遞層的頂上，這能保證即使在傳輸時接收器出了故障，或者接收器從故障狀態恢復正常工作時發送器出了故障，最終也能接收到標記著“保證傳遞”的專門消息。 全局時間層能提供如下功能： - 全局時鐘（在不同地點上施加一種一致的和均勻的次序） - 把網絡的所有地點描述成“正常工作的”或“出故障的”可能性和監控這兩種狀態之間轉換的可能性，叫故障恢復（就全局時鐘而言，故障恢復是瞬間的）。 RelNet的最低層建立在ARPANET的消息傳輸層上，它至少能保證： - 若接收到從地點1向地點2發送的任意兩個消息，則以發送這兩個消息相同的次序接收這兩個消息。 - 若在任意兩個消息傳遞之間沒有發生故障，則兩個傳輸之間沒有來自發送器的其它消息。 若網絡不能提供這些特性，則會出現災難性故障，同時系統的狀態是無法預測的。此外，SDD-1把網絡劃分看作是災難性故障，因為RelNet不能管理劃分。這種限制是由於網絡劃分在ARPANET上是相當靠不住的這一事實來證明的，這要在各地點之間擁有幾種選擇連接。 顯然，RelNet不能提供100%的可靠性，它采用的方法能為其每一層指明導致災難性故障類型。這樣，就能確定災難性故障的界限，通過在各相應層增加副本能使災難性故障的可能性降低到最小。
1、 全局時間層：本層所提供的主要特征之一是全局時鐘。全局時鐘根據下面的規則建立時間次序： --> 同一進程內的事件按其執行次序安排 --> 若在執行時間2之前，一個進程知道不同進程的時間1，則事件1必須安排在事件2之前。
局部時鐘子層：這是最低層。它在每個地點上均保存一個邏輯局部時鐘。它只是一個單調遞增的計數器，用來產生分配給事務處理和消息的時標。本層還支持實時時鐘。實時時鐘由超時機構采用，同時還用來使邏輯時鐘“大致上”與實時時鐘同步。為了獲得這種同步，兩個時鐘的時間間隔采用不同粒度，以便為實時時鐘給出粗調器粒度。當實時時鐘通過邏輯時鐘時，邏輯時鐘就被“沖擊”到實時時鐘之外。
局部狀態子層：本層所完成的主要操作是管理局部狀態表。該表能按照“正常工作的”或“出故障的”給出所有網絡地點的狀態。這層根據來自較高層的命令負責把狀態標記成“正常工作的”或“出故障的”。RelNet還能提供把監視員設定在給定地點上的可能性，等待那一地點恢復的進程能設定監視員。當這個時間發生時，能通過中斷通知這個進程。局部狀態層負責產生該中斷。 兩個專門的消息在各地點之間進行交換，以通知狀態和狀態變化： - I am up （消息由正恢復的地點發送） - You are down （消息從一個地點傳送到另一個地點，以便在那個地點上強制實現局部恢復）
全局時鐘子層：本層負責向較高層提供一致的全局時鐘。這種全局時鐘能監視相對時間，而不是絕對時間，這種功能“幾乎”全由局部時鐘層提供。但是，存在這樣一種情況：一個地點沒有接收到另一個地點的任何消息時，就知道該地點的事件。當一個地點觀察到另一個地點的故障時，就會發生這種情況。已經指定了叫作管理員的專門進程，以便用比遠程故障地點時鐘的值大得多的值調整局部時鐘。 為了揭示其故障，管理員監視其它地點的進程。為每個地點配備了幾個管理員。管理員定期請求確認送到控制地點的消息。若確認在給定的超時內沒有到達，則認為該控制地點出了故障。向該地點發送一個預先約定好的消息，以便強制執行局部恢復；當控制地點上實際是正常工作時，這個消息有效。 當管理員檢測控制地點的故障時，為了保證新局部時間大於遠程地點的故障時間，它“沖擊出”局部時鐘足夠的間隔。為了保證這種特性，管理員應在給定時間間隔內重復控制。 當一給定地點的所有管理員都失效，同時那一地點出現故障時，全局時間層就面臨著災難。該災難由全局時間層的不精確性構成。通過增加每個地點上的管理員數量就可以使這種災難性事件發生的可能性減到最少。
全局狀態子層：協調由它下邊的子層所提供的各種功能，並把網絡視圖提供給具有下面特性的較高層： - 所有地點均標記成“正常工作的”或“出故障的”（這種狀態之間的變換瞬間發生） - 提供全局時間 本層負責標記地點狀態，處理有關地點狀態，並在指定的地點向用戶進程提供監視。他還負責把已經完成局部恢復的地點恢復到正常工作狀態，這是利用下面步驟實現的： - 向所有其它地點發送預先約定的消息（I am up.） - 接收來自這些地點的時標應答（允許適當地調整局部時間和狀態） - 向所有沒有響應的地點發送預先約定的消息（You are down.） - 最後將局部狀態調整為“正常工作的”
2、 保證傳遞層： SDD-1中的消息可被標記為“保證傳遞”，這可保證最終能接收到這些消息。RelNet的保證傳遞層能提供這種特性。請注意，所有傳遞的信息都按發送它們的相同次序到達，與標記無關；然而，非保證傳遞消息可能丟失。 RelNet 通過把有故障地點的消息存入所謂可靠的緩沖寄存器中來實現這種結果。每個地點都有這麼一個緩沖寄存器。采用分布式在幾個地點上的幾個物理緩沖寄存器能構成可靠的緩沖寄存器，叫做假脫機器。當一個消息標記有“保證傳遞”、接收器地點出故障時，這個層的責任就是把消息分布到地點的假脫機器中。當該消息安全地存儲在這些假脫機器中時，即使該消息還未到達目的地，也可以對發送進程發送確認消息。實際上，可確保目標目的地地點在恢復過程中能以對於所有其它“保證傳遞”消息的適當的次序，評價存儲在假脫機器中的信息。 為了交換“保證傳遞”消息，我草擬了發送器、接收器和假脫機器地點所采用的算法（我沒有涉及假脫機器的故障管理和可能的消息“間隔”）。發送器、接收器和假脫機器的地點可以處在兩種狀態：目的地故障期間的假脫機狀態和正常情況下的非假脫機狀態。 - 非假脫機狀態時的發送器能正常地發送消息，但是若其中一個消息在給定的超時內未被確認，則發送器請求全局時鐘層，把這個接收器看作是出了故障的接收器，給假脫機器發送一個“開始假脫機過程”消息，並進入假脫機狀態。 - 假脫機狀態時的發送器將其消息發送給所有假脫機器，並等待其確認。當接收到來自假脫機器的“停止假脫機”消息時，該發送器進入非假脫機狀態。 - 假脫機狀態時的接收器確認正常收到的消息。故障之後或已經接收到一個 “you are down” 消息之後，該接收器進入假脫機狀態。在其重新啟動期間，假脫機狀態的接收器選擇其假脫機器中的一個，並通過請求假脫機消息使它為空。當已經評價了所有消息時，接收器從該假脫機器接收到“停止假脫機”消息，同時該接收器變換到不同的假脫機器。為了避免兩次處理相同的消息，最初要求根據每個假脫機器請求消息時標清單。 - 非假脫機狀態時的假脫機器能向所有輸入消息回答“停止假脫機”，唯有“開始假脫機”消息除外，這能使假脫機器進入其它狀態。 - 非假脫機狀態時的假脫機器能接收來自發送器的消息，這通常能確認該消息，並能接收來自接收器的消息請求。當接收到這個消息時，存儲在緩沖存儲器中的下一個消息被送入接收器。當傳遞得到確認時，從緩沖寄存器中刪除這個消息。當緩沖寄存器為空時，假脫機器進入非假脫機狀態。 當標記有“保證傳遞”的消息丟失時，這一層上出現災難性故障。當目的地和所有假脫機器同時出故障時，會發生這種情況：若每個地點都有適當數量的假脫機器，則能使這種災難性故障發生的可能性任意小。
3、 事務處理控制層：提供RelNet的較高層特征 - 獲得新的事務處理標識符的能力，在事務處理執行的讀階段開始時需要這種能力。 - 產生事務處理的參加者進程（或主角）的能力。當提交事務處理或事務處理被異常終止時，它們就會失效。 - 具有保證事務處理原子性的能力。這要求具有或者在所有地點提交事務處理，或者在所有地點上異常終止事務處理的能力。 為了提供第三種特征，已經把2階段提交用於SDD-1環境。直接利用2階段提交會導致供協調者使用下面的協議： - 階段1a：協調者向參加者發送標記有“保證傳遞”的更新消息 - 階段1b：協調者等待對保證傳遞消息的確認 - 階段2a：協調者發送標記有“保證傳遞”的決定 - 階段2b：協調者等待對保證者傳遞消息的確認 即使參加者在提交時不是“正常工作的”，保證傳遞特征也允許提交事務處理：它只要求把更新消息安全地存儲在假脫機器中。這樣，在2階段提交期間，上面的機構對參加者的事故不敏感。然而，對協調者故障是很敏感的。 為了處理協調者故障，可采用備用進程。這些進程在啟動提交協議之前由協調者產生，並在協調者出故障時代替協調者。為了保證只有一個進程能代替協調者，把備用進程線性地排序，以便第一個進程檢查協調者，第二個進程檢查第一個進程，依次類推。若一個備用進程出了故障（如備用進程 k），則備用進程 k+1 啟動。檢查備用進程 k-1：備用進程 k 決不會再包括在事務處理中。這種情況下的檢查意味著定期發送控制消息（類似管理員）。 包括備用進程的提交協議由四個階段構成： - 階段1a：協調者建立n個線性排序的備用進程，每個進程均知道參加者的標識。 - 階段1b：協調者接收到存在備用進程的確認。 - 階段2a：協調者向參加者發送標記有“保證傳遞”的更新消息。 - 階段2b：協調者等待對保證傳遞消息的確認。 - 階段3a：協調者將其決定通知給備用進程。 - 階段3b：協調者等待來自備用進程的確認，並把給定超時內沒有響應的那些地點看作是出了故障。 - 階段4a：協調者把其標記有“保證傳遞”的決定發給參加者。 - 階段4b：協調者等待對保證傳遞消息的確認，然後它使備用進程失效。 當備用進程代替協調，或代替另一個充當協調者的備用進程時，它或者已經接收到決定，或者做出異常終止決定。通過把該決定通知其它備用進程和等待確認，來完成該協議的第三階段。即使新的協調者證實了前一個協調者決定，這也是需要的。因為新的協調者不知道先前的協調者是否已經把這個決定通知給備用進程。然後，新的協調者執行上述協議的第四階段。 若利用這個協議，當協調者做出故障時，用事務處理的任一備用進程的非可用性表示災難。像其它情況時一樣，這也可能使這種災難發生的可能性任意小。
[SDD-1 DDBMS 研究（五）：總結]
SDD -1一直是分布式數據庫管理方面的一個大型項目，並且驗證了許多新技術，並第一次應用了許多設想（如：段存儲、連接、並發控制的時標、假脫機器和備用協調者等）。SDD-1的整個體系結構在各模塊和半各層次中具有清楚的分解編譯。然而，SDD-1系統的性能不佳。其某些特征似乎比較差： - 並發控制是保守的，並且不是無死鎖的，真實環境中的沖突圖分析的價值一直沒有得到證實。 - 把數據模塊和數據語言作為局部DBMS和DML會在查詢處理中引進某些限制，這些限制在完全關系型系統中是不必要的。 - 可靠性系統不能支持網絡劃分。
[IBM R* 系統研究]
R* 系統是在美國 CA 州的 IBM San Jose Research Laboratory 開發的。它的目的是建立由協同操作，但卻是獨立的地點構成的分布式數據庫系統。每個地點支持一個關系數據庫系統。R* 是 R 系統向分布式環境的自然擴展。 在 R* 系統中，數據以關系形式存儲。就地理概念上講，不必要求各地點相距遙遠，不同的地點可能處在同一台計算機上。這一點不僅對於開發和測試數據庫應用來說被認為是最重要的，而且對於操作系統來說，也被認為是最重要的。在這種設想中，就安全、記帳或性能諸原因來說，能夠把不同的R* 模塊放置在相同的計算機上。 R* 系統最重要的目標是提供地點自主權。當每個地點既能控制由另一個地點上對其數據的訪問，也能在不受任何其它地點限制的條件下處理自己的數據時，也就實現了地點自主權。R* 系統完全實現了第一個目標。但它僅僅是部分地實現了第二個目標，因為在事務處理的2階段提交期間，不可避免地要損失地點自主權。 地點自主權還要求在新的地點與現有的地點連接時，該系統能夠逐漸增加和連續操作，並不要求現有地點與要連接的地點就全局數據結構或定義達成一致意見。 R* 系統的另一個重要問題是位置透明性（用戶並不知道數據的實際位置）。這樣，從程序員的觀點來看，使用R* 系統與使用集中式系統基本一樣。由於分布而引起的對 SQL 語言的有關擴展如下： - 命名：對每個目標來講，R* 系統的“系統范圍”名稱包括下面的規范 @ @ 這種命名模式包括每個目標的生成地點，它是一種靜態特性，但不包括該目標的實際位置，它可能不時地發生變化。同義詞和缺席用來簡化這種命名模式。 - 在兩個地點之間移動目標的可能性（目標遷移）。 雖然在R* 系統中引入的附加語言特性極少，但R* 系統的主要成就是在分布式環境中提供了SQL/DS 的大多數功能。
[IBM R* 系統研究（一）：R* 系統的體系結構]
R* 系統由3個主要部分組成：局部DBMS、提供信息傳輸的數據通信部分和能協調實現多地點事務處理的事務處理管理程序。局部DBMS可進一步分為兩個部分：存儲系統（用於數據的存儲與檢索），數據庫語言處理器（用於將高級SQL語句轉換成存儲系統上適用的操作命令）。R* 方案中采用的存儲系統叫RSS*，是以系統R的存儲系統為基礎。 R* 各地點通過CICS的系統間通信（ISC）設備進行通信。每一個R* 地點都在一個CICS地址空間運行，而CICS控制終端I/O和信息通信。假定該通信是不可靠的（不能保證所傳輸的信息總能送到），但可以假定所送到的信息是正確的、不重復的，並以與發送它們的相同次序接收。 一個應用程序在其局部地點執行所有對R* 系統的數據庫訪問請求。所有地點間的通信均在不同地點的R* 系統之間進行。因為是R*、而不是應用程序負責為分布式數據定位。這樣，在R* 環境中不需要遠程應用程序。 應用地點的事務處理管理程序，把未包括在明確定義的事務處理中的第一個SQL語句看作是事務處理的開始，隱含地執行一個開始——事務處理。當用戶完成一次會話後，就假定一個隱含的結束——事務處理，並提交所有已經完成的工作。 當應用程序員想使事務處理程序把幾個SQL查詢看作是一個原子單元時，則可以用顯式提交和異常終止命令把這幾個SQL語句封閉起來。在任一顯式提交或異常終止命令之後，R* 能假設下一個語句開始新的工作單元，並隱含地發出一個開始——事務處理。 也可以使用UFI（便於用戶使用的接口）來起用R*，這時，把SQL語句逐個地從UFI提交給R*，並把每個語句看作是一個單獨的事務處理。 對於每一個事務處理來講，事務處理管理程序能分配一個唯一的事務處理標識符（由局部事務處理計數器和地點標識符構成）。 根據支持預定應用的重復執行，由R* 的計算模型負責。可以預料，多個SQL語句能由同樣的應用程序發出，因此也可以預料到，用戶與R*的會話可能持續較長時間。這樣，建立能用於若干數據庫訪問請求的計算結構，以及在所有有關地點保留分布式應用狀態信息都是很方便的。 R* 采用計算的“進程”模型。不是為每個數據庫訪問請求分配一個不同的進程，而是為遠程地點的第一個請求的用戶生成一個進程，並一直保留到該應用結束為止。這樣，分配給一個應用的進程數量是有限的，生成進程的費用就會減少。用戶識別只在生成進程時執行一次，同時把那一特殊應用所要求的所有訪問計劃裝入到進程存儲器中。 遠程地點上激活的進程可依次請求激活另一個地點上的進程。一般來講，R* 中的計算可能要求產生同屬於相同應用的進程樹。屬於相同應用的多個進程可以在同一地點上同時執行。這與上面敘述的在遠程地點為第一個請求生成一個進程、並一直保持到該應用的結束這一點並不矛盾。只是在同一應用的兩個不同進程要求時，才會在同一地點為同一應用生成兩個進程。為了在相同地點上以相同事務處理的名義，並發執行幾個進程所引起的問題可通過嚴格地使其訪問串行化加以避免。 當生成遠程進程和在整個處理期間保持不變時，進程利用所建立的會話進行通信。這樣，進程和會話為應用構成一種穩定的計算結構。R* 的會話以半雙工方式工作，由進程中的一個進程來控制信息流。在已經利用會話發出請求之後，請求方既可以等待響應；也可以繼續進行會話。在後一種情況下，它可以利用不同的會話向不同的進程發出另一個請求，這樣就啟動了並行計算。 會話對於檢測處理器和通信故障是特別有用的。利用低層協議（確認和超時）向通信進程報告通信故障。當兩個進程間的會話出故障時，就異常終止現行的事務處理。不能夠與父通信的進程也會使與其子女通信的會話失效，而其它會話則為後面的嘗試保持下去，以繼續進行具有不同訪問策略的應用。 兩種附加的通信方式能用在R* 中。為了暫停數據的傳輸，信號可以與會話一道從接收器送到發送器；這對接收器對接收附加信息不再感興趣時是有用的。 信息也可以利用數據報協議發送。數據報能在接收器地點生成一個進程，該接收器地點上運行一個程序來處理該進程。數據報用於死鎖檢測和事務處理恢復。事實上這些功能是由R* 連續不斷地完成的，因此信息丟失問題可通過下一個周期上直接重復信息傳輸加以解決。
[IBM R* 系統研究（二）：查詢的編譯、執行和重新編譯]
在 R* 系統中，SQL查詢既可以靜態地進行編譯（n 個執行編譯一次），也可以動態地進行編譯（在單個執行前立即進行編譯）。前一種情況用於重復查詢，後一種情況用於預先不知道的查詢。在R* 方案中，重復查詢的重要性比預先不知道的查詢高得多。在這兩種情況下，非過程型SQL語句被轉換成訪問計劃，該計劃規定訪問關系的次序進行訪問的地點，完成每一個操作的方法及在RSS* 中檢索或處理元組的訪問路由。 對每一個高級SQL語句來說，查詢編譯符合低級程序的生成和分布，以便訪問 RSS*。這些程序能夠重復執行，只是當SQL語句使用的數據定義發生變化時，才需要重新編譯。為了能檢測出是否需要重新編譯，需要存儲有關數據定義的編譯查詢的相關性信息。若解釋一個查詢，則對查詢的每次執行訪問計劃。 在R* 設計中，曾考慮了幾種選擇方案，以確定哪個地點應負責對查詢進行編譯。一個地點負責所有編譯的集中式解決方案顯然使人不能接受（因為這與地點自主權的基本概念相違背）；只在提供查詢的地點進行編譯也是不可接受的（因為這需要維護其它地點的自主權，而那些地點必須能夠拒絕訪問計劃訪問它們自己的數據）。 每個地點利用“遞歸”編譯方法執行一部分查詢編譯，然後請求其它地點編譯剩余的子查詢。這種方法的缺點是在執行編譯的各地點之間需要進行協商。不同的地點能產生用於執行同一查詢的不同計劃，因為它們沒有統一的目錄信息。（例如，考慮一下能用兩種不同的訪問計劃回答的一個查詢，並假設每個地點都確信最佳訪問計劃是包含其它地點的。在這種情況下，每個地點為進行編譯多半可能向其它地點發送該查詢，這樣就確定了一個無窮縮環。） 為R* 選擇的解決方法是：指定提供查詢的地點負責查詢的“全局”編譯，該地點叫師傅地點。全局計劃規定了操作次序和為完成這些操作應該使用的方法。參與編譯的其它地點叫徒弟地點，它們接收與它們有關的部分全局計劃，並選擇出與全局計劃一致的訪問它們自己的局部數據的最佳計劃。
——> 師傅地點上的查詢編譯包括： - 對查詢進行語法分析（包括SQL語句的語法檢查和名字的分解）。 - 訪問目錄信息：若查詢所使用的數據是局部存儲的，則目錄信息也是局部的。反之，目錄信息或者能從遠程數據的局部超高速緩沖寄存器，或者能從存儲數據的各地點上的遠程目錄檢索到。通過在數據的出生地點查找目錄，可以知道這些地點的標識。 目錄包括關系的提問檔和適用的訪問路由信息。師傅地點把編譯所用的目錄項目的版本號連同在第四步中產生的訪問計劃分配給徒弟地點，各徒弟地點在自己的地點檢查目錄項目的版本號，以確保用於制定全局計劃的目錄信息與局部目錄信息一致。 - 特許檢查：在局部關系上執行（師傅地點 ——> 土地地點），用於確定編譯查詢的用戶是否擁有相應的訪問權限。 - 訪問計劃的制定（查詢優化）：R* 的優化程序研究了為生成全局計劃由查詢所需要的 I/O、CPU 和信息量，而不是將數據傳輸所需要的信息量減到最少。 - 計劃分布：把完整的全局計劃分布給所有的徒弟地點。全局訪問計劃規定了操作次序和執行這些操作所采用的方法以及對用於局部操作的一些建議，但徒弟地點可以遵守，也可以不遵守這些規定。它還包括原始的SQL語句（帶有經過分解的系統范圍名字）、目錄信息，以及在執行該查詢時各地點之間要交換的各種參數的規范。 - 局部裝配：把在師傅地點上執行的計劃部分使用的名字裝配到那一地點的內部目標名字中。 - 計劃存儲與相關性：把師傅地點的局部計劃轉換成一個“局部訪問模塊”，這要在RSS* 的局部范例中執行。把該計劃與有關的“相關性”一起存儲起來，相關性能指出該計劃所采用的關系和訪問方法。當這些數據變得無法利用時（如刪除一個由訪問模塊所采用的關系），就違反了相關性，執行被終止。 徒弟地點接收該計劃屬於它們的部分，其中包括下列信息： 1、 原始SQL語句 2、 由師傅地點為它們准備的全局計劃（它們根據該全局計劃把屬於它們的部分隔離出來） 3、 師傅地點所采用的目錄信息 [注意]師傅地點把描述一個子查詢的高級SQL語句裝配到徒弟地點中，而不是向它們發送由語法分析程序產生的某些內部表示法。這種選擇的基本原理在於將來每個徒弟地點能存儲一個不同的局部優化程序版本。此外，傳遞一個高級語言語句能給出更高的獨立性和可移植性。
——> 每個徒弟地點能執行以下步驟： - 語法分析 - 目錄查找（在自己地點上） - 特權檢查 - 局部訪問優化（對於修改師傅對涉及徒弟地點的各操作所做的某個錯誤決定是很有用的） 可以采用不同的訪問方法（如不同的索引），或為局部連接采用不同的連接方法。最後，把局部名字連接在一起，並把計劃和獨立性存儲起來。 當相同的應用程序的所有SQL語句已經由所有徒弟地點編譯完時，師傅地點要求事務處理管理程序提交該編譯，把該編譯看作為一個原子單元。2階段提交協議用來確保或編譯在所有地點上是成功的，或在所有地點上均失效。
執行：在執行時，檢索和執行先前送到徒弟地點的各計劃。師傅地點發送各“執行”請求，並依次把各“執行”請求送到其從屬地點。這樣，就激活了進程樹。每個中級進程接收來自從屬地點的結果數據，裝配成字組，只要接收到第一個結果，它就能開始其自己的執行，同時把結果立即送到更高級進程。這樣，實現了流水線操作。一個信號由樹中的特權者采用，以停止從從屬地點傳輸結果。
重新編譯：在執行時，測試目錄中的旗幟，以確定訪問模塊是否有效。這個旗幟在成功地完成編譯之後調整成有效，但在它所依靠的數據定義變化時變得無效。實際上，數據定義中的任一變化都會引起對記錄相關性的目錄進行搜索，以便找出取決於目標的訪問方法。 若發現該旗幟無效，則需要重新編譯。首先嘗試進行局部重新編譯，即數據定義在其上已經變化的地點試著利用局部可用的數據結構重新編譯其局部檢查部分。即使按全局觀點看這個新版本可能不是最佳的，局部重新編譯也似乎要比重復整個應用的全局編譯劃算。 然而在某些情況下，全局重新編譯是必須的（如：當數據已經轉移到一個不同的地點時）。若局部重新編譯不可能進行時，則重新編譯整個語句，由提供應用的地點作為師傅地點。
[IBM R* 系統研究（三）：視圖管理]
在 SQL/DS中，視圖被定義為SQL選擇語句的結果，由一個或多個操作數關系產生一個結果關系。該結果關系為用戶提供一個數據庫的新“視圖”（或ANSI -SPARC術語中的“外部模式”），這要通過標准查詢語言來建立。視圖是特許的客體，實際上視圖一般用於為用戶提供訪問所選擇的信息的能力，以代替完全的關系。 視圖取決於定義它的SQL語句中采用的客體的存在；很清楚，若一個視圖訪問刪除的數據，則該視圖必須是無效的。因此，視圖與實際關系的相關性也必須存儲起來。視圖一般用於只讀訪問，因為不是總能根據為關系加下線來確定視圖更新的影響。 在R* 中，可以利用對視圖定義地點不是局部的關系來定義視圖。因此，視圖管理也是分布式的。在R* 術語中，無相應特許特性的視圖叫做簡寫視圖，主要為各用戶提供一個較為方便的接口。用於提供特許的視圖叫做保護視圖。 分布引進了確定視圖定義和相關性應該存儲在哪兒和如何存儲的附加問題，以及訪問視圖的查詢應該如何進行編譯問題。在R* 中，視圖定義存儲在對視圖進行說明的地點上，視圖相關性存儲在視圖定義中所使用的實際數據存儲的各地點上，也就是所謂的視圖連接地點。後一種選擇與地點自主權一致，因為視圖的有效性能夠由局部操作校驗，同時也是有效的，因為采用該視圖的程序要求無論如何也要訪問連接地點。作為兩種選擇的結果，視圖定義和刪改是分布式操作。 視圖定義包括一個師傅地點（視圖在其上提交的地點）和幾個徒弟地點（視圖連接地點）。師傅地點執行查詢編譯中的一般步驟：語法分析、名字分解和目錄查找。當視圖訪問其定義中的另一個視圖時，執行遞歸視圖，以產生其中僅出現真實關系的組合定義（不是視圖）。之後，把視圖定義請求傳播給該視圖的所有連接地點，這時，檢查與師傅地點的目錄信息的一致性，然後存儲相關性。 由於一個視圖的定義是一個SQL語句，因此在提交時，或者所有連接地點與師傅地點意見一致，則提交該定義；或者其中某些與師傅地點的意見不相符，拒絕該定義。在目前的視圖實現中，沒有對提供視圖定義的用戶的特許進行有效性驗證，但是當采用視圖時，即訪問視圖的查詢被編譯時，對連接地點上的實際關系上執行特許權檢查。 如果SQL語句是個現有的關系，則它能使用視圖。在查詢的師傅地點上，SQL語句利用視圖定義語句加以組合，以產生能在實際數據上操作的單個SQL查詢。但要注意，這種變換類似於“規范變換”。在該“規范變換”中，把工作在虛擬客體上的表達式編譯成工作在物理客體上的表達式。 刪除視圖定義所依據的關系具有使運行在該視圖上的程序失效的作用，也可以使視圖定義本身失效。然而，這可由采用該視圖的第一個應用發現。應使視圖在該視圖定義地點重新編譯全局視圖。如果這種重新編譯出了故障，則通知所有連接地點刪除該視圖。
[IBM R* 系統研究（四）：R* 中數據定義協議與特許協議]
在 R* 中，需要編譯各個查詢，因為預計這些查詢可能要重復執行。然而，同樣的假設對數據定義、布局和SQL的特許語句沒有意義。因此，要對這些語句加以解釋。這些語句能工作在遠程地點的客體上。此外，客體能從一個地點移到另一個地點，以便為執行每個語句要求一個以上的遠程訪問。為了便於解釋這些語句，已經設計出專門的協議，采用公用基本結構。 經過解釋的語句一般分為兩類：
1、 靜態處理語句（SOPS）：包括只訪問靜態實體的語句，即其位置不發生變化（用戶、程序、地點）。利用 SOPS，能夠從語句本身導出執行地點。 2、 動態處理語句（DOPS）：包括能訪問動態實體的語句，即這些位置會變化（如關系和視圖）。利用 DOPS，能在其上執行語句的各地點預先是不知道的。
與兩種類型語句有關的協議擁有相同的基本結構。利用遠程過程調用機構可以把執行從一個地點遷向另一個地點。每個語句被編程為一個單獨的過程。該單獨過程或者在局部地點執行其功能，或者能請求在不同地點上執行。當一個過程說：“我希望在地點 x 上執行。”時，分布式遞歸調用過程通過把用戶識別和語句本身送給 x 地點來實現。采用這種方法，就可以在地點 x 上啟動遠程語句的執行。在這個執行期間，為了請求在不同地點 y 上執行，也可以采用相同的機構。很清楚，一個過程能請求在地點 x 上執行，因為它要求訪問處在地點 x 上的數據。動態確定“下一個”要訪問的地點 x 的可能性允許有效地編譯 DOPS 語句。 這種方法能夠提供以下幾個優點： - 根據將要執行的功能，不是根據數據分布規定各過程； - 保持地點自主權，因為每個請求以高級語句形式分布，每個地點能單獨作出有關請求的決定。
分布式遞歸過程的模式如下： 1、 完成語句的語法分析和局部用戶識別； 2、 確定必須在其上進行工作的地點； 3、 就必須在其上進行工作的地點 x 來說，或者 x 是現有地點，局部完成該工作，或者 x 是遠程地點，利用在那一地點上遞歸地發出一個遠程過程調用來完成工作。 該方法的第三步按順序進行，僅一個進程在給定時間上執行。遠程過程調用同步地進行，調用過程在該調用本身上暫停執行，並只在完成遠程進程時才繼續其執行來實現遠程過程調用的同步。也曾考慮過利用異步過程調用把相同請求廣播給幾個遠程地點的可能性，這樣就使得遠程地點可以並行方式工作，但沒有實現這種方案。實際上，並不認為執行這些非重復語句的效率是極重要的。
[IBM R* 系統研究（五）：事務處理管理]
R* 系統中事務處理是執行的一個原子的可持續的單元。它是由一個或多個 SQL 語句構成，SQL 語句封閉在一個 begin-transaction 和一個 end-transaction 中。給事務處理規定了唯一的事務處理標識符，由該事務處理所要求的地點標識符和順序號碼構成。並發控制由2階段鎖定機構提供，事務處理握有其鎖定，直到提交或異常終止以提供隔離特性。如我在前面的帖子裡提到的那樣，能夠完成分布式死鎖檢測。當探測到死鎖時，由異常終止等待循環內事務處理的一個來消除死鎖（一般異常終止只完成了極少工作的那個事務處理）。 在R* 系統中，利用標准2階段提交協議的變形提交事務處理。設計這些變形的目的是在信息交換方面和運行記錄上所要求的操作方面，改進標准的2階段提交協議的性能。在敘述這些協議時，我們把術語“force a log”（人工轉移一個運行記錄）用於把運行記錄復制到穩定存儲器的操作，采用術語“write a log”（寫一個運行記錄）用於把運行記錄寫入虛擬存儲器的操作。最終虛擬存儲器連接到穩定存儲器。當把記錄人工轉移到運行記錄中時，局部恢復機構肯定會知道該記錄。當只編寫該記錄時，在把記錄復制到穩定存儲器之前，系統事故可能導致運行記錄信息丟失。 標准2階段提交的變形，這種協議能夠引起地點自主權的丟失，這種丟失是不能消除的。實際上，在進入准備好狀態之前，任何一個地點都能在任一時間異常終止一個事務處理，這樣就保持了該地點對協調程序的自主權。然而，當一個參加者進入准備好狀態時，它就不再允許異常終止事務處理。因此，事務處理的資源由協調程序“查封”，並且對該參加者不再有效，直到該協調程序送出一個包含其決定的信息為止。這種丟失地點自主權不能消除，因為它是提供事務處理原子性所要求的。
1、 假定異常終止協議： 在 “假設的異常終止”算法中，當恢復機構沒有事務處理的信息時，恢復機構就假設該事務處理已經被異常終止。如果這種推理由恢復機構一致地執行，則能設計一種 2階段提交算法。在這種算法中，協調程序能比在標准2階段提交模式中更早地忘掉所異常終止的事務處理。實際上，當協調程序接收到否定應答並作出異常終止該事務處理的決定時，它能向所有的參與者廣播該異常終止信息，在無需強制的情況下把全局異常終止記錄寫入運行記錄中，然後忘掉該事務處理。 這樣恢復機構將能從協調程序地點上的運行記錄推理出該異常終止，運行記錄中或者包含全局異常終止記錄，或者根本就沒有可用的信息。注意，這種方法允許編寫全局異常終止記錄，而不是人工轉移這些全局異常終止記錄。同樣，參與者只是把提交記錄人工轉移到運行記錄中，並把異常終止記錄寫入運行記錄中。 假設異常終止協議的另一個特性，與發現該提交的某些參與者實際上是只讀子事務處理的可能性有關。當一個參與者不進行任何編寫時，它就不需要記入記錄，並能釋放鎖定和在已經送出其肯定決定之後，立即忘掉該事務處理。實際上，它不需要知道該事務處理最終是否能提交或異常終止。 如果所有的參與者均是只讀事務處理，則協調程序不需要進入該提交的第二階段。它人工轉移一個提交記錄，釋放其鎖定，並忘掉事務處理。當部分參與者是只讀事務處理，部分參與者要求更新時，只是進入准備好的狀態的參與者是要求更新的參與者。
2、 假定的提交協議： 假設的提交協議對假設的異常終止協議是孿生的，因為該提交協議是采用這樣一種方法研究出來的，即在這種方法裡，對在師傅地點上恢復進程的“no information”等效於一個提交。這種孿生性導致研究一種方法，用這種方法異常終止必須予以確認，而提交不需要確認。然而，這種方法不是即刻正確的：在已經送出准備信息之後，但在已經編寫全局提交記錄之前，協調程序的事故可能導致一種情況，在這種情況中，協調程序恢復可能取消該事務處理和異常終止，而參與者可能找到“no information”和提交。這通過把記錄人工轉移到協調程序的運行記錄中加以避免，這不是假設的異常終止協議所要求的。准備記錄是存儲參與者的標識。這樣，當協調程序地點上恢復機構發現上面談到的故障狀態時，它能把異常終止通知各參與者。必須確認這種通知，只是在接收所有確認信息之後，才利用恢復機構人工轉移全局終止記錄。在這種提交協議中，編寫提交記錄，並只把異常終止記錄人工轉移進運行環境中。 注意，即使事務處理可能原是只讀事務處理，協調程序也需要把一個記錄人工轉移進具有所有參與者標識的運行記錄中。
3、 假設異常終止和假設提交的比較： 對於參與者來說，假設提交協議要比假設異常終止有效得多。假設提交協議能成功地完成更新事務處理，因為它不需要確認和提交記錄的人工轉移。另一方面，對於成功地進行只讀事務處理的參與者來講，假設異常終止協議更有效些，因為帶有參與者信息的附加記錄不需要人工轉移進協調程序的運行記錄中。在R* 中，能夠為每個單獨的事務處理選擇協議。假設的異常終止是為假定是只讀事務處理的事務處理提出的，假設的提交是為所有其它事務處理提出的。
[IBM R* 系統研究（六）：終端管理]
在 R* 方案中，為了允許單個終端用戶與多個計算交互作用，有一種分布式終端管理（DTM）設備，能在不同地點上執行。利用這種設備，用戶能看到由多個進程產生的輸出，或為多個進程產生輸入。一般來說，或者通過把劃分終端顯示和把分段分配給每個計算，或者通過多路轉換顯示和在不同計算之間轉換來開發終端管理系統。 DTM 屬於後一種范疇。 終端操作員和計算之間的交互作用被認為是一種順序數據流。實際上，DTM 能采用更先進的顯示特性。DTM 命令前綴一個專用字符“%”，該字符能把 DTM 命令與其它輸入區別開。為了接收來自用戶的輸入和為用戶產生輸出，把每個進程連接到一個邏輯終端上。幾個進程很可能共享相同的邏輯終端。命令 %CONNECT 用來把一個物理終端分配給現有計算的邏輯終端，或者用於啟動一個新的計算。 從與相同邏輯終端有關的多進程來的各輸出線進入一個輸出流緩沖器（OSB）。從不同進程來的線由進程標識符標記（或者更簡單地以不同顏色標記）。由同一計算來的輸出線以適合的次序產生，從不同計算來的輸出線可以交織。 當分配給同一邏輯終端的各進程要求輸入時，這種輸入必須是時分多路轉換的。命令 %SWITCH 適用於用戶循環通過正在進行競爭的進程。當單個進程一度請求輸入時，不需要采用 %SWITCH（比如當計算由同步過程調用構成時）。 邏輯上把一個物理終端搭接到一個遠程地點是可能的，利用命令 %PASSTHRU 在那一地點上開始一個計算也是可能的。這時可執行注冊與識別，允許通過幾個層次，利用 %QUIT 命令終止通過。
[IBM R* 系統研究（七）：總結]
我在這裡介紹的 R* 樣機的各種特性均是操作特性（包括 SQL 的控制語句和數據定義、事務處理的管理、死鎖探測及恢復機構）。盡管 R* 是一種研究樣機，但是它是采用系統的和有效的方式開發出來的，利用了用於事務處理管理的大部分成熟技術（2階段鎖定和2階段提交）。這個原型機可以看作是開發先進系統的重要基礎。
[八十年代中期 IBM 內部系統通信研究]
適用於 IBM 計算機的各種軟件產品，包括數據庫管理系統和事務處理的處理器，與由具有 ENCOMPASS DBS 的 Tandem 計算機網絡提供的嚴格同構型環境相比，為分布式數據庫設計人員規定了更加復雜的環境。IBM 已經開發出和正在開發多種工具，它們有助於在同構型和異構型局部系統上面建立分布式數據庫。這些最重要的工具是 SNA 和 ISC。 SAN 包括用於建立 IBM 計算機和終端及處理其專用特性的通信軟件。支持不同地點上各進程之間的邏輯會話和各程序之間的通信協議。 IRC 是允許符合它們要求的各種系統相互通信的協議集合。用於 CICS 事務處理的處理器和 IMS DBMS 的 ISC 協議很早就實現了。
[八十年代中期 IBM 內部系統通信研究（一）：CICS/ISC]
CICS 是所謂的 TP —— 監控器或事務處理的處理器，它的主要功能是控制執行由各種終端上的終端用戶請求的聯機應用。當用戶輸入應用代碼時，CICS 激活相應的應用程序。因此，CICS 執行與操作系統調度程序相同的功能。
用 CICS 代替基本操作系統的理由是： 1、CICS 允許定義終端的構造，可由終端請求應用的代碼，必須執行的相應應用程序，應用的訪問權和相似結構的參數。 2、 CICS 能夠比通用操作系統更有效地控制事務處理的執行。典型的聯機應用遠不同於可用計算機完成的其它形式的功能，它們要求極短的計算，它們受到 I/O 的強烈約束，它們必須具有短的響應時間。CICS 把這些應用的特性知識用於更有效的調度和更有效的資源分配，以便與以前由通用操作系統控制的各種應用相比，在同一系統上能並行運行更多的應用。
CICS 應用能由一個或幾個事務處理構成。當啟用應用時，隱蓄地執行開始事務處理。應用程序可以規定一個同步點。該同步點相當於執行一個提交基元，後面緊跟著一個新的開始事務處理基元。CICS 保留一個支持事務處理原子性的運行記錄。 CICS 不是一個 DBMS，其功能便於執行終端上各用戶請求時的應用程序和管理系統資源。但是，由 CICS 控制的應用程序通常是數據庫訪問程序。因此，應用程序可以用類似 IMS 的 DBMS。在事務處理器和 DBMS 之間存在一個強有力的綜合。CI/ISC 把 IMS 基元從一個地點傳送到一個目標地點也是可能的，在這種情況下，假設在目標地點 IMS DBA 能說明它，因為 CICS 不能直接說明任何數據庫訪問基元。 由於 CICS 管理在不同 DBMS 控制下訪問數據庫的應用，因此 CICS/ISC 可以用來建立異構型分布式數據庫。可以用 CICS 執行的兩個 IBM DBA 是 IMS 和 SQL/DS。CICS 應用也能調用其它能運行在 IBM 計算機、但不是 IBM 產品的 DBMS，如 Cullinane 公司的 IDMS 和 Applied Data Research 公司的 DATACOM/DB。然而，采用這些產品建立異構型數據庫，要比只采用 IMS 和 SQL 建立異構型數據庫困難得多。 IMS 是引導 DBA，基本上是一次一個記錄的 DBMS。此外它具有執行事務處理的控制（數據通信部件 IMS/DC）的部分，甚至也有多 IMS 耦合特性（MSC）。然而，當運行在 CICS 上時，只采用 IMS 數據管理部件（IMS/DB 或 IMS/DLI）。 SQL/DS 是一種采用 SQL 語言的關系 DBMS，它不僅可以由終端用戶作為查詢語言使用，也可以由程序員用來編寫聯機應用。在後一種情況時，含有對 SQL/DS 的調用的應用程序可在 CICS 監控器的控制下運行。 CICS/ISC 不僅僅是一個允許兩個系統通信的工具，也是向開發包括幾種不同軟件部件的綜合數據管理環境邁進了一步。
[八十年代中期 IBM 內部系統通信研究（二）：功能發送]
功能發送由把單個數據訪問基元送到遠程地點構成。如果地點1上的事務處理要求來自地點2上文件的數據，則可用功能發送實現。如果把在地點2上存放的文件指定給 CICS/ISC，則該操作能以對程序是透明的方式進行。程序發出對文件的請求，CICS/ISC 負責識別是否存在地點上，把該請求發送到地點2，控制其執行，接收返回的結果和把結果送給程序，就像已經局部地執行了該請求。因此 CICS/ISC 對由一個程序發出的數據訪問基元實現了完全的位置透明性。假設 DBMS IMS/DL1 用於數據庫訪問，則 CICS/ISC 能實現遠程地點上 DL1 基元的執行。
地點1上事務處理 A 發出的 DL1 基元和要求對地點2上 IMS 數據庫進行訪問的實現，由 CICS/ISC 按順序執行以下步驟： - 從通信網絡軟件 VTAM 獲得會話（SNA 部件），與地點2上的 CICS 通信。 - 把 DL1 基元送到地點2上的 CICS 系統。 - 地點2上的 CICS 系統生成用於處理請求的專門事務處理。CICS 為執行遠程請求所建立的這些事務處理叫鏡像事務處理。 - 像地點2的任一其它事務處理一樣，鏡像事務處理由地點2上的系統來執行。鏡像事務處理體包括執行局部的 IMS 系統上的 DL1 基元。 - 送回結果。如果鏡像事務處理沒有進行任何更新，則將其刪除，並終止會話。如果鏡像事務處理進行了更新，則該會話必須保持直到提交點（在 CICS 裡叫同步點）為止，以便允許恢復和保持文件的完整性。
在資源利用和各個事務處理的響應時間方面功能發送的效率是相當低的。這是因為會話和鏡像事務處理的建立要求類似單個文件訪問的較小操作。經驗已經證明，局部文件訪問要求十分之一毫秒級別的時間，而通過功能發送的遠程文件訪問可能要求幾百毫秒、甚至幾秒級別的時間。因此，功能發送應該局限於幾種情況。如果要求許多遠程文件的訪問，則應該采用異步事務處理或分布式事務處理。然而在某些情況下，功能發送和這些方法相比所具有的優點使得我們不得不采用它：在遠程地點上不需要應用程序，因而可由這種操作方式提供位置透明性。
[八十年代中期 IBM 內部系統通信研究（三）：異步事務處理]
采用異步事務處理，局部事務處理在遠程地點上啟動一個指定的事務處理，對於其啟動者來說，它以異步方式進行工作，傳送請求要求會話；然而，一旦所規定的事務處理被啟動，該會話就立刻停止。然後兩個事務處理獨立地繼續進行。 遠程事務處理也能激活其它事務處理。最常見的是它能激活起始地點上的第三個事務處理，以顯示出最終結果。 如果必須在遠程地點單獨實現幾種功能，並且完整性不是主要的，則異步事務處理是方便的。這種工作方式要比功能發送更有效，因為它需要比發送一個請求大致相同的資源（即建立相當短時間的會話）。但這些資源的費用可通過執行整個遠程事務處理來補償，這一般包括一個以上的單個文件訪問。 采用這種方法的主要問題是分布式事務處理的原子性不是由系統保證的，因此應用程序中必須包括所需要的恢復過程。若要求分布式處理的原子性，則應該用分布式事務處理的處理過程來代替異步事務處理的處理過程。
[八十年代中期 IBM 內部系統通信研究（四）：分布式事務處理]
如果采用分布式事務處理，局部事務處理啟動一個遠程事務處理，就像采用異步事務處理那樣。然而，起始事務處理要等到被啟動的事務處理已經完成了所需要的功能時為止。在整個協作過程中，要保持兩個事務處理的同步進行和會話。當兩個事務處理合作時，能在會話時交換幾種信息。 這種操作方式能保證分布式事務處理的原子性。有關異步事務處理的主用費用是會話費用，這也適用於事務處理執行的整個時間。 分布式事務處理的主要缺點是不能提供位置透明性，因為應用程序在請求激活事務處理時，它必須指明該遠程事務處理所駐留的地點。
[八十年代中期 IBM 內部系統通信研究（五）：比較]
三種方法中的每一種方法都有優點和缺點。下表根據位置透明性、事務處理的原子性、響應的時間和資源消耗幾個方面評價了這三種方法。
位置透明性 事務處理的原子性 響應時間 資源耗費 功能發送 1 1 3 3 異步事務處理 2 3 2 1 分布式事務處理 3 1 1 2
1、位置透明性最好是采用功能發送，因為應用程序只簡單地發出數據庫訪問基元，無須知道數據存在哪裡。這時，通過簡單地改變文件位置定義可以很方便地管理文件遷移，不會影響應用程序。異步事務處理允許一個應用程序啟動另一個程序的執行而無須知道它的位置，因此與分布式事務處理相比，異步事務處理的等級較高。 2、 功能發送和分布式事務處理兩者能支持事務處理的原子性，因此在這方面它們比異步事務處理的等級高些，異步事務處理不能提供原子性。 3、 要求幾個遠程數據庫訪問的事務處理響應時間最好采用分布式事務處理，最不適合采用功能發送。如果分布式事務處理需要在兩個地點之間進行幾次交換信息，則異步事務處理的響應時間大大劣於分布式事務處理的響應時間，因為采用分布式事務處理，可以把同一會話用於這一目的。 4、 采用異步事務處理時資源耗費是最少的，采用功能發送時資源耗費是最大的。
上面的比較表明，三種方法中，沒有哪一種方法在所有方面和所有應用環境中能占主導地位，或一種方法被另一種方法所取代。因此，所有三種方法都可能存在下去，盡管這三種方法的某些特性取決於專用系統的特性。
[八十年代中期 IBM 內部系統通信研究（六）：總結]
考慮不僅取決於 Tandem 公司的 ENCOMPASS 和 IBM 公司的 CICS/ISC，而且也取決於下面幾種系統： - ADR（Applied Data Research）公司的 D-NET 系統 - Cullinane 公司的 IDMS-DDS 系統 - ICL（International Computer Limited）公司的 IDMS-DDB50 系統 - Nixdorf Computer AG 公司的 VDN 系統 - Siemens AG 公司的 UDS-D 系統 - Software AG 公司的 NET-WORK 系統 其中某些產品仍在研制中，還未公開。所有產品都正在迅速變化著。我們不可能比較它們的特性，只能把它們作為現有產品樣機加以介紹。 除了 VDN 之外，所有這些系統都是作為擴展先前存在的集中式 DBMS 開發的，即作為局部 DBMS。在某些情況下，必須對以前的 DBMS 進行廣泛地改造。在 VDN 的情況下，局部和分布式系統要一起進行設計。IDMS-DDS、IDMS-DDB50 和 UDS-D 局部系統是 Codasyl、IDMS 和 UDS 系統。D-NET 和 NET-WORK 的局部系統是 DATACOM/DB 和 ADABAS，它們屬於帶有反向表的關系系統類。VDN 的局部系統介於 Codasyl 和關系型系統之間。
分布式透明性：所考慮的所有系統都能提供某種程度的分布式透明性。比如，Tandem 公司的 ENCOMPASS 能提供文件的透明水平段存儲，IBM 公司的 CICS/ISC 能為遠程文件訪問提供位置透明性。這兩種系統都不采用數據字典來獲得位置透明性。像 IDMS-DDS 和 D-NET 這樣的系統卻以數據字典為中心。在這些系統中，通過采用描述數據字典中的數據庫分布所需要的所有信息來獲得位置透明性。 分布單位：大多數系統的分布基本單位是文件，只有 VDN 和 ENCOMPASS 允許把文件劃分成幾個較小的單位。Codasyl 系統對把邏輯單元映射到各地點有附加限制。比如，在 IDMS-DDB50 中，每個 Codasyl 集合必須完整地存放在一個地點上。 數據復制：只有 D-NET、VDN 和 NET-WORK 三個系統支持數據復制。在 D-NET 中，文件可以復制，但是只能對主文件進行一致的更新。事務處理可使用其它副本來進行“髒”讀出，而無須要求一致性。在 NET-WORK 中，文件各副本既可以像在 D-NET 中那樣采用，也可以迫使它們一致。VDN 允許段的復制，段也可以重疊。 遠程數據庫訪問：訪問遠程文件的可能性由幾個計算機網絡提供，與數據管理系統的存在無關。采用 CICS/ISC 能在進行執行遠程 IMS/DL1 基元（功能發送）。這種方法的主要缺點是大多數文件和數據庫訪問基元只能訪問極少的數據，以致於不能補償建立進程間通信的費用。改進這種解決方法的一種方式是建立功能更強的基元，這種基元可利用遠程 DBA 進行解釋。比如，基於引導 Codasyl 數據庫管理系統 IDMS 的 IDMS-DDS，因為單個記錄請求對有效遠程數據庫訪問來說太小而受到損害。通過采用 IDMS 的 LRF（邏輯記錄設備），可以增加地點到地點的通信效率。LRF 可以把幾個數據記錄（或其中的一部分）定義為單個邏輯記錄。因為應用程序的每個請求都能檢索邏輯記錄，所以單個遠程調用能檢索幾個物理記錄。 遠程進程到進程通信：這種設備是開發分布式數據庫系統的基礎，它可由大多數同構型計算機網絡提供。對於異構型網絡來說，這種要求可能更苛刻，但可以支持不同 DBMS 之間的進程到進程通信。比如，SNA 和 ISC 兩者都能支持遠程進程到進程通信。 分布式事務處理的恢復：幾種系統已經能支持2階段提交，分布式事務處理的恢復協議能夠用在聲稱能管理分布式數據庫的所有系統中。就復制問題和並發控制的耐久性問題而論，這種狀態似乎更重要。