[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阶段提交，分布式事务处理的恢复协议能够用在声称能管理分布式数据库的所有系统中。就复制问题和并发控制的耐久性问题而论，这种状态似乎更重要。