CN1829988A - 无共享数据库系统中的单相提交 - Google Patents

Abstract

本发明提供了用于在无共享数据库系统中处理分布式事务的技术，其中，一个或多个节点能够访问共享的永久存储器。分布式事务的协调器使用单相提交协议，而不使用双相提交协议来协调分布式事务，该单相提交协议具有能够访问由协调器保持的事务状况信息的那些参与者。事务状况信息可以驻留在例如协调器的重做日志中。在协调器故障的情况下，那些参与者可以基于存储在共享磁盘上的信息来确定分布式事务的状态。此外，协调器可以基于由参与者存储在共享磁盘上的信息来确定是否可能提交分布式事务，而不用那些参与者进入正式的“准备好的”状态。

Description

无共享数据库系统中的单相提交

技术领域

本发明涉及用于管理在共享磁盘硬件上运行的无共享(shared-nothing)数据库系统中的数据的技术。

背景技术

多处理计算机系统一般分为三类：一切资源共享(shared-everything)系统、共享磁盘系统、以及无共享系统。在一切资源共享系统中，所有处理器上的程序能够直接访问系统中的所有易失存储装置(下文中一般称为“存储器”)以及所有非易失存储装置(下文中一般称为“磁盘”)。因此，要求不同的计算机组件之间的高级布线，以提供一切资源共享的功能。另外，就一切资源共享结构而言还存在可扩缩性限制。

在共享磁盘系统中，处理器和存储器被分组成节点。共享磁盘系统中的每个节点本身可以构成包括多处理器和多存储器的一切资源共享系统。所有处理器上的程序能够访问系统中的所有磁盘，但是只有属于特定节点的处理器上的程序能够直接访问在特定节点内的存储器。共享磁盘系统通常需要少于一切资源共享系统的布线。因为所有节点能够访问所有数据，所以共享磁盘系统还能够容易地适应不平衡的工作负荷条件。然而，共享磁盘系统易受相关开销(coherence overhead)的影响。例如，如果第一节点已经修改了数据并且第二节点想要读取或者修改该相同的数据，则必须采取多个步骤以确保将数据的正确版本提供给第二节点。

在无共享系统中，所有的处理器、存储器、和磁盘被分组成节点。如同在共享磁盘系统中一样，在无共享系统中，每个节点本身可以构成一切资源共享系统或共享磁盘系统。只有在特定节点上运行的程序才能够直接访问特定节点内的存储器和磁盘。在三种一般类型的多处理系统中，无共享系统通常需要最少量的各种系统组件之间的布线。然而，无共享系统最易受不平衡的工作负荷条件的影响。例如，在特定任务期间被访问的所有数据可能都驻留在特定节点的磁盘上。因此，只有在该节点内运行的程序可以用于执行工作区组(work granule)，即使其他节点上的程序都保持空闲状态。

在多节点系统上运行的数据库一般分为两类：共享磁盘数据库和无共享数据库。

共享磁盘数据库

共享磁盘数据库基于以下的假设来协调工作：假设由数据库系统管理的所有数据对于数据库系统可用的所有处理节点而言都可见。因此，在共享磁盘数据库中，服务器可以向任何节点上的程序分配任何工作，而与包含在工作期间将被访问的数据的磁盘的位置无关。

因为所有节点都能够访问相同的数据，并且每个节点都具有其自己的专用高速缓存，所以相同数据项的多个版本可以驻留在任意数量的多个节点的高速缓存中。遗憾的是，这意味着当一个节点需要特定数据项的特定版本时，该节点必须与其他节点相协调以使数据项的特定版本被传送至请求节点。因而，共享磁盘数据库被认为以“数据传送”的原理运行，其中，数据必须被传送到已经被指定处理该数据的节点。

这样的数据传送请求可能导致“查验(ping)”。特别地，当由一个节点所需的数据项的拷贝驻留在另一节点的高速缓存中时，就会出现查验。查验可能要求将数据项写入磁盘，然后从磁盘读取。查验所必需的磁盘操作的性能能够显著地降低数据库系统的性能。

共享磁盘数据库既可以在无共享计算机系统上运行，也可以在共享磁盘计算机系统上运行。为了在无共享计算机系统上运行共享磁盘数据库，可以将软件支持程序(software support)添加到操作系统或者可以提供其它硬件以允许程序能够访问远程磁盘。

无共享数据库

无共享数据库假设程序只能在数据被包含在与程序属于相同节点的磁盘上时访问该数据。因此，如果特定节点想要对由另一节点所拥有的数据项执行操作，则特定节点必须向另一节点发送请求，请求另一节点执行该操作。因而，无共享数据库被认为执行“功能传送”，而不是在节点之间传送数据。

因为任何给定的数据块都仅由一个节点拥有，因此只有这一个节点(数据的“所有者”)将永久在其高速缓存中具有数据的拷贝。因此，无需在共享磁盘数据库系统中所要求的高速缓存相关性机制类型。另外，由于不要求拥有数据项的节点将数据项的高速缓存版本保存到磁盘以使另一节点然后能够将该数据项存入其高速缓存，因此无共享系统不遭受与查验相关的性能损失。

无共享数据库可以在共享磁盘多处理系统和无共享多处理系统上运行。为了在共享磁盘机器上运行无共享数据库，可以提供一种机制用于对数据库进行分区(partitioning)，并且将每个分区的所有权分配给特定节点。

只有有所有权的节点可以对数据块进行操作的事实意味着无共享数据库中的工作负荷可能变得极度不平衡。例如，在十个节点的系统中，所有工作请求的90％可能涉及由节点中的一个所拥有的数据。因此，该一个节点工作过度，而其他节点的计算资源未被充分使用。为了“重新平衡”工作负荷，可以使无共享数据库脱机，并且数据(及其所有权)可以在节点之间被再分配。然而，该过程涉及移动可能地大量数据，并且可能仅仅临时解决工作负荷的失衡。

在无共享数据库系统中的分布式事务

分布式事务可以指定对驻留在无共享数据库系统中的不同节点上的数据项的更新。例如，分布式事务可指定对由第一无共享节点拥有的第一数据块的更新，以及对由第二无共享节点拥有的第二数据块的更新。拥有在分布式事务中涉及的数据的节点在此称为“参与”节点或简单地称为“参与者”。

为了保持数据的一致性，分布式事务必须被提交，或在发生错误的情况下，“回滚(roll back)”。当事务被提交时，由该事务指定的对数据的所有改变变为永久的。另一方面，当事务被回滚时，已经做出的由事务指定的对数据的所有改变被取消或撤消，如同从未对数据做出改变。因此，使数据库处于反映在事务中指定的所有改变或不反映在事务中指定的改变的状态。

双相提交

一种用于确保在分布式事务期间的数据一致性的方法涉及使用双相提交协议来处理分布式事务。例如，在标题为“Performing2-Phase Commit With Delayed Forget”的美国专利第6,493,726号中，详细地描述了双相提交。通常，双相提交需要首先“准备”事务，然后提交。在准备好的相位之前，在每个参与无共享节点进行由事务指定的改变。当参与节点完成了所有请求操作时，该参与节点将改变和“准备”记录强加给永久存储器。随后，参与者向协调器报告参与者处于“准备好的”状态。如果所有的参与者成功地进入准备好的状态，那么协调器将提交记录强加给永久存储器。另一方面，如果在准备好的状态之前发生任何错误，指示参与节点中的至少一个不能做出由事务指定的改变，那么取消在每个参与节点的所有改变，将每个参与数据库系统恢复到其改变之前的状态。

图1示出了多节点无共享数据库系统，用于更加详细地说明与用于执行双相提交的传统方法相关的成本。多节点数据库系统100包括协调节点110和参与节点150。协调节点110接收来自数据库客户120的对数据的请求，该数据库客户包括客户122和客户124。这种请求可以是例如SQL语句的形式。

协调节点110包括日志，例如日志112。日志112用于记录对数据库系统做出的修改，以及影响这些修改的状况的事件，例如提交。日志112包括多种日志记录。当第一次创建这些日志记录时，它们最初被存储在易失存储器中，并且不久被永久地存储到非易失存储器(例如，诸如磁盘的非易失存储器)。一旦日志记录被写入非易失存储器，就将由日志记录指定的修改和其它事件称为“永久的”。修改和事件是“永久的”，这是因为在重新进行修改和事件以将数据库恢复成其失败之前的状态失败之后，如果发生系统故障则可以使用永久存储的日志记录。

图2是示出了根据用于执行双相提交的传统方法的协调器和参与者之间的交互作用的流程图。使用多节点数据库系统100作为实例来说明事务状态。事务状态201是事务在协调数据库系统(即，协调节点110)中进行的事务状态，以及事务状态202是事务在参与数据库系统(即，参与节点150)中进行的事务状态。

参照图2，待用状态210、240、250、280表示事务的待用状态。在待用状态中，不存在由需要任何进一步行动(例如，诸如数据块的执行操作所需要的资源的提交、取消、锁定、或解锁)的事务指定的数据库操作。事务最初处于待用状态(即，待用状态210和250)，并且在完成时事务返回到待用状态(即，待用状态240和280)。

当数据库系统接收到“开始事务”的请求时，事务从待用状态转变成活动状态。例如，客户122(图1)可以将BEGINTRANSACTION请求发布给协调节点110。可选地，“开始事务”命令可以是隐含的。例如，数据库服务器可以在接收到指定操作或改变的语句时开始活动的事务。在步骤212，协调节点110接收开始事务请求并且进入活动状态220。接下来，协调节点110接收修改参与节点150上的数据的命令。相应地，在步骤221，协调节点110向参与节点150传输请求以开始事务。在步骤222，协调节点110向参与节点150传输一个或多个请求以修改在参与节点150上的数据。

在步骤252，参与节点150接收开始事务的请求。关于参与节点150，事务进入活动状态260。然后，参与节点150接收修改数据的请求。

一旦数据库系统中的事务进入活动状态，则数据库系统可接收修改数据的任何数量的请求作为事务的一部分。例如，客户122可以向协调节点110发布请求以修改在协调节点110和参与节点150上的数据。响应于接收修改在参与节点150上的数据的请求，协调节点110向参与节点150传输修改在参与节点150上的数据的请求。

在步骤223，协调数据库系统接收来自客户122的提交事务的请求。相应地，在步骤224，协调节点110将准备请求传输到参与节点150。在步骤262，参与节点150接收该请求。

在步骤264，参与节点150将日志152(图1)写入(flush)非易失存储器。“写入日志”指的是使当前仅存储在易失存储器中的日志的日志记录存储到非易失存储器。因此，写入日志使得对参与节点150的修改变为永久。当修改变为永久时，参与节点150可保证其可以提交该事务中它的部分。因此，在步骤264之后，事务进入准备好的状态。在步骤266，参与节点150将到准备好的状态的转变记录在日志152中(即，将记录已经达到准备好的状态的事实的日志记录存储在磁盘上)。

在步骤272，参与节点150将准备好的确认(acknowledgment)传输到协调节点110。准备好的确认是由参与数据库系统发送的消息，其指示参与数据库系统是否准备提交该事务。当在参与数据库系统上事务处于准备好的状态时，参与数据库系统准备提交。在步骤226，协调节点110接收准备好的确认。

在步骤228，协调节点110提交并且写入日志112。特别地，协调节点110在日志112中创建日志记录以记录该提交。当协调节点110写入日志时，其使得该提交是永久的。当提交是永久时，事务处于已提交状态。因此，在写入日志之后，协调节点110转变为已提交状态230。

在事务达到已提交状态之后，在步骤232，协调节点110将遗忘请求传输到参与协调节点110。接下来，参与节点150遗忘该事务。遗忘请求是发送到参与数据库系统的消息，其请求参与数据库系统执行遗忘处理。“遗忘处理”通常指的是将事务从准备好或已提交状态转变为待用状态所需的附加操作(即，提交事务、释放资源、以及使事务为待用)。

在步骤274，参与节点150接收遗忘请求。在步骤276，参与数据库系统提交(包括创建日志记录以记录该提交)，并随后写入日志152。在此阶段，在参与节点150上事务进入待用状态。在步骤282，参与节点150释放在由参与节点150以事务的名义锁定的资源上的任何剩余锁定。在步骤284，参与节点150将遗忘确认传输到协调节点110。遗忘确认是由参与节点发送的消息，其确认遗忘处理在参与节点上完成。

在步骤234，协调节点110接收确认遗忘处理完成的消息。在步骤236，协调节点110可以删除由协调器以事务的名义保持的状态信息。这种状态信息可包括，例如，在分布式事务中的参与者的列表。在此阶段，在协调节点110上事务进入待用状态。

可以通过归因于执行双相提交的传输的消息和日志写入的数量，来测量双相提交的每个事务成本。由于有四个消息(即，步骤221、步骤232、步骤272、以及步骤284)归因于双相提交，因此在消息方面的每个事务成本为4N，其中，N等于参与节点的数量。由于用于协调节点的一个日志写入(即，步骤228)和用于每个参与节点的两个日志写入均归因于双相提交，因此在日志写入方面的成本为2N+1，其中，N是参与节点的数量。

基于以上描述，显然希望提供用于减少完成涉及多个无共享节点的事务所需的消息、信号交换、以及日志写入的数量的技术。

附图说明

通过附图中的实例来描述本发明，但是不局限于此，在附图中相同的附图标号表示相似的元件，其中：

图1是多节点数据库系统的框图；

图2是示出了在传统双相提交协议中涉及的步骤的流程图；

图3是示出了根据本发明的实施例的协调器和内部参与者之间的交互作用的流程图；以及

图4是可以实施本发明的实施例的计算机系统的框图。

具体实施方式

下文中描述了用于提高包括共享磁盘存储系统的无共享数据库系统的性能的各种技术。在下面的描述中，为了解释的目的，描述了多个特定的细节，以对本发明有彻底的了解。然而，很显然，在没有这些特定细节的情况下，也可以实现本发明。在其它的实例中，以框图形式示出已知的结构和设备，以避免不必要地使本发明不清楚。

功能概述

下文中描述了用于提高无共享数据库系统的性能的各种技术，其中，运行无共享数据库系统的节点中的至少两个节点能够共享地访问磁盘。正如由数据库系统的无共享结构所确定的，在任何给定的时间，每个数据块仍然仅由一个节点拥有。然而，利用运行无共享数据库系统的节点中的至少一些节点能够共享地访问磁盘这一事实，可以更有效地执行分布式事务。特别地，访问包括协调器处理的重做日志(redo log)的共享磁盘的这些参与者使用单相提交协议，而不是通过双相提交协议来确保分布式事务的一致性。

重做日志

当作为事务的一部分，数据库服务器更新易失存储器中的数据项时，数据库服务器生成包括关于更新的信息的重做记录。在事务提交之前，该更新的重做记录通常存储在磁盘上的重做日志中。在事务提交之前将重做记录存储在磁盘上确保了即使数据库在更新数据项本身被写入磁盘之前崩溃，该数据库也能够反映该更新。例如，在标题为“Method And Apparatus For User Selectable Logging”的美国专利第5,903,898号中描述了重做记录和重做日志。

由节点生成的重做记录通常存储在该节点专用的重做日志中。因此，具有三个节点的无共享数据库系统通常具有三个重做日志，其中每个均对应于三个节点中的一个。与无共享节点相关的重做节点可以仅包括用于由该节点做出的改变的重做。然而，当重做日志被存储在其它节点访问的共享磁盘上时，其它节点可以检查重做日志的内容。

正如将在下文中更加详细地说明的，提供允许通过利用无共享节点的能力来检查由其它无共享节点保持的信息，使用单相提交协议来执行一定分布式事务或部分分布式事务的技术。例如，描述了利用在分布式事务中的一些参与者可能能够读取由分布式事务的协调器程序保持并且表示分布式事务的状态的信息的事实的技术。这种状态信息可以被保持在共享磁盘上，例如，保持在协调器程序的重做日志中。可选地，诸如表、组或块的单独结构或一些永久的索引结构可以被用来存储分布式事务状态信息。如下面将说明的，在分布式事务提交期间，协调器将对事务状态的改变强加到共享磁盘，使得状态信息可以被其它参与者检查以确定结果，以免在协调器将消息发送到有关该提交的其它参与者之前死掉。

内部参与者和外部参与者

根据一个实施例，在无共享数据库系统内的分布式事务中的协调节点和参与者之间的相互作用中使用的协议，取决于该参与者是否能够检查由协调器保持的分布式事务状态信息。能够检查分布式事务状态信息的参与者在此称为“内部参与者”，而不能检查分布式事务状态信息的参与者在此称为“外部参与者”。

用于外部参与者的双相提交

根据一个实施例，在无共享数据库系统中的分布式事务中的外部参与者根据双相提交协议与协调器程序相互作用。例如，外部参与者可以通过图2所示的状态和步骤进行转变。特别地，外部参与者首先从协调器接收开始事务的请求作为较大分布式事务的一部分。随后，外部参与者开始事务并且执行所请求的操作作为事务的一部分。

如果由分布式事务做出的改变趋向于是永久的，那么外部参与者将最终接收“准备”请求。响应于准备请求，外部参与者将重做记录写入到磁盘，将“准备好的”记录写入到磁盘，并且将准备好的确认发送回协调节点。

假设所有的参与者均能够成功地准备，则外部参与者将接收遗忘请求。响应于遗忘请求，外部参与者将提交记录强加到磁盘。随后，参与者将遗忘确认发送到协调节点。

用于内部参与者的单相提交

在一个实施例中，内部参与者在分布式事务期间不使用双相提交协议。特别地，在成功地执行其与分布式事务相关的任务之后，内部参与者不必将表示它们已经准备好的准备记录记入日志。相反地，在执行所请求的工作并且将由此做出的任何改变写入到永久存储器之后，内部参与者仅仅等待来自协调器的提交请求。当提交请求到达时，内部参与者提交改变并且将提交确认消息发送回协调器。

参照图3，其是示出了根据本发明的实施例的在分布式事务期间协调器和内部参与者之间的相互作用的流程图。为了说明的目的，假设协调节点和内部参与者是无共享数据库的两个无共享节点，并且假设分布式事务需要涉及由内部参与者拥有的数据的一个或多个操作。

在步骤302，协调器接收开始分布式事务的请求，并且在步骤304，协调器开始分布式事务。在步骤306，协调器向内部参与者发送开始子事务的请求以执行作为分布式事务的一部分的操作。

在步骤350，内部参与者接收开始子事务的请求，以及在步骤352，内部参与者开始该子事务。在步骤308，协调器向内部参与者发送执行工作的请求，以及在步骤354，内部参与者接收该请求并且执行工作。当内部参与者执行该工作时，内部参与者生成反映由内部参与者做出的改变的重做记录。如步骤356所示，这些重做记录可以周期性地存储在磁盘上。可选地，重做记录可以保留在易失存储器中，直到满足某些写入触发条件。这样的写入触发条件可包括，例如，释放易失存储器用于其他用途的需要，或接收到写入请求。

在步骤310，协调节点接收提交请求。响应于该提交请求，协调器确定是否所有的参与者已经将用于所有改变的重做存储到磁盘，这些改变作为分布式事务的一部分被执行。可以使用多种技术以便协调器做出该确定。下面将更加详细地给出这些技术的实例。

如果所有的参与者已经将用于被执行的所有改变的重做存储到磁盘作为分布式事务的一部分，那么控制转到步骤314。否则，控制转到步骤322。在步骤322，协调节点等待，直到所有的参与者已经将它们的改变写入磁盘。为了加速事务的完成，协调器可以可选地将写入请求发送到还没有将其所有的改变记录到磁盘的那些参与者。响应于这种请求，参与者将所有与做出的改变相关的所有重做写入磁盘作为分布式事务的一部分。

在步骤314，协调器将用于该事务的还没有写入磁盘的任何重做写入磁盘。协调器还将提交记录强加到磁盘，该提交记录表示分布式事务已经被提交。随后，协调器将提交请求发送到参与者，并且等待参与者确认它们已经提交了其改变(步骤316和324)。应当注意，当协调器仍向内部参与者发送提交请求时，可以在分布式事务实际提交之后发送提交请求。因此，这些消息的传输、以及随后的确认的接收不在分布式事务的“关键路径”上。

在步骤358，内部参与者接收提交请求，并且在步骤360，提交包括用于分布式事务的工作的子事务。在提交该子事务之后，内部参与者将提交确认消息发送回协调器(步骤362)。

协调器永久地保留表示分布式事务的状态的数据，直到协调器接收来自所有参与者的提交确认消息。一旦协调器接收到来自所有参与者的提交确认消息，协调器程序不再需要保留关于分布式事务的状态信息(步骤320)。

确定参与者重做是否已经被写入磁盘

如上所述，当节点做出改变时，节点生成对应于该改变的重做记录。由每个节点执行的改变通常由节点分配给序号。这样的序号在这此称为“日志序号”。

根据一个实施例，当内部参与者执行作为分布式事务的一部分的工作时，内部参与者将对应于由用于事务的内部参与者完成的工作的最高日志序号传输到分布式事务的协调器。例如，假设内部参与者执行作为分布式事务的一部分的三个改变。进一步假设用于那些改变的重做记录被分配日志序号5、7、和9。在本实例中，在改变完成时，内部参与者将日志序号9传输给协调器。

根据一个实施例，协调器使用从内部参与者接收的日志序号，以确定内部参与者是否已经将做出的所有改变记录到磁盘作为分布式事务的一部分。例如，假设已经由特定内部参与者传输到协调器的最高日志序号为9。在这些情况下，如果内部参与者的永久日志包括与日志序号9以及更小日志序号相关的所有重做记录，那么协调器知道内部参与者已经将与分布式事务相关的改变记录到磁盘。

可以使用多种技术以便协调器确定哪个重做记录已经由内部参与者写入到磁盘。例如，内部参与者的重做日志可以在协调器可直接访问的共享磁盘上。因此，协调器可以简单地检查内部参与者的重做日志和/或为重做日志保持的任何元数据，以确定必要的重做信息是否已经被存储在磁盘上。可选地，在无共享数据库系统中的各种节点可以彼此传输它们各自的重做日志的当前边界(“检查点”)(其中，在检查点或在检查点之下的所有重做已经被记录到磁盘)。可以响应于对该信息的请求或可以基于周期提前地做出这些通信。

捎带(piggybacked)消息

通常，许多消息在无共享数据库系统的无共享节点之间来回运送。根据一个实施例，在协调节点和内部参与者之间传输的一些或所有信息通过否则在节点之间发送的消息上“捎带”该信息来传输。

例如，在步骤322，协调器可以通过在正被发送到内部参与者的节点的另一消息上捎带该消息，来将“强制重做”消息发送到内部参与者。类似地，内部参与者可以通过在其它被发送到协调器的消息上捎带信息，来将最高日志序号和提交确认消息发送到协调程序。

崩溃参与者的恢复

如上所述，在作为分布式事务的一部分，协调器确定所有的参与者已经记录了与做出的改变相关的重做之后，协调器提交该分布式事务(步骤314)。在将必需的重做写入磁盘之前或之后，分布式事务中的参与者可能崩溃。在这些情况下，崩溃参与者的恢复将涉及确定是否提交或回滚做出的改变作为分布式事务的一部分。

如果崩溃参与者是外部参与者，那么如果外部参与者在崩溃之前准备了改变，则参与者自己的重做日志将具有与分布式事务相关的准备记录。在检测准备记录时，恢复程序将知道不自动地回滚与分布式事务相关的改变。另一方面，如果外部参与者的重做日志不具有准备记录，那么恢复程序自动地回滚改变。

如果崩溃参与者是内部参与者，那么参与者自己的重做日志将不具有准备记录，即使该崩溃参与者在崩溃之前已经将足够的重做信息记录到磁盘。然而，恢复程序向协调节点询问分布式事务是否已经被提交，而不是自动地回滚与该分布式事务相关的改变。

如果协调器是有效的并且通过指示分布式事务已提交来响应，那么由崩溃节点做出的改变被变成永久，作为崩溃节点的恢复的一部分。

如果协调节点是有效的并且通过指示分布式事务被回滚来响应，那么由崩溃节点做出的改变被回滚作为崩溃节点的恢复的一部分。

如果协调节点已经崩溃，并且另一节点正在恢复该协调节点，那么正在恢复该协调节点的程序可以将必要的信息提供给崩溃参与者的恢复程序。然而，如果协调节点已经崩溃，并且没有恢复程序可用于提供分布式事务的状况，那么内部参与者的恢复程序可以通过直接访问由协调节点保持的分布式事务状态信息来获得必要的信息。

特别地，在内部参与者能够访问协调器的重做日志的实施例中，崩溃的内部参与者的恢复程序可以检查协调器的重做日志，以了解是否存在用于分布式事务的提交记录。如果协调程序的重做日志包括用于分布式事务的提交记录，那么恢复程序提交由崩溃的参与者做出的改变。另一方面，如果协调器的重做日志不包括用于分布式事务的提交记录，那么恢复程序回滚由崩溃的参与者做出的改变。

崩溃的协调器

在将提交请求发送到分布式事务中的参与者之前，协调器有可能崩溃。在这些情况下，外部参与者将基于其在崩溃之前从协调器接收的通信而知道分布式事务的状况。特别地，外部参与者将知道其是否已经接收到准备请求和/或遗忘请求。

另一方面，内部参与者可能必需访问共享磁盘以检查由协调器在崩溃之前写入磁盘的事务状态信息。根据一个实施例，当内部参与者需要知道协调器的事务状态时，内部参与者从协调节点请求状态信息，或者如果协调节点正在被恢复，则从正恢复协调节点的恢复程序请求状态信息。如果协调节点崩溃并且还没有被恢复，那么内部参与者检索由协调器保持的分布式事务状态信息。例如，在一个实施例中，内部参与者通过检查协调器的重做日志来获得此信息。如果事务状况指示协调器已经提交了分布式事务，那么内部参与者提交内部参与者已经做出的改变作为分布式事务的一部分。如果在崩溃时协调程序还没有提交分布式事务，那么内部参与者回滚由内部参与者做出的改变作为分布式事务的一部分。

为了确保所有的内部参与者最后都知道分布式事务的最终状态，协调节点防止分布式事务的事务状态信息被删除或重写，直到所有的下级确认其相应的子事务已经被提交或中止。因此，即使内部参与者在分布式事务被提交之后并且在接收提交请求之前崩溃，内部参与者将最终知道分布式事务被提交，并因此将最终提交其相应的子事务。

硬件综述

图4是示出了可以执行本发明的实施例的计算机系统400的框图。计算机系统400包括用于传递信息的总线402或其它通信装置以及用于处理信息的与总线402连接的处理器404。计算机系统400还包括耦合至总线402的主存储器406，诸如随机访问存储器(RAM)或者其它动态存储装置，用于储存信息和将由处理器404执行的指令。在执行将由处理器404执行的指令期间，主存储器406还可用于储存临时变量或其他中间信息。计算机系统400进一步包括只读存储器(ROM)408或耦合至总线402的其他静态存储装置，用于存储静态信息和处理器404的指令。提供诸如磁盘或光盘的存储设备410，并耦合至总线402用于存储信息和指令。

计算机系统400可以经由总线402耦合至诸如阴极射线管(CRT)的显示器412，用于向计算机用户显示信息。包括字母数字键和其他键的输入装置414耦合至总线402，用于将信息和指令选择传递到处理器404。另一种类型的用户输入装置是光标控制416，诸如鼠标、跟踪球、或光标方向键，用于将方向信息和命令选择传递到处理器404并用于控制显示器412上的光标移动。输入装置通常在两个轴上(第一个轴(例如X轴)和第二个轴(例如Y轴))具有两个自由度，使装置能指定平面上的位置。

本发明涉及计算机系统400的使用，用于执行在此描述的技术。根据本发明的一个实施例，通过计算机系统400响应于执行包括在主存储器406中的一个或多个指令的一个或多个序列的处理器404，来实现这些技术。这样的指令可以从诸如存储装置410的其它计算机可读介质读入主存储器406。包括在主存储器406中的指令序列的执行，使得处理器404执行此处所述的处理步骤。在可选实施例中，可以使用硬连线电路(hard-wired circuitry)来取代软件指令或者与软件指令结合来实施该发明。因此，本发明的实施例将不限于硬件电路和软件的任何特定组合。

这里使用的术语“计算机可读介质”是指参与向处理器404提供指令用于执行的任何介质。这种介质可以采取多种形式，包括但不限于非易失性介质、易失性介质、和传递介质。非易失性介质举例来说包括光盘或磁盘，诸如存储装置410。易失性介质包括动态存储器，诸如主存储器406。传输介质包括同轴电缆、铜线、和光纤，包括组成总线402的导线。传输介质还可采取声波或光波形式，例如那些在无线电波和红外线数据通信过程中产生的声波和光波。

通常形式的计算机可读介质包括如软盘、软性盘、硬盘、磁带，或者任何其它磁性介质、CD-ROM、任何其它光介质、打孔纸、纸带、或者任何带孔图样的物理介质、RAM、PROM、EPROM、FLASH-EPROM、或者其他任何存储芯片或者盒式磁带，或者以下提到的载波、或者计算机可读的任何其他介质。

各种形式的计算机可读介质可参与将一个或者多个指令的一个或多个序列承载到处理器404用于执行。例如，指令开始可承载在远程计算机的磁盘中。远程计算机可以将指令加载到其动态存储器中，然后使用调制解调器通过电话线发送指令。计算机系统400本地的调制解调器可接收电话线上的数据，并使用红外发射器将数据转换成红外信号。红外探测器可以接收红外信号携带的数据，并且合适的电路可以将数据放到总线402上。总线402将数据承载到主存储器406，处理器404从主存储器取回并执行这些指令。在由处理器404执行这些指令之前或之后，由主存储器406接收的指令可随意地储存在存储装置410上。

计算机系统400还包括耦合至总线402的通信接口418。提供双向数据通信的通信接口418，耦合到与局域网422连接的网络链路420。例如，通信接口418可以是综合业务数字网(ISDN)卡或者调制解调器，用于提供到相应类型的电话线的数据通信连接。又如，通信接口418可以是局域网(LAN)卡，用于提供至兼容局域网(LAN)的数据通信连接。也可以使用无线链路。在任何这样的实施中，通信接口418发送和接收承载表示各种类型的信息的数字数据流的电信号、电磁信号、和光学信号。

网络链路420通常可通过一个或者多个网络向其它数据装置提供数据通信。例如，网络链路420可通过局域网422与主机424连接，或者与互联网服务提供商(ISP)426操作的数据设备连接。ISP426又通过目前通称为“互联网”428的全球分组数据通信网络提供数据通信服务。局域网422和互联网428都使用承载数字数据流的电信号、电磁信号、或光学信号。通过各种网络的信号和网络链路420上的信号以及通过通信接口418的信号，都传送数字数据给计算机系统400或者传送来自计算机系统的数字数据，是传输信息的载波的示例性形式。

计算机系统400能通过网络、网络链路420、和通信接口418发送消息和接收数据(包括程序代码)。在互联网的实例中，服务器430可通过互联网428、ISP 426、局域网422、和通信接口418，传送用于应用程序的所请求的程序代码。

所接收的代码可以在其被接收时由处理器404执行，和/或储存在存储装置410或者其它非易失性介质中用于随后执行。按照这种方式，计算机系统400可以以载波的形式获得应用代码。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (22)

1.一种用于在无共享数据库系统中执行分布式事务的方法，所述方法包括：

在所述无共享数据库系统的第一无共享节点上，使正在协调所述分布式事务的协调器将指示所述分布式事务的状况的信息存储在永久存储装置上；

其中，参与者能够访问所述永久存储装置，所述参与者将执行一个或多个操作作为所述分布式事务的一部分；

其中，所述参与者驻留在所述无共享数据库系统的第二无共享节点上；以及

在所述无共享数据库系统的所述第二无共享节点上，使所述参与者通过读取来自所述永久存储装置的所述信息来确定所述分布式事务的所述状况。

2.根据权利要求1所述的方法，其中：

所述参与者是所述分布式事务中的多个参与者的第一参与者；

所述多个参与者包括不能够访问所述永久存储装置的第二参与者；以及

所述方法进一步包括所述协调器根据双相提交协议与所述第二参与者相互作用的步骤。

3.根据权利要求1所述的方法，进一步包括以下步骤：

所述协调器提交所述分布式事务；

在所述协调器提交所述分布式事务之后，所述协调器将提交消息发送到所述参与者；以及

防止指示所述分布式事务的状况的所述信息被重写或删除直到一组条件被满足，

其中，在所述一组条件中的一个条件是所述协调器接收来自所述参与者的提交确认消息。

4.根据权利要求1所述的方法，进一步包括以下步骤：

所述参与者将第一信息块发送到所述协调器，其中，所述第一信息块与作为所述分布式事务的一部分由所述参与者执行的工作相关；以及

所述协调器在所述第一信息块和与所述第二无共享节点的重做日志相关的信息之间进行比较；以及

所述协调器至少部分地基于所述比较来确定是否提交所述事务。

5.根据权利要求4所述的方法，其中，信息块包括作为所述分布式事务的一部分由所述参与者做出的最新改变的日志序号。

6.根据权利要求5所述的方法，其中，所述发送的步骤包括以下步骤：

所述参与者识别为了与所述分布式事务不相关的目的而正被发送到所述第一无共享节点的消息；以及

在所述消息上捎带所述日志序号。

7.一种用于在无共享数据库系统中执行分布式事务的方法，所述方法包括：

分配参与者以执行一个或多个操作作为所述分布式事务的一部分；

其中，所述参与者驻留在所述无共享系统的第一无共享节点上；

使所述参与者在永久存储装置上存储指示由所述参与者在所述一个或多个操作执行期间做出的改变的状况信息；

其中，协调器可以访问所述永久存储装置，所述协调器负责协调所述分布式事务；

其中，所述协调器驻留在所述无共享数据库系统的第二无共享节点上；

在所述无共享数据库系统的所述第二无共享节点上，使所述协调器基于在所述永久存储装置上的所述状况信息，来确定所述参与者是否已经将通过执行所述一个或多个操作产生的改变写到永久存储器；以及

所述协调程序至少部分地基于所述参与者是否已经将通过执行所述一个或多个操作产生的改变写到永久存储器，来确定所述分布式事务是否可以被提交。

8.根据权利要求7所述的方法，其中：

所述使所述参与者在永久存储装置上存储指示由所述参与者在所述一个或多个操作执行期间做出的改变的状况信息的步骤包括：

使所述参与者将在重做日志中的重做信息存储在所述永久存储装置上；以及

所述使所述协调器基于在所述永久存储装置上的所述状况信息来确定所述参与者是否已经将通过执行所述一个或多个操作产生的改变写到永久存储器的所述步骤包括：检查所述参与者的所述重做日志，以确定用于所述改变的所述重做信息是否已经被写到所述永久存储器。

9.根据权利要求7所述的方法，其中：

所述参与者是所述分布式事务中的多个参与者中的第一参与者；

所述多个参与者包括将状况信息存储在所述协调器不能够访问的第二永久存储装置上的第二参与者；以及

所述方法进一步包括所述协调器根据双相提交协议与所述第二参与者相互作用的步骤，。

10.根据权利要求7所述的方法，其中：

在所述永久存储装置上的所述信息指示所述参与者还没有将通过执行所述一个或多个操作产生的改变写到永久存储器；以及

所述方法进一步包括所述协调器将强制重做消息发送到所述参与者，以使所述参与者将通过执行所述一个或多个操作产生的所述改变写到永久存储器。

11.根据权利要求10所述的方法，其中，所述发送强制重做消息的步骤包括以下步骤：

识别为了与所述分布式事务不相关的目的而正被发送到所述第一无共享节点的消息；以及

在所述消息上捎带所述强制重做消息。

12.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求1中所述的方法。

13.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求2中所述的方法。

14.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求3中所述的方法。

15.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求4中所述的方法。

16.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求5中所述的方法。

17.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求6中所述的方法。

18.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求7中所述的方法。

19.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求8中所述的方法。

20.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求9中所述的方法。

21.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求10中所述的方法。

22.一种计算机可读取介质，承载有一个或多个序列指令，当所述序列指令由一个或多个处理器执行时，使所述一个或多个处理器执行在权利要求11中所述的方法。

Images