CN100550009C - 异步信息共享系统 - Google Patents

Abstract

本发明披露了用于在多种环境下共享信息的方法。描述了一种信息共享系统，该系统允许显式捕获过程和隐式捕获过程，以将信息条目添加到中间存储区中。此外，信息共享系统支持储存在所述中间存储区中的信息条目的隐式和显式消费。规则引擎被提供来允许用户创建和登记定制捕获过程、消费过程和将信息从中间存储区传送到指定目的地的传播过程的行为的规则。也描述了用于完成对条目序列恰好处理一次的方法，其中，这些条目被保存在易失性存储器中。也提供了用于记录DDL操作和基于之前执行的DDL操作异步执行操作的方法。

Description

异步信息共享系统

相关申请

本申请涉及并要求下列申请的优先权，用于将其全部内容结合于此作为参考：

于2002年8月1日提交的名称为“在分布式信息共享中的使用规则(UTILIZING RULES IN DISTRIBUTED INFORMATIONSHARING)”的第60/400,532号美国临时专利申请；以及

于2002年9月13日提交的名称为“ORACLE流”的第60/410,883号美国临时专利申请。

技术领域

本应用涉及信息共享系统。

背景技术

容易而及时地共享信息的能力对于任何商业环境都是非常重要的要求。因此，信息共享已被许多机制支持，诸如讨论、邮件、书、期刊以及计算机技术。许多基于计算机的技术已发展来支持信息共享的目标，诸如报表/语句、复制和信息传送。

不幸地，大多数信息共享仍然通过应用程序处理，这种应用程序代表了一种由于与开发、配置、操作和维护提供信息共享服务的应用程序有关的成本造成的相对昂贵的解决方案。另外，这种应用程序提供的服务常常缺乏理想的功能，诸如对特别请求、用户化和及时而灵活的传送的支持。

任何数据库管理系统的重要特征是在多个数据库和应用程序之间共享信息的能力。传统地，这已经包括使用各种重叠技术将信息从数据库中取出的用户和应用程序。目前，新的效率和商业模型要求一种更全面且自动化的方法。许多信息共享解决方案的目标是解决特定的信息共享问题。虽然这种解决方案可以解决它们所针对的特定信息共享问题，但它们可能不可以应用，甚至可能与其它的信息共享问题不兼容。

综上所述，希望提供一种以比目前的特定问题解决方案更灵活的方式的用于共享电子信息的系统和方法。

附图说明

本发明在附图中以举例而不是限制的方式加以阐明，附图中相似的参考标号指相似的元件，其中：

图1是根据本发明的实施例配置的信息共享系统的框图；

图2是示出根据本发明的实施例的当数据条目流经信息共享系统时所经历的三个一般阶段的框图；

图3是示出根据本发明的实施例的数据库中变更的自动捕获的框图；

图4是示出根据本发明的实施例的从源队列向目的队列传播的事件的框图；

图5是示出根据本发明的实施例实施的有向网络环境的框图；

图6是示出根据本发明的实施例的在单一队列中事件的显式入列和出列的框图；

图7是示出根据本发明的实施例的事件的显式入列、传播和出列的框图；

图8是示出根据本发明的实施例的一个应用过程的框图；

图9是示出根据本发明的实施例的在应用程序操作过程中转换的框图；

图10是示出使用信息共享系统将来自Oracle数据库系统的数据共享给非-Oracle数据库系统的框图；

图11是示出使用信息共享系统将来自非-Oracle数据库系统的数据共享给Oracle数据库系统的框图；

图12是示出根据本发明的实施例的在单一数据库内实施的信息共享系统的框图；

图13A和13B是示出根据本发明的实施例的用于在多个数据库之间共享信息的信息共享系统的框图；

图14是示出根据本发明的实施例的在一个规则集评价过程中的阶段的框图；

图15是示出根据本发明的实施例的一个规则集可以被规则引擎的多个客户端使用的框图；

图16是示出根据本发明的实施例的在捕获过程中转换的框图；

图17是示出根据本发明的实施例的在传播过程中转换的框图；

图18A、18B和18C是示出每个数据库既是源数据库也是目的数据库的多节点系统的框图；

图19是示出当每个数据库都是源数据库又是目的数据库时使用标记的框图；

图20是示出一个主数据库与几个从属数据库共享数据的的框图；

图21是示出在主数据库中使用标记的框图；

图22是示出在从属数据库中使用标记的框图；

图23是示出一个主数据库和几个扩展的从属数据库的框图；

图24是示出根据本发明的实施例的从源站点经过一个中间站点至目的站点的在存储器内的变更信息流的框图；

图25是示出根据本发明的实施例的由一应用引擎执行的步骤的流程图，该应用引擎使用持久储存的LOW WATERMARK、持久储存的识别ABOVE-MARK APPLIED事务的数据以及非持久储存的HIGHEST SO FAR CSN来获取恰好一次的行为；以及

图26是一个可以在其上实施本发明的实施例的计算机系统的框图。

具体实施方式

本发明描述了一种用于共享电子信息的方法和系统。在下面的描述中，出于解释的目的，许多具体的细节被阐明以提供对本发明的彻底理解。然而，显而易见，本发明可以在没有这些具体细节的情况下进行实施。在其它实施例中，已知的结构和装置以框图的形式示出以避免对本发明不必要的混淆。

触发的活动链

传统的数据库系统技术常常将数据操作看作一种孤立的动作。然而，在许多现实方案中，情况不是这样的。特别地，数据操作常常触发活动序列或“链”。这样触发的动作分成多个种类，包括但不局限于：

·信息创建、修改、删除或通过时间(the passage of time)：这一类的活动可以构成一个“商业事件”。

·信息要求的评价(evaluation)：确定谁需要/喜欢被告知一个商业事件。

·理想信息的创建：使用应用程序查看和/或转换，将信息创建为一种相互协定的形式。

·经由理想传输将信息转移到理想位置。

·在目标位置的数据的修改：吸收根据接收方的需要组织的目标环境中的新信息。

·新状态的通知：为接收方或程序提供低潜伏期知识(latencyknowledge)；通知可能激活应用程序。

·对信息的存取：可能地为一个反应创建和/或修改信息(从而导致另一“商业事件”)。

根据本发明的实施例，可以为各种活动建立规则，以自动地执行某些数据修改事件想要的活动链。当然，被任何给定数据操纵事件触发的特定活动链将基于事件的性质和已建立的规则变更。

功能综述

下面描述了一种灵活的异步信息共享系统。该系统提供了可以单独使用或结合使用以解决多种信息共享问题的许多特征。根据一实施例，信息共享系统包括用于储存将被共享的信息的一个或多个中间存储区。一个在此被称作“捕获过程”的软件过程集将信息放置在中间存储区中。另一在此被称作“消费过程”的软件过程集消费来自中间存储区的信息。

根据一实施例，通过中间存储区执行的信息共享是异步的。特别地，产生被捕获过程捕获的变更的过程不会暂停执行来等待捕获过程对变更的捕获。相反地，捕获过程不必返回向产生变更的过程报告。类似地，捕获过程不暂停执行以等待添加到中间存储区的信息的进一步处理。类似地，消费过程不必返回向捕获过程报告以提示捕获过程继续执行。

根据一个方面，信息共享系统支持多种捕获过程，包括隐式捕获过程和显式捕获过程。隐式捕获过程是基于发生在与所述隐式捕获过程有关的系统中的事件将信息添加到一个或多个中间存储区的过程。日志捕获过程是隐式捕获过程的一个实例。日志捕获过程读取日志，诸如响应于在数据库系统内发生的事件由数据库系统产生的日志，基于日志的内容将信息放入中间存储区。显式捕获过程是添加信息到中间存储区的过程，通过进行显式功能调用，经由一个与中间存储区有关的API，将信息添加到中间存储区。

根据另一方面，信息共享系统支持多种消费过程，包括应用过程、传播过程和显式出列过程。应用过程是自动出列和根据包含在中间存储区内的信息动作的过程。传播过程自动使信息出列并将信息从一个中间存储区移动到一个指定的目的地。指定的目的地可以是例如另一中间存储区。显式出列过程从中间存储区获取信息，通过进行显式调用，经由一个与中间存储区有关的API，从中间存储区获取信息。

消费过程可以用于用它们消费的信息执行多种操作。例如，消费过程可以用于将从队列中提取出的消息传送到之前已登记了对接收或被告知某种类型的信息或事件感兴趣的“用户过程”。在另一环境下，所提取的信息可以表示已在一数据库系统内已作出的变更，消费过程可以用于在另一数据库系统内作出相应变更。

系统综述

图1是根据本发明的实施例的用于异步共享信息的系统100的框图。参考图1，它包括多个中间存储区102、104、106。信息被捕获过程112、114和116分别添加到每个中间存储区102、104、106。信息被消费过程122、124和126分别从每个中间存储区102、104、106消费。捕获过程112、114和116可以包括隐式捕获过程和/或显式捕获过程。消费过程122、124和126可以包括应用过程和显式出列过程。

系统100还包括用于将信息从一个中间存储区106提取出并添加到另一中间存储区102的传播过程118。以下将更加详细地描述，传播过程118的源和目标不必总是中间存储区。例如，传播过程可以用于有选择地从一中间存储区提取信息并将所提取的信息发送到对该信息感兴趣的另一过程。该另一过程可以是例如在与系统100相对遥远的系统内运行的过程。

根据一实施例，中间存储区102、104、106可以为不是特定类型的队列。因为中间存储区102、104、106不是特定类型的，相同的中间存储区可以用于储存大量不同类型的数据。因此，多条信息可以按顺序或反映这些条信息之间关系的排列一起储存在中间存储区内，甚至当这些条信息对应于不同类型的数据时。在其它可选择的实施例中，中间存储区可以是特定类型的，其中，每个中间存储区用于储存特定类型的信息条目。

信息共享系统100可以使用户共享数据和事件。信息共享系统100可以将该信息在数据库内传播或从一个数据库传播到另一数据库。信息共享系统100将指定的信息传送到指定的目的地。这个结果是一个新特征，这一特征提供了比传统的用于捕获和管理事件、以及与其它数据库和应用程序共享该事件的解决方案更强大的功能性和灵活性。信息共享系统100能够使用户中断交替使用一个解决方案和其它解决方案的循环。信息共享系统100提供了需要建立和操作分布的企业和应用程序、数据仓库和高效解决方案的能力。用户可以同时使用信息共享系统100的所有能力。如果需要变更，那么用户可以实施信息共享系统100的一种新的功能而不必牺牲现有的功能。

使用信息共享系统100，用户控制将什么信息输入信息共享系统100，信息如何从中间存储区向中间存储区或从数据库向数据库流动或传送，当信息共享系统100内的事件流入每个数据库时在信息共享系统100中会发生什么事情，以及信息共享系统100如何终止。通过配置信息共享系统100的具体功能，用户可以提出具体要求。基于用户的具体要求，信息共享系统100可以自动地捕获、储存和管理数据库内的事件，包括但不局限于，数据操纵语言(DML)变更和数据定义语言(DDL)变更。用户也可以将用户定义的事件放入信息共享系统100中。然后，信息共享系统100可以将信息自动地传播到其它数据库或应用程序。此外，基于用户的具体要求，信息共享系统100可以在目的数据库应用事件。图2示出了当信息通过信息共享系统100被共享时信息通常流经的阶段。

信息共享选项

如上所述，响应于一个事件，可以被系统100执行的活动链可以形成多种形式。一般而言，活动链可以包括一个或多个数据捕获、出站(out-bound)存储、传播、入站(in-bound)存储和消费。根据一实施例，系统100提供以多种方式实施这些活动中的每个活动的机制。表1列出了对于各种活动中的每个活动的一些特征的多个选项。

表1

组件	元素	选项	注释
				数据捕获	方式	E-显式	选择一个
		I-隐式
					数据类型	S-模式	选择一个
		B-商业对象
					约束	N-无	任何结合
		S-序列
						CY-循环
		CO-冲突
						P-过程
		D-数据
						TR-事务的
存储：出站		N-无	选择一个
						J-日志
		B-基本的(Basic)
						S-SQL
传播	传送	B-最大努力	选择一个
						E-恰好一个
	安全	C-机密的	任何结合
						S-有符号的
	寻址	O-开放式	选择一个
						C-封闭式
	约束	与数据捕获相同的选项

存储：入站		除了J，与存储出站相同的选项
				消费		与数据捕获相同的选项

关于被捕获的信息的数据类型，“模式”选项指的是面向模式的数据查看。相反，“B”选项指的是面向商业文档的数据查看。

表1中给出的活动、元素和相应选项的列表不是详尽的。在此描述的信息共享框架可以以一种提供多种其它活动、元素和选项的方式被实现。例如，传播活动的传送元素的另一选项可以是“至少一次”。这样，表1仅仅想要说明在此所述的信息共享系统的灵活性。

表2举例说明本文所述的信息系统的灵活性如何被利用以在多种环境下完成信息共享任务。特别地，表2列出了一种需要或要求信息共享的环境，并列出了当使用系统100执行那个环境下的信息共享活动时可能使用的选项。

环境	数据捕获和消费选项	出站存储选项	传播选项	入站存储选项
					信息传送-本地	E，B，TR	B/S	N/A	N/A
信息传送-远程	E，B，TR	B/S	*，*，*，TR	B/S
					应用程序到应用程序	E，B，P，TR	S	E，C，O，TR	S
复制-标准	I，S，S，CY，CO，TR	S	E，C，C，TR	B
					复制-日志	I，S，S，CY，CO，TR	J	E，C，C，TR	B
复制-模式或B2B	I，B，S，CY，CO，TR	S/J	E，C，C，TR	B
					HA	I，S，TR	J	E，C，C，TR	B
HA-模式	I，B，TR	J	E，C，C，TR	B
					B2B信息传送	E，B，TR	S	E，*，O，TR	S
B2B协议	E，B，P，TR	S	E，*，O，TR	S

信息共享系统100的操作综述

根据一实施例，用户可以使用信息共享系统100捕获数据库中的变更，使事件进入一个队列，将事件从一个队列传播到另一队列，使事件出列，应用数据库中的事件，实现有向的网络，执行自动冲突检测和解析，执行转换，以及实现不同的信息共享。

关于捕获变更，用户可以配置一个后台日志捕获过程以捕获对表、模式或整个数据库作出的变更。根据一实施例，日志捕获过程从重做日志捕获变更并将每个被捕获的变更格式化成“逻辑变更记录”(LCR)。在重做日志中产生变更的数据库被称作源数据库。

关于将事件放入一个队列，至少两种类型的事件可以储存在信息共享系统100的队列中：LCR和用户消息。捕获过程使事件进入用户指定的队列。然后该队列在相同的数据库内共享事件或与其它的数据库共享事件。用户也可以显式地用一个用户应用程序使用户事件入列。这些显示入列事件可以是LCR或用户消息。

关于将事件从一个队列传播到另一队列，队列可以在相同数据库中或不同数据库中。

关于使事件出列，后台应用过程可以使事件出列。用户也可以用一个用户应用程序使事件出列。

关于在数据库应用事件，用户可以配置一个应用过程以应用一个队列中的所有事件或仅仅应用用户指定的事件。用户也可以配置一个应用过程以调用用户创建的子程序(例如，用PL/SQL语言写的子程序)处理事件。应用事件或处理其它类型事件的数据库被称作目的数据库。在一些配置中，源数据库和目的数据库可以相同。

信息共享系统100的典型应用程序

信息共享系统100是灵活的，足以取得实际无限数量的信息共享对象。因此，放入信息共享系统100的应用程序的数量非常大。为了举例说明信息共享系统100的实用性和多功能性，将给出信息共享系统如何被应用来实现消息排队和数据复制的细节。

关于消息排队，信息共享系统100允许用户应用程序使不同类型的消息入列，将消息传播到订阅队列，通知用户应用程序消息已准备好用于消费，使目的数据库的消息出列。基于规则的消息通知消费过程可以与日志捕获过程结合使用。利用这种组件的结合，捕获过程可以将反映在数据库的日志文件中反映的事件的LCR添加至中间存储区，消费过程可以发送通知给那些表明对特定类型的数据库事件感兴趣的订阅者。订阅者感兴趣的特定事件可以作为订阅数据储存起来，它可以使用一个或多个SQL语句识别订阅者感兴趣的数据。重要的是，这种通知可以直接发送给订阅者，通过远程但兼容的信息传送系统发送给用户，或通过与最初产生LCR的系统不兼容的信息传送系统的消息网关发送给订阅者。

根据一实施例，信息共享系统100使用一种储存SYS.AnyData类型的消息的队列实现中间存储区102、104和106。几乎所有类型的消息都可以打包成SYS.AnyData包，并储存在SYS.AnyData队列中。信息共享系统100用一种支持消息排队系统的所有标准特征的排队机制相互操作，包括多用户队列、公布和订阅、基于内容的传送、Internet传播、转换和到其它信息传送子系统的网关。

关于数据复制，信息共享系统100可以有效地捕获对数据库对象进行的数据操纵语言(DML)和数据定义语言(DDL)变更并将这些变更复制到一个或多个其它数据库。捕获过程(例如捕获过程116)捕获对源数据库对象作出的变更并将它们格式化成LCR，LCR可以传播到目的数据库(例如经由传播过程118)，然后被应用过程(例如消费过程122)应用。

目的数据库可以允许对相同数据库对象的DML和DDL变更，这些变更可以或不可以传播到环境中的其它数据库。换而言之，用户可以配置具有传播变更的数据库的信息共享系统100，或用户可以配置一种在其中可以在数据库之间双向传播变更的环境。用于被共享的数据的表也不必在所有的数据库都是相同的副本。这些表的结构和内容可以在不同的数据库不同，这些表内的信息可以在这些数据库之间共享。

核心服务

系统100的组件提供了一个核心服务集。根据一实施例，那些核心服务包括事件捕获、事件分配和事件消费。

事件捕获一般指建立对发生在感兴趣的系统中的事件的记录。例如，感兴趣的系统可以是一个数据库系统，事件捕获可以由捕获过程的集合执行，这将在下文更加详细地描述。

事件分配一般指把有关事件的信息分配给对该事件感兴趣的实体。这种实体可以驻留在创建感兴趣的事件的系统内部或驻留在系统外部。例如，事件分配可以包括把有关一个数据库系统内作出的变更的信息发送至另一数据库系统。

事件消费一般指读取捕获的事件信息。通常，消费过程将基于所捕获的事件执行某些活动，或开始某种活动链。例如，接收来自一个源数据库系统的变更信息的目标数据库系统内的过程可以读取来自源数据库系统的变更信息，并基于源数据库系统内作出的相应变更开始目标数据库系统内的变更。

隐式捕获过程实例

如上所述，系统100支持显式和隐式捕获过程。日志捕获过程是隐式捕获过程的实例。根据一实施例，日志捕获过程是用于读取储存在数据库服务器的日志文件内的信息，并基于日志文件中的信息将信息存入一个或多个中间存储区的过程。这种日志文件可以包括例如由数据库系统产生来记录数据库系统正作出的变更的重做日志文件。

例如，一个重做日志文件可以包括表明在一个特定点，数据库服务器及时地将一特定表的特定行的特定列的值由X变更为Y的重做记录。这种重做记录中包含的信息通常由数据库服务器使用来保证当故障发生时丢失没有提交的变更。然而，使用一个日志捕获过程与其它过程有选择地共享包含在重做记录中的信息，通过将信息放入消费过程可使用的一个或多个中间存储区中，允许以除了开始产生日志的恢复目的之外的多种方式使用信息。例如，消费过程可以有选择地将来自中间存储区的变更信息提供给驻留在产生日志的数据库服务器的外部的过程。

根据一实施例，日志捕获过程有选择地捕获来自日志文件的信息。例如，响应于对特定表作出的特定类型的变更，异步触发器可以用于启动。因此，当事务对特定表作出特定类型的变更时，(1)数据库服务器将产生重做记录来响应变更，以及(2)触发器将启动以及一个捕获过程将捕获新的重做记录。由于触发器是异步的，捕获过程的执行将不作为导致变更的事务的一部分被执行。这样，事务可以继续进行而不必等待捕获过程，捕获过程可以在作出变更之后的某一时间捕获新的重做记录。

响应于异步触发器的启动，执行捕获过程仅仅是捕获过程操作的一个实例。另外，日志捕获过程可以简单地用于定期检查新记录的适当日志。作为另一可选择的方法，响应于同步触发器，日志捕获过程可以被执行。当使用同步触发器时，捕获操作可由作为作出导致触发器启动的变更的事务的一部分的捕获过程执行。这样，变更的捕获相对于导致变更的事务是“同步的”。然而，与链(例如存储、传播、消费)有关的活动链中的任何其它活动仍然可以相对于那个事务异步执行。

根据一实施例，捕获过程获取从重做日志中抽取的变更数据，将变更数据格式化成LCR。捕获过程将LCR放入中间存储区中用于进一步处理。在一实施例中，对热挖掘联机重做日志和挖掘存档的日志文件均提供了支持。当执行热挖掘时，重做流可以在变更数据被写入时同时被挖掘，从而减少了捕获的潜伏期。

如上所述，对典型数据库内的数据库对象进行的变更被记入重做日志以保证在用户错误或介质故障发生的情况下的可恢复性。在一实施例中，隐式捕获过程是后台过程，在正管理数据库和读取数据库重做日志以捕获对数据库对象所作的DML和DDL变更的数据库服务器内执行。在将这些变更格式化成LCR之后，隐式捕获过程使它们排队进入中间存储区。

根据一实施例，存在几种类型的LCR，包括：行LCR，包括有关由DML操作引起的对表中行的变更的信息；以及DDL LCR，包括有关对数据库对象的DDL变更的信息。用户使用规则指定捕获哪些变更。图3示出了捕获LCR的隐式捕获过程。

如下文将更加详细地加以解释的，用户可以为由某一会话或应用过程产生的重做实体指定“标记”。然后这些标记成为由捕获过程捕获的LCR的一部分。标记可以被用于确定一个重做输入或LCR是否包含产生于本地数据库或不同数据库的变更，这样用户可以避免将LCR发送回产生它们的数据库。标记也可以用于其它LCR跟踪目的。用户也可以使用标记来为每个LCR指定目的数据库集。根据已为信息共享系统100的各种组件建立的规则，与LCR有关的标记值可以当LCR流经系统时在不同的点被设置、修改和/或转换。例如，对于一个在日志文件中识别的变更创建的LCR，一个标记值可以由捕获过程设置来表明变更产生的数据库。作为另一例子，用于LCR的标记值可以由传播过程设置来表明传播过程正从其传播LCR的系统。

一个挖掘变更的日志的捕获过程可以本地(其日志正被挖掘的系统)或远程(其日志正被挖掘的系统的外部)地驻留。在捕获过程正远程执行的地方，日志可以从产生它们的系统输出到捕获过程正执行的系统。例如，捕获过程可以用于挖掘第一数据库的日志，将用于在日志中表示的各种事件的LCR储存在中间存储区中。捕获过程可能实际上正在第二数据库系统中执行。在这种情形下，日志文件可以从第一数据库系统传送到第二数据库系统，以便由第二数据库系统的捕获过程处理。捕获过程储存LCR的中间存储区也可以驻留在第二数据库系统中。以这种方式“卸载”与捕获过程有关的开销的能力可以用于装载和资源平衡的目的。

中间存储区

如图1所示，中间存储区可以用于暂时保存信息的捕获、分配和消费之间的信息。用于保存信息的中间存储区的性质可以根据信息和由信息触发的活动链的性质变更。例如，用于保存信息的捕获、分配和消费之间的信息的中间存储区可以具有下面任何一种形式：

·无：被捕获的信息被直接传送到传播或消费过程。

·日志：恢复日志中的信息用于查找被捕获的事件。

·基本的：信息被保存在本身不提供恢复机制的存储区。

·SQL：信息被储存，但不必被保留在一个可以使用数据库语言诸如SQL查询的数据容器中。

·备有证明文件的：与SQL选项相同，除了信息被保留在数据容器中。

具有上述特征的中间存储区可以多种方式实现，本发明不局限于任何特定的实施。例如，SQL和备有证明文件的选项可以使用目前Oracle公司当前可提供的Oracle 9iR2数据库系统中的高级排队机制来实施。而且，高级排队功能可以与Oracle公司提供的OracleWorkflow 2.6结合使用来获得检查在其它事件的环境下的事件的能力。例如，一个显式事件(例如从一个应用程序接收到的消息，该应用程序在应用程序通过API作出的一个调用中)可以在其它显式事件的描述体中被看到(例如，从相同应用程序接收到的其它消息)。相似地，一个被隐式捕获的事件(例如，对由数据库服务器管理的数据的变更)可以在其它被隐式捕获的事件(例如其它数据库变更)的环境下被看到。

在一实施例中，信息共享系统100使用队列储存用于传播或消费的事件。用户可以使用信息共享系统100将事件从一个队列传播到另一队列，这些队列可以在相同的数据库或不同的数据库中。从其传播事件的队列被称作源队列，接收事件的队列被称作目的队列。在源队列和目的队列之间可以有一对多、多对一或多对多的关系。

储存在一个队列中的事件可以由一个或多个消费过程(诸如应用过程或用户定义)的子程序消费。如果用户配置一个传播过程(例如传播过程118)，将变更从源队列传播到目的队列，那么用户可以使用规则来指定哪些变更可以被传播。图4示出了从一个源队列到目的队列的传播。

有向网络(directed network)综述

信息共享系统100能够使用户配置一种通过有向网络(directednetwork)共享变更的环境。有向网络是在其中被传播的事件在到达目的数据库之前可以通过一个或多个中间数据库传播的网络。事件可以或不可以在中间数据库被处理。使用信息共享系统100，用户可以选择哪些事件可以传播到每个目的数据库，用户可以指定事件将到达目的数据库所通过的路线。

图5示出了一个有向网络环境的实例。在图5示出的实例中，在芝加哥的中间数据库上的队列既是源队列也是目的队列。

事件的显式入列和出列

用户应用程序可以显式地使事件排队进入信息共享系统100的中间存储区。用户应用程序可以将这些事件格式化成LCR，LCR允许应用过程在目的数据库应用它们。另外，这些事件可以通过另一用户应用程序被格式化为用于消费的用户消息，另一用户应用程序使事件显示地出列或者用来自应用过程的调用返回处理事件。显示地排队进入队列的事件可以显示地从相同的队列出列。图6示出了事件显式入列和从相同的队列出列。

当事件在队列之间传播时，显式地进入源队列的事件可以由用户应用程序从目的队列显式地出列而不需要来自应用过程的任何干预。图7示出事件显示地进入源队列、传播到目的队列、然后从目的队列显示出列。

虽然本文给的许多实例包括LCR的捕获、传播和应用，但那些实例中举例说明的技术同样适用于任何形式的共享数据。这种共享数据例如可以具有显示入列的用户消息，或甚至以一种不同于LCR的形式组织的被隐式捕获的信息。

应用过程综述

根据一实施例，应用过程是后台过程，在数据库服务器内运行，它使事件从队列出列或者直接将每个事件应用到数据库对象或将事件作为一个参数传送到被称作应用处理程序(handler)的用户定义的程序。这些应用处理程序可以包括消息处理程序、DML处理程序、和DDL处理程序。

根据一实施例，应用过程被设计成可以意识到事务边界。例如，应用过程意识到以应用过程正消费的LCR中表示的哪些变更是最初作为相同事务的一部分。应用过程将这些变更集合到事务中，以一种考虑到事务之间相关性的方式应用这些变更。根据一实施例，应用过程将这些变更并行地应用到事务之间的相关性所允许的程度。

通常应用过程将事件应用到正运行的本地数据库，但在不同的数据库环境下，它可以被配置成在具有与本地数据库不同类型的远程数据库应用事件。例如，本地数据库可以是由一个公司生产的数据库服务器创建的数据库，远程数据库可以是由另一公司生产的数据库服务器创建的数据库。用户使用规则指定队列中的哪些事件被应用。图8示出了处理LCR和用户消息的应用过程。

根据一实施例，当直接应用LCR时应用过程自动检测冲突。通常当源数据库和目的数据库的相同行几乎同时被改变时发生冲突。当冲突发生时，用户需要一种机制保证冲突可根据用户指定的商业规则被解决。根据一实施例，信息共享系统100包括多种预先建立的冲突解决处理程序。使用这些预先建立的处理程序，用户可以为根据用户指定的商业规则解决冲突的每个用户数据库定义一个冲突解决系统。如果用户具有一种预先建立的冲突解决系统不能解决的独特情况，那么用户可以建立定制的冲突解决处理程序。根据一实施例，如果冲突没有被解决，或如果处理程序过程产生错误，那么产生错误的事务中的所有事件被保存在异常队列中以便以后分析和可能再执行。

如上所述，LCR仅仅是可以被应用过程处理的共享信息类型的一个实例。应用过程可以被配置成能够“应用”任何形式的共享信息，包括显式入列的用户消息和不作为LCR组织的自动捕获的数据。

规则驱动的信息共享

如上所述，活动链中的每个活动都可以以多种方式执行。例如，可以用“最大努力”和“开放式”特征，或“恰好一次”和“封闭式”特征执行传播。根据本发明的一实施例，规则登记机制被提供以允许用户登记指定的规则：

·活动链响应于特定事件执行，以及

·活动链中的每个活动如何被执行。

根据一实施例，登记机制在数据库系统内被实施。当信息共享规则向数据库系统登记时，数据库系统产生和存储反映该规则的元数据(本文称作“规则元数据”)。另外，数据库系统产生请求执行该规则的任何机制。例如，假定用户需要使用系统100在目标数据库复制一个存在于源数据库中的表。为了使系统100执行该复制，用户可以登记规则集：

·识别将被复制的数据库表

·识别目标数据库，以及

·指定用于执行复制的数据捕获、存储、传播和消费选项

响应于该规则集的接收，数据库系统将产生元数据来记录该规则，产生任何支持机制来实施该规则。这种支持机制可以包括例如用于响应于在数据库表上执行的变更触发捕获过程的执行的异步触发器。元数据可能包括例如(1)指示捕获过程关于从哪个日志捕获信息、捕获哪个信息、要使用的捕获选项、以及将捕获的信息储存在哪的元数据；(2)指示传播过程要传播哪个信息、该信息在传播之前如何转换、以及在哪儿传播数据等的元数据。(3)指示目标数据库系统中的应用过程在哪儿接收被传播的信息、如何处理被传播的信息、以及如何应用被传播的信息来保持目标数据库系统中的表与被传播的信息中反映的变更同步等的元数据。

规则综述

信息共享系统100使用户能够控制共享哪个信息以及在哪儿使用规则共享它。规则被指定作为一个类似于SQL查询的WHERE语句中的条件，用户可以将相关的规则分类成规则集。根据一实施例，规则包括规则条件、规则评价环境、以及规则动作环境。

规则条件结合了一个或多个表达式和运算符并基于一个事件返回一个Boolean值，该Boolean值是TRUE、FALSE或NULL(未知)。

规则评价环境(context)定义了可以在规则条件中被参考的外部数据。该外部数据可以作为外部变量、作为列表数据存在或者作为两者存在。

规则动作环境是与当规则被评价时由规则引擎的客户端解释的规则有关的可选信息。

例如，下面的规则条件可以用于信息共享系统100来指定为了使条件等于TRUE，拥有表的模式名必须是hr以及表名必须是departments:

:dml.get_object_owner()＝′hr′AND:dml.get_object_name()＝′departments′

在信息共享系统100内，该规则条件可以以下面的方式使用：

指示捕获过程捕获对hr.departments表的DML变更。

指示传播过程传播对hr.departments表的DML变更。

指示应用过程应用对hr.departments表的DML变更。

信息共享系统100基于规则执行任务。这些任务包括：利用捕获过程捕获变更，利用传播过程传播变更，以及利用应用过程应用变更。根据一实施例，用户可以为这些任务定义三个不同等级的规则：表格规则、模式规则、和全局规则。

当用户定义表格规则时，在用户指定的表发生变更时执行任务。例如，用户可以定义指示捕获过程捕获对hr.employees表的变更的规则。给定这一规则，如果将一行插入到hr.employees表中，那么捕获过程捕获该插入，将它格式化成LCR，并使LCR排队进入一队列。

当用户定义模式规则时，在用户指定的模式下的数据库对象以及将来添加到模式的任何数据库对象发生变更时执行任务。例如，用户可以定义两个指示传播过程将hr模式的DML和DDL变更从一个源队列传播到一个目的队列的规则。给定这些规则，假设源队列包含定义下面变更的LCR：

hr.loc city_ix索引被改变。

在Hr.j obs表中的行被更新。

传播过程将这些变更从源队列传播到目的队列，因为两种变更都是用于hr模式的数据库对象。

当用户定义全局规则时，在数据库中的任何数据库对象发生变更时任务被执行。如果它是一个全局DML捕获规则，那么捕获过程捕获数据库中的数据库对象的所有DML变更。如果它是一个全局DDL传播或应用规则，那么执行任务用于队列中的所有DDL变更。

规则引擎

如上所述，系统100的各种组件可以设计默认行为，该默认行为可以由系统100的登记规则取代。当一个规则被登记时，在系统100内产生元数据以反映该规则。系统100的各种组件用于读取元数据并根据反映在其中的任何规则((1)应用它们和(2)应用于它们目前正操作的环境)修改它们的行为。

例如，一特定用户可以登记一个规则，该规则为当正被传播的条目是一特定类型的消息时将传播策略从默认的“恰好一次”改变为一个新值“最大努力”。负责传播那种特定类型消息的过程用于读取元数据，并当为那个特定用户处理那种特定类型的消息时使用“最大努力”传播方法。然而，当为其它用户传播相同类型的消息时，传播过程可以继续使用默认的“恰好一次”方法。

除了取代组件放入默认行为，规则可以用于补充行为。例如，一个特定的捕获过程可以用于捕获某些类型的信息并将该信息添加到中间存储区。规则可以向系统100登记，该规则为捕获过程指定了几种额外的任务，以在执行由它的默认行为提出的任务之前、过程中和/或之后执行。例如，根据登记的规则，捕获过程可以用于在将信息添加到中间存储区时(诸如(1)在将信息放入中间存储区之前给它添加标记，以及(2)在将信息放入中间存储区之后发送通知给各种实体时)执行许多额外任务。

登记和管理被系统100的组件使用的规则中包含的各种过程在本文被称为“规则引擎”。

转换综述

基于规则的转换是对当规则评价为TRUE时产生的事件的任何修改。例如，当用户需要对事件变更表中特定列的数据类型时用户可以使用基于规则的转换。在这种情况下，转换可以是一个PL/SQL函数，该函数的输入是一个包含一列为NUMBER数据类型的逻辑变更记录(LCR)的SYS.AnyData对象，并返回一个包含相同列为VARCHAR2数据类型的LCR的SYS.AnyData对象。

根据一实施例，转换可以在下面的时间发生：

·在事件的入列过程中，它可以用于将事件格式化成适合所有目的数据库的方式。

·在事件的传播过程中，它可以用于在将数据发送到远程站点之前使数据形成子集。

·在事件出列过程中，它可以用于将事件格式化成适合特定的目的数据库的方式。

图9示出了在应用过程中基于规则的转换。

不同的信息共享综述

除了由相同公司生产的数据库之间的信息共享之外，信息共享系统100支持不同公司的数据库之间的信息共享。典型地，一个公司提供的数据库系统支持的特征不同于其它公司提供的数据库系统支持的特征。因此，在两种不同类型的数据库系统之间共享信息的任务可能是非常复杂的。下面将更加详细地描述，信息共享系统100可以被利用来极大地便于这种不同的数据库系统之间的信息共享。

为了描述信息共享系统100如何用于在不同的数据库之间共享数据，应该假定数据应该在Oracle数据库服务器和非-Oracle数据库服务器之间被共享。然而，本文所述的方法不局限于这种情形。因此应用这些方法的不同系统内的数据库的实际类型可以从一个实现到另一个实现变化。

出于解释的目的，初始产生将被传送到其它数据库系统的信息的数据库系统本文被称作“源”数据库。相反，接收共享信息的数据库系统被称作“目的”数据库。如果Oracle数据库是源以及非-Oracle数据库是目的地，那么非-Oracle数据库目的地将通常缺乏信息共享系统100的以下组件：接收事件的队列、以及出列和应用事件的应用过程。

为了与非-Oracle目的数据库共享Oracle源数据库的DML变更，Oracle数据库作为代理并执行一些通常在目的数据库进行的步骤。也就是，使用于非-Oracle目的数据库的事件在Oracle数据库本身内出列，在Oracle数据库的应用过程使用不同服务，通过网关、跨越一条网络连接将事件应用到非-Oracle数据库。图10示出了与非-Oracle数据库共享数据的Oracle数据库。

根据一实施例，制定应用程序(custom appliaction)被用于捕获和将变更从非-Oracle数据库传播到Oracle数据库。该应用程序通过使用触发器或某种其它方法，从事务日志读取对非-Oracle数据库的变更。该应用程序集合并将事务排序，将每个变更转换成逻辑变更记录(LCR)。然后，通过使用PL/SQL接口，该应用程序使LCR排队进入Oracle数据库中的一个队列，在那儿它们可以被应用过程处理。图11示出了非-Oracle数据库与Oracle数据库共享数据。

图12示出了信息共享系统100如何用于在单一数据库内共享信息，而图13A和13B示出了信息共享系统100如何用于在两个不同的数据库之间共享信息。

应该提到图13A和13B中示出的信息共享操作中包含的各种组件中的每一个组件都可以根据储存在规则引擎中的规则集操作。例如，用于捕获源数据库作出的变更的捕获过程可以根据用户登记的规则操作。在其它事情中，规则可以规定捕获哪些变更、如何转换这些变更、以及如何生成表示那些变更的LCR附加标记。类似地，传播过程、应用过程和各种处理程序过程都可以被规则驱动。

根据一实施例，这些不同的组件可以设计默认动作，它们在没有任何登记的规则集的情况下实施。

复制实例

如上所述，来自数据库服务器(下文称作“源服务器”)的重做日志的信息可以由捕获过程有选择地添加到中间存储区。然后消费过程有选择地将这种来自中间存储区的信息提供给源服务器外部的过程。变更信息可以例如被提供给不同的数据库服务器(下文称作“目标”数据库服务器)中的过程。然后目标数据库服务器中的过程使用来自源数据库服务器的变更信息来保持驻留在目标数据库的信息与源数据库服务器中的相应信息同步。例如，过程可以基于源数据库服务器中的表T2作出的变更更新目标数据库服务器中的表T1，因此T1可以作为T2的副本。

基于Oracle的重做日志和捕获过程的实例

每个Oracle数据库都有一个两个或多个重做日志文件的集合。数据库的重做日志文件统称为数据库重做日志。重做日志的主要功能是记录数据库的所有变更。

重做日志用于保证在发生人为错误或介质故障的情况下的可恢复性。根据一实施例，信息共享系统100的捕获过程作为读取数据库重做日志以捕获对数据库对象作出的DML和DDL变更的可选的Oracle后台过程来实现。当捕获过程用于从重做日志捕获变更时，产生变更的数据库被称作源数据库。

逻辑变更记录(LCR)

捕获过程将从重做日志中捕获的变更重新格式化成LCR。LCR是描述数据库变更的对象。根据一实施例，捕获过程捕获多种类型的LCR，包括行LCR和DDL LCR。

在捕获一个LCR之后，捕获过程使包含该LCR的事件排队进入一个队列。捕获过程总是与单一的SYS.AnyData队列关联，它仅仅使事件排队进入这个队列。用户可以创建多个队列并使不同的捕获过程与每个队列相关联。图3示出了捕获LCR的捕获过程。

行LCR描述了单一行中的数据的变更或行中单一LOB列的变更。变更产生于数据操纵语言(DML)语句或LOB的分段更新。例如，DML语句可以将多行插入或合并入一个表，可以更新表中的多个行，或可以从表中删除多个行。因此，单一DML语句可以生成多个行LCR。也就是，捕获过程为由DML语句变更的每行创建一个LCR。而且，DML语句本身可以是包括多条DML语句的事务的一部分。

被捕获的行LCR也可以包括事务控制语句。这些行LCR包含诸如COMMIT和ROLLBACK的指令。这些行LCR是内部的，被应用过程使用来保持源数据库和目的数据库之间的事务的一致性。

根据一实施例，每行LCR都包含下面的信息：

·发生行变更的源数据库的名称

·产生变更、或者INSERT、UPDATE、DELETE、LOB ERASE、LOB WRITE或LOB TRIM的DML语句的类型

·包含变更的行的表的模式名称

·包含变更的行的表的名称

·可以用于跟踪LCR的原标记

·运行DML语句的事务的标识符

·当变更被写入重做日志时的系统变更号(SCN)

·与变更有关的旧值。如果DML语句的类型是UPDATE或DELETE，那么这些旧值包括在DML语句之前的变更行中的一些或所有列。如果DML语句的类型是INSERT，那么没有旧值。

·与变更有关的新值。如果DML语句的类型是UPDATE或INSERT语句，那么这些新值包括在DML语句之后的变更行中的一些或所有列。如果DML语句的类型是DELETE，那么没有新值。

DDL LCR描述了数据定义语言(DDL)变更。DDL语句改变了数据库的结构。例如，DDL语句可以创建、改变或删掉一个数据库对象。

根据一实施例，每个DDL LCR都包含下面的信息：

·发生DDL变更的源数据库的名称

·生成变更(例如ALTER TABLE或CREATE INDEX)的DDL语句的类型

·拥有运行DDL语句的数据库对象的用户的模式名称

·在其上运行DDL语句的数据库对象的名称

·在其上运行DDL语句的数据库对象(例如TABLE或PACKAGE)的类型

·DDL语句的文本

·登录用户是其会话执行DDL语句的用户

·如果没有为DDL文本中的对象指定模式而使用的模式

·基表所有者。如果DDL语句依赖于一个表，那么基表所有者是DDL语句依赖的表的所有者。

·基表名称。如果DDL语句依赖于一个表，那么基表名称是DDL语句依赖的表的名称。

·可以被用于跟踪LCR的原标记

·运行DDL语句的事务的标识符

·当变更写入重做日志时的SCN

捕获规则

根据一实施例，信息共享系统100内的捕获过程(例如捕获过程116)基于用户定义的规则捕获变更。每个规则指定了数据库对象，捕获过程为数据库对象捕获变更以及要捕获的变更的类型。在一实施例中，用户可以指定下面几个等级的捕获规则：

·表格规则，捕获特定表的DML或DDL变更。

·模式规则，捕获特定模式中的数据库对象的DML或DDL变更。

·全局规则，捕获数据库中的所有DML或所有DDL变更。

捕获过程规则评价

一个正在运行的捕获过程完成下面一系列的动作以捕获变更：

1.查找重做日志中的变更。

2.执行预过滤重做日志中的变更。在这一步骤过程中，捕获过程评价在对象级和模式级的规则集中的规则，把重做日志中发现的变更分成两类：应该转换成LCR的变更和不应该转换成LCR的变更。

预过滤是对不完整的信息所做的安全的最佳方法(safeoptimization)。这一步骤识别随后将被处理的相关变更，使得：

如果一个或多个规则可以在转换之后评价为TRUE，变更转换成LCR。

如果捕获过程可以保证没有规则在转换之后评价为TRUE，变更不转换成LCR。

3.基于预过滤(prefiltering)，将可以导致一个或多个规则评价为TRUE的变更转换成LCR。

4.执行LCR过滤。在这一步骤过程中，捕获过程评价有关每个LCR中的信息的规则，以将LCR分成两类：应该入列的LCR和应该删除的LCR。

5.删除基于规则不应该入列的LCR。

6.使剩下被捕获的LCR排队进入与捕获过程有关的队列。

例如，假设为捕获过程定义了下面的规则：捕获其中department-id为50的hr.employees表的变更。没有为捕获过程定义其它的规则，捕获过程的对应参数被设置为1。

给定这一规则，假设在hr.employees表上的UPDATE语句改变了表中的50行。捕获过程为每行变更执行下面一系列的动作：

1.在重做日志中查找由UPDATE语句引起的下一次变更。

2.确定由UPDATE语句引起的hr.employees表的变更必须被捕获。如果不同的表发生变更，那么捕获过程忽略这一变更。

3.捕获变更并把它转换成LCR。

4.过滤LCR以确定它是否包含department id为50的行。

5.如果它包含department-id为50的行，使LCR排队进入与捕获过程有关的队列，或如果它包含department-id不为50或空白的行，删除LCR。

事件存储和传播综述

信息共享系统100使用类型为SYS.AnyData的队列以储存事件。有两种类型的事件可以储存在一个队列中：逻辑变更记录(LCR)和用户消息。LCR是包含关于数据库对象的变更的信息的对象，而用户消息是由用户或应用创建的定制消息(custommessages)。两种类型的事件均为SYS.AnyData类型，可以用于单一数据库内或数据库之间的信息共享。

储存的事件可以被消费或传播或者两者均可。这些事件可以由一个应用过程或一个使它们显式出列的用户应用程序消费。即使在一个事件被消费之后，如果用户也配置了信息共享系统100来将事件传播到一个或多个其它队列或者如果指定消息保持，它仍然可以保留在队列中。这些其它的队列可以驻留在相同数据库或不同数据库中。在任何一种情况下，从其传播事件的队列被称作源队列，接收事件的队列被称作目的队列。在源队列和目的队列之间可以有一对多、多对一或多对多的关系。图4示出了从源队列到目的队列的传播。

根据一实施例，信息条目的顺序在数据条目的传播过程中被保持。当条目的顺序具有功能分支时，保持顺序是非常有用的。例如，如果正被传播的条目是数据库系统的变更，保持顺序是重要的，以使在它们依赖的被传播的变更之后，对目标系统作出被传播的变更。

用户可以创建、改变和删掉一个传播，用户可以定义控制传播哪些事件的传播规则。拥有源队列的用户是传播事件的用户。该用户必须拥有传播事件所必要的特权。这些特权包括：

·在传播使用的规则集上执行特权

·在规则集中使用的所有转换功能上执行特权(privilege)

·如果目的队列在相同的数据库中，在目的队列上使特权入列。

被捕获和被用户入列的事件

根据一实施例，事件可以以两种方式入列：

·捕获过程使被捕获的变更以包含LCR的事件的形式入列。包含一个最初被捕获过程捕获和入列的LCR的事件被称作被捕获的事件。

·用户应用程序使类型为SYS.AnyData的用户消息入列。这些用户消息可以包括LCR或任何其它类型的消息。被用户或应用显式入列的任何用户消息或应用程序被称作被用户入列的事件。通过从应用过程调用的用户程序入列的事件也是被用户入列的事件。

因此，每个被捕获的事件都包含一个LCR，但被用户入列的事件可以或不可以包含LCR。传播一个被捕获的事件或被用户入列的事件使事件进入目的队列。

根据一实施例，事件可以以两种方式出列：

·应用过程使被捕获的或被用户入列的事件出列。如果事件包括LCR，那么应用过程可以直接应用它或调用一个用户指定的程序用于处理。如果事件不包括LCR，那么应用过程可以调用被称作消息处理程序的用户指定的程序来处理它。

·用户应用程序显式地使被用户入列的事件出列并处理它们。用户应用程序不能使被捕获的事件出列；它们必须通过应用过程出列。然而，如果被应用过程调用的用户程序显式地使一个事件入列，那么该事件是被用户入列的事件且可以被显式地出列，即使事件最初是一个被捕获的事件。

被出列的事件可能已经在与它们被出列数据库的相同的数据库产生，或它们可以产生于不同的数据库。

队列之间的事件传播

用户可以使用信息共享系统100来配置在两个队列之间的事件传播，两个队列可以驻留在不同的数据库。信息共享系统100使用作业队列来传播事件。

根据一实施例，传播是在源队列和目的队列之间。虽然传播是在两个队列之间，但单一队列可以参与许多传播过程。也就是，单一源队列可以将事件传播到多个目的队列，且单一目的队列可以接收来自多个源队列的事件。根据一实施例，在特定的源队列和特定的目的队列之间仅允许存在一个传播过程。单一队列也可以是用于一些传播过程的目的队列以及是用于其它传播过程的源队列。

传播过程可以将源队列中的所有事件传播到目的队列，或传播过程可以仅仅传播事件的一个子集。单一传播过程也可以传播被捕获的和被用户入列的事件。用户可以使用规则来控制源队列中的哪些事件被传播到目的队列。

根据用户如何建立信息共享系统100环境，可以将变更发送回它们产生的站点。用户需要保证环境被配置来避免在无限循环中循环变更。用户可以使用标记来避免这种变更循环。

传播规则

传播过程基于用户定义的规则传播事件。对于事件，每个规则指定了传播过程传播的变更所针对的数据库对象以及要传播的变更的类型。用户可以为事件指定下面几个等级的传播规则：

·表格规则，传播特定表格的DML或DDL变更。

·模式规则，传播特定模式中的数据库对象的DML或DDL变更。

·全局规则，传播源队列中的所有DML或所有DDL变更。

对于非-LCR事件和具有特殊需要的LCR事件，用户可以创建它们自己的规则来控制传播过程。

指定一个条件的队列订阅者导致系统生成一个规则。一个队列的所有订阅者的规则集被结合进单一系统生成的规则集，使订阅更高效。

应用过程综述

根据一实施例，应用过程是使逻辑变更记录(LCR)和来自一特定队列的用户消息出列或直接应用每一个或者将之作为参数传送给用户定义的程序的后台过程。被应用过程出列的LCR包含应用过程可以应用于目的数据库中的数据库对象的数据操纵语言(DML)变更或数据定义语言(DDL)变更。被应用过程出列的用户定义的消息属于SYS.AnyData类型，可以包含任何用户消息，包括用户创建的LCR。

应用过程应用的事件被应用用户应用。该应用用户是应用所有的DML语句和DDL语句以及运行用户定义的应用处理程序的用户。

应用规则

应用过程基于用户定义的规则应用变更。每个规则指定了应用过程将变更应用到其的数据库对象以及所应用的变更类型。用户可以指定下面等级的应用规则：

·表格规则，对特定表应用DML或DDL变更。子集规则是包括对特定表格的变更子集的表格规则。

·模式规则，对特定模式中的数据库对象应用DML或DDL变更。

·全局规则，在与应用过程相关联的队列中应用所有DML或所有DDL变更。

对于非-LCR事件和具有特殊需要的LCR事件，用户可以创建它们自己的规则来控制应用过程的行为。

利用应用过程的事件处理

应用过程是一种用于处理队列中事件的灵活的机制。用户具有选项，以考虑用户何时为你的环境配置一个或多个应用过程。这部分讨论应用过程可以应用的事件的类型和它可以应用它们的方式。

根据一实施例，单一应用过程可以应用被捕获的事件或被用户入列的事件，但不是两者。如果目的数据库的队列包含被捕获的和被用户入列的事件，那么目的数据库必须具有至少两个应用过程来处理事件。

根据一实施例，当用户创建应用过程时，用户使用应用被捕获的参数(a apply captured parameter)指定应用过程是否应用被捕获的或被用户入列的事件。

产生事件的数据库对于用于被捕获的事件而不是用于被用户入列的事件的应用过程很重要。对于一个被捕获的事件，源数据库是重做日志中产生变更的数据库。根据一实施例，对于被用户入列的事件，应用过程忽略关于事件产生的数据库的信息，即使事件是被用户入列的LCR。单一应用过程可以应用在不同数据库产生的被用户入列的事件。

事件处理选项

用于事件处理的选项依赖于应用过程接收的事件的种类。图8示出了应用过程的事件处理选项。

来自多个数据库的捕获的LCR可以被发送到单一目的队列。如果单一队列包含来自多个数据库的捕获的LCR，那么一个或多个应用过程可以被用于获取这些LCR。当使用多个应用过程时，这些应用过程中的每一个应用过程都可以用于使用规则接收来自恰好一个源数据库的捕获的LCR。

如果在源数据库上运行多个捕获过程，以及来自一个以上这些捕获过程的LCR被应用在目的数据库，那么一个或多个应用过程可以用于应用变更。

用户可以配置应用过程来以下面的方式处理包含LCR的被捕获的或被用户入列的事件：直接应用事件或将事件作为参数传送给用户程序用于处理。下面的部分解释了这些选项。

直接应用LCR事件：如果用户使用这一选项，那么应用过程应用该事件而不必运行用户程序。应用过程或者成功地将LCR中的变更应用于数据库对象，或者如果遇到冲突或应用错误，设法利用冲突处理程序或被称作错误处理程序的用户指定的程序来解决错误。

如果冲突处理程序可以解决冲突，那么它应用LCR或者删掉LCR中的变更。如果错误处理程序可以解决错误，那么如果适当的话，它应该应用LCR。错误处理程序可以通过在应用LCR之前修改它来解决错误。如果错误处理程序不能解决错误，那么应用过程将事务以及与该事务有关的所有LCR放入异常队列中。

调用用户程序来处理LCR事件：如果用户使用这一选项，那么应用过程将该事件作为一个参数传送给用户程序用于处理。用户程序然后可以以定制的方式处理事件。

处理由DML语句产生的行LCR的用户程序被称作DML处理程序，而处理由DDL语句产生的DDL LCR的用户程序被称作DDL处理程序。应用过程可以拥有许多DML处理程序和DDL处理程序。

对于与应用过程有关的每一个表格，用户可以设置一个单独的DML处理程序处理行LCR中每一个下面类型的操作：

INSERT UPDATE DELETE LOB UPDATE

例如，hr.employees表可以有一个DML处理程序处理INSERT操作以及一个不同的DML处理程序处理UPDATE操作。

用户程序可以用于任何定制的LCR处理。例如，如果用户需要每次在源数据库插入特定表都导致在目的数据库插入多个表，那么用户为完成这一目标可以创建处理在处理表上的INSERT操作的用户程序。或者，如果用户想要在应用它们之前将DDL变更记入日志，那么用户为完成这一目标可以创建处理DDL操作的用户程序。

非-LCR用户消息处理

不包含LCR的被用户入列的事件由被指定用于应用过程的消息处理程序处理，如果被用户入列的事件满足用于应用过程的规则集中的至少一个规则。消息处理程序是一个可以为你的环境以定制的方式处理非-LCR用户消息的用户定义的程序。

消息处理程序在任何具有需要更新一个或多个远程数据库或执行某种其它远程动作的应用的环境下提供优势。这些应用程序可以使用户消息进入本地数据库的队列，信息共享系统100可以将每个用户消息传播到目的数据库的适当的队列。如果存在多个目的地，那么信息共享系统100为自动传播和处理这些目的地的消息提供基础设施(infrastructure)。如果仅有一个目的地，那么信息共享系统100还在源数据库的应用程序和目的数据库的应用程序之间提供一层，因此，如果远程数据库的应用程序变得不可使用，那么源数据库的应用程序可以继续正常起作用。

例如，消息处理程序可以将用户消息格式化成电子邮件消息。在这种情况下，用户消息可以包含用户将在电子邮件消息中期望的属性，诸如从、到、主题、消息文本等。消息处理程序可以将这些用户消息转换成电子邮件消息并将它们通过电子邮件网关发送出去。

应用过程组件

根据本发明的一实施例，应用过程包括读者服务器(readerserver)、协调过程(coordinator process)和一个或多个应用服务器。

读者服务器使事件出列。读者服务器是计算LCR之间相关性以及将事件集合到事务中的并行执行服务器。然后读者服务器将集合的事务返回协调器，协调器将它们指定为空闲的应用服务器。

协调过程从读者服务器获得事务并将它们传送给应用服务器。应用服务器将LCR作为DML或DDL语句应用到数据库对象或者将LCR传送到它们适当的处理程序。对于非-LCR消息，应用服务器将事件传送给消息处理程序。每个应用服务器都是并行执行服务器。如果应用服务器遇到错误，那么它试图利用用户指定的错误处理程序解决错误。如果应用服务器不能解决错误，那么它回滚事务并将整个事务(包括事件的所有)放入异常队列中。

当应用服务器提交已完成的事务时，该事务已被应用。当应用服务器将事务放入异常队列以及提交时，该事务也已被应用。

如果正被应用服务器处理的事务与另一不知已被应用的事务存在相关性，那么应用服务器联系协调器并等候指示。协调器监控所有的应用服务器以保证事务以正确的顺序被应用和提交。

例如，考虑这两种事务：

1.一行被插入到表格中。

2.相同的行被更新来变更某些列值。

在这种情况下，事务2依赖于事务1，这是因为行在被插入到表中之后才能被更新。假设这些事务从源数据库的重做日志被捕获，传播到目的数据库并在目的数据库应用。应用服务器A处理插入事务，应用服务器B处理更新事务。

如果应用服务器B在应用服务器A已应用插入事务之前准备好应用更新事务，那么应用服务器B等候来自协调器的指示。在应用服务器A已应用插入事务之后，协调过程指示应用服务器B应用更新事务。

规则组件

根据一实施例，规则是使客户端能够在事件发生以及一个条件被满足时执行一个动作的数据库对象。规则由一个规则引擎来评价，根据一实施例，规则引擎内置于管理信息共享系统100的数据库服务器中。用户创建的应用和信息共享系统100可以是规则引擎的客户端。根据一实施例，规则由下面的组件组成：

·规则条件

·规则评价环境(可选的)

·规则动作环境(可选的)

每个规则被指定作为一个类似于SQL查询的WHERE语句中的条件。用户可以将相关的规则分成规则集。单一规则可以在一个规则集中、多个规则集中或不在规则集中。

规则条件结合了一个或多个表达式和运算符并返回一个布尔(Boolean)值，该布尔值是TRUE、FALSE或NULL(未知)值。表达式是一个或多个值和求出值的运算符的结合。值可以是表中的数据、变量中的数据或被SQL函数或PL/SQL函数返回的数据。例如，下面的条件由两个表达式(department-id和30)以及一个运算符(-)组成：

department id＝30

当department-id列为30时，对于给定行，该逻辑条件评价为TRUE。在此，该值是表格的department id列中的数据。

单一规则条件可以包括一个以上与AND、OR和NOT条件运算符结合的条件来形成复合条件。例如，考虑下面的复合条件：

department id＝30 OR job_title＝′Programmer′

该规则条件包含由OR条件运算符加入的两个条件。如果两个条件的任何一个评价为TRUE，那么规则条件评价为TRUE。如果条件运算符是AND而不是OR，那么为了使整个规则条件评价为TRUE，两个条件需要都评价为TRUE。

规则条件中的变量

规则条件可以包含变量。根据一实施例，规则条件中的变量之前有一个冒号(:)。下面是规则条件中使用的变量的实例：

:x＝55

变量使用户能够指示未储存在表中的数据。一个变量也可以通过代替一个常发生的表达式提高性能。性能可以提高，这是因为变量被评价一次而不是对相同的表达式评价多次。

规则条件也可以包含对一个子程序的调用的评价。这些条件以与其它条件相同的方式被评价。也就是，它们评价的值为TRUE、FALSE或未知值。下面是一个包含确定一个雇员是否为经理的名称为is_Manager的简单函数调用的条件的实例：

is_manager(employee id)＝′Y′

在此，employee_id的值由employee_id是一个列的表中的数据确定。

用户可以使用用户定义的类型用于变量。所以，变量可以具有属性。当变量具有属性时，每个属性都包含变量的部分数据。在规则条件中，用户使用圆点符号来指定属性。例如，如果变量y的属性z的值为9，下面的条件评价为TRUE：

:y.z＝9

简单规则条件

一个简单规则条件是具有下面形式之一的条件：

·简单-规则-表达式 运算符 常数

·常数 运算符 简单-规则-表达式

规则组件

在一个简单规则条件中，简单规则表达式是下面之一：

·表列

·变量

·变量属性

·方法结果，其中方法没有自变量，方法结果可以由变量方法函数返回，因此表达式是数字类型或字符类型

对于表列、变量和变量属性，支持所有数字(NUMBER、FLOAT、DOUBLE、INTEGER)和字符(CHAR、VARCHAR2)类型。其它类型的表达式的使用导致非简单规则条件。

在简单规则条件中，运算符是下面之一：

＝，＜＝，或＞＝

其它运算符的使用导致非简单规则条件。常数是固定值。常数可以是：

数字，诸如12或5.4，字符，诸如x或$

字符串，诸如“this is a string”。所以，下面的条件是简单规则条件：tabl.col＝5

·:v1＞′aaa′

·:v2.a1＜10.01

·:v3.m()＝10

规则集评价

规则引擎基于事件评价规则集。事件是由规则引擎的客户端定义的事件。客户端通过调用DBMS-RULE.EVALUATE程序发起对事件的评价。当客户端调用DBMS-RULE.EVALUATE程序时客户指定的信息包括如下：

包含用于评价事件的规则的规则集的名称。评价环境用于评价。仅仅评价使用指定的评价环境的规则。

表值和变量值：表值包含指示表行中的数据的行标识符，变量值包含用于显式变量的数据。为隐式变量指定的值取代可能使用变量值评价函数得到的值。如果一个被指定的变量具有属性，那么客户端可以发送用于整体变量的值，或客户端可以发送用于任意数量的变量属性的值。然而，如果整体变量的值被指定，客户端不能指定属性值。

可选的事件环境：事件环境是类型为SYS.RE$NV_LIST的可变长度阵列，它包含具有相关事件的信息的名称-值对。这个可选的信息不直接被规则引擎使用或解释。而是它被传送到客户端返回调用，诸如评价函数、变量值评价函数(对于隐式变量)和可变方法函数。

客户端也可以发送其它有关事件以及如何使用DBMS-RULE.EVALUATE程序评价事件的信息。例如，调用者可以指定评价是否在发现第一TRUE规则或第一MAYBE规则(如果没有TRUE规则)时就必须停止。

规则引擎使用被指定的规则集中的规则评价事件。然后规则引擎将结果返回给客户端。规则引擎使用EVALUATE程序中的两个OUT参数返回规则：true-rules和maybe_rules。也就是，true-rules参数返回评价为TRUE的规则，可选地，maybe_rules参数返回给定更多信息时下可能评价为TRUE的规则。

图14示出了规则集评价过程：

1.客户端定义的事件发生。

2.客户端通过运行DBMS-RULE.EVALUATE程序将事件发送至规则引擎。

3.规则引擎基于规则集中的规则和相关的评价环境评价事件。客户端在对DBMS-RULE.EVALUATE程序的调用中指定规则集和评价环境。仅仅在指定的规则集中和使用指定的评价环境的规则被用于评价。

4.规则引擎获得评价的结果。每个规则都评价为TRUE、FALSE或NULL(未知)。

5.规则引擎将评价为TRUE的规则返回至客户端。每个返回的规则和它的整体动作环境一起返回，其可能包含信息或者可以为NULL。

6.客户端基于规则引擎返回的结果执行动作。规则引擎不执行基于规则评价的动作。

规则如何用于信息共享系统100综述

在信息共享系统100中，当机制与一个规则集相关时，下面的每个机制是一个规则引擎的客户端：捕获过程、传播过程和应用过程。

在一实施例中，这些机制的每一个可以与至多一个规则集相关联。然而，单一规则集可以在相同的数据库内被多个捕获过程、传播过程和应用过程使用。图15举例说明了规则引擎的多个客户端可以使用一个规则集。

特别地，用户使用信息共享系统100中的规则集做下面的事情：

(1)指定一个捕获过程从重做日志捕获的变更。也就是，如果重做日志中发现的变更导致与捕获过程相关的规则集中的任何规则评价为TRUE，那么该变更由捕获过程捕获。

(2)指定传播过程从一个队列传播到另一队列的事件。也就是，如果队列中的事件导致与传播过程相关的规则集中的任何规则评价为TRUE，那么该事件由传播过程传播。

(3)指定应用过程从一个队列中获取的事件。也就是，如果队列中的事件导致与应用过程相关的规则集中的任何规则评价为TRUE，那么该事件由应用过程获取和处理。

在传播过程或应用过程的情况下，对比规则集评价的事件可以是被捕获的事件或被用户入列的事件。

如果存在与一种机制相关的冲突规则，那么如果任一规则评价为TRUE，该机制执行该任务。例如，如果与捕获过程相关的规则集包含一个指示捕获过程捕获hr.employees表的DML变更的规则，但规则集中的另一规则指示捕获过程不捕获hr.employees表的DML变更，那么捕获过程捕获hr.employees表的DML变更。

系统创建的规则

信息共享系统100基于规则执行三种任务：利用捕获过程捕获变更，利用传播过程传播变更，以及利用应用过程应用变更。用户创建的规则和系统创建的规则均可以用于控制如何执行这些任务中的每个任务。而且，这些任务的任何一个可以被包括系统创建的规则和用户创建的规则的单一规则集控制。

系统创建的规则为一个任务指定了下面的粒度级(granularity)之一：表格、模式或全局。这部分描述了这些等级中的每一个。用户可以为特定任务指定一个以上等级。例如，用户可以指示单一应用过程对oe模式中的表执行表-级应用以及对整个hr模式执行模式-级的应用。

图6-1示出了对于每个信息共享系统100任务每个等级的规则的含义。

任务类型和规则等级

任务    表格规则             模式规则              全局规则

        捕获指定表格的重做                         捕获对数据库中

                             捕获指定模式中的数据

        日志中的变更，将它                         的所有数据库对

                             库对象在重做日志中的

捕获    们转换成逻辑变更记                         象的变更，将它们

                             变更，将它们转换成

        录(LCR)，以及使它                          转换成LCR，以

                             LCR，以及使它们入列。

        们入列。                                   及使它们入列。

        将与源队列中的指定   将与源队列中的指定模  将源队列中的所

传播    表有关的LCR传播      式中的数据库对象有关  有变更传播到目

        到目的队列           的LCR传播到目的队列   的队列

        应用与指定的表有关   应用与指定模式中的数  应用队列中的所

应用    的队列中的所有LCR    据库对象有关的队列中  有LCR

        或LCR的子集          的LCR

基于规则的转换和捕获过程

如果捕获过程使用一个规则集，那么为了在捕获过程中执行转换必须满足下面的两个条件：

对于重做日志中发现的特定变更，规则评价为TRUE。

动作环境包含一个具有一个特定的系统识别的名称的名称-值对。

当规则被评价时TRANSFORM FUNCTION返回至捕获过程。

给定这些条件，捕获过程完成下面的步骤：

1.将重做日志中的变更格式化成LCR

2.将LCR转换成SYS.AnyData对象

3.运行名称-值对中的PL/SQL函数以转换SYS.AnyData对象

4.使被转换的SYS.AnyData对象进入与捕获过程相关联的队列

图16示出了捕获过程中的转换。例如，如果一个事件在捕获过程中被转换，那么被转换的事件排队进入源队列。所以，如果这样被捕获的事件被从dbs1.net数据库传播到dbs2.net和dbs3.net数据库，那么在dbs2.net和dbs3.net的队列将在传播之后包含被转换的事件。

在捕获过程中执行转换的好处如下：

如果转换除去或改变私人信息，那么可以提高安全性，这是因为该私人信息不会在源队列中出现且不会传播到任何目的队列。

根据所执行的转换的类型，可以减少空间消费。例如，减少数据量的转换导致入列、传播和应用的数据更少。

当对于一个被转换的事件存在多个目的队列时，转换开销减少，这是因为在源队列执行转换仅仅一次，而不是在多个目的队列执行转换。

在捕获过程中执行转换的可能缺点如下：

·所有站点接收被转换的事件。

·在源数据库中发生转换开销。

·在捕获过程中发生基于规则的转换错误。

如果在捕获过程中运行转换函数时发生错误，那么变更不被捕获，错误返回至捕获过程，捕获过程失效。在捕获过程启动之前，用户必须变更或除去基于规则的转换以避免错误。

基于规则的转换和传播

如果传播过程使用规则集，那么对于在传播过程中将要执行的转换必须满足下面的条件：

·对于源队列中用于传播的事件，规则评价为TRUE。该事件可以是被捕获的事件或者是一个被用户入列的事件。

·动作环境包含具有特定的、系统识别的名称的名称-值对。

·当规则被评价时，TRANSFORM-FUNCTION返回传播过程。

给定这些条件，传播过程完成下面的步骤：

1.开始使事件从源队列出列

2.运行名称-值对中的PL/SQL函数以转换事件

3.完成使被转换的事件出列

4.将被转换的事件传播到目的队列

图17示出了传播过程中的转换。在下文给出的几个实例中，正在被转换的信息具有LCR的形式。然而，如上面所解释的，LCR仅仅是一种可以使用系统100被共享的信息的类型。这样，在此所述的各种技术，包括基于规则的转换，同样适用，而不管正被共享的信息的形式。

再次参照图17，假设用户使用基于规则的转换，用于从dbs1.net数据库到dbs2.net数据库的传播，但用户不使用基于规则的转换，用于从dbs1.net数据库到dbs3.net数据库的传播。在这种情况下，在dbs1.net的队列中的事件可以在它传播到dbs2.net之前转换，但相同的事件可以在它传播到dbs3.net时保留它的原始形式。在这种情况下，在传播之后，在dbs2.net的队列包含被转换的事件，在dbs3.net的队列包含原始事件。

传播过程中执行转换的优点如下：

如果转换在传播事件之前除去或变更私人信息，可以提高安全性。

一些目的队列可以接收被转换的事件，而其它的目的队列可以接收原始事件。

不同的目的地可以接收相同事件的不同变量。传播过程中执行转换可能的缺点如下：

一旦事件被转换，在第一个传播之后事件被传播到的任何数据库接收被转换的事件。例如，如果dbs2.net将事件传播到dbs4.net，那么dbs4.net接收被转换的事件。

当有向网络中的第一传播过程执行转换时，在源数据库上发生转换开销。

当多个目的数据库需要相同的转换时，相同的转换可以进行多次。

如果在传播过程中运行转换函数时发生错误，那么导致错误的事件不会出列，事件不会被传播，以及错误被返回传播过程。在事件可以被传播之前，用户必须改变或除去基于规则的转换以避免错误。

基于规则的转换和应用过程

如果应用过程使用规则集，那么在应用过程中将要执行的转换必须满足下面的两个条件：

·对于与应用过程相关联的队列中的事件，规则评价为TRUE。该事件可以是被捕获的事件或者是被用户入列的事件。

·动作环境包含具有特定的、系统识别的名称的名称-值对。

·当规则被评价时，TRANSFORM_FUNCTION返回应用过程。

给定这些条件，应用过程完成下面的步骤：

1.开始使事件从队列出列

2.运行名称-值对中的PL/SQL函数，以在出列过程中转换事件

3.完成使被转换的事件出列

4.应用被转换的事件

例如，假设事件以它的原始形式从dbs1.net数据库传播到dbs2.net数据库。当应用过程使事件从dbs2.net的队列出列时，事件被转换。

在应用期间执行转换的可能优点如下：

在第一传播过程之后，事件被传播到的任何数据库可以接收原始形式事件。例如，如果dbs2.net将事件传播到dbs4.net，那么dbs4.net可以接收原始事件。

当源数据库和目的数据库不同时，在源数据库上不会发生转换开销。

在应用过程中执行转换可能的缺点如下：

如果事件包含私人信息，安全性可能是一个值得关注的事，这是因为事件被传播到的所有数据库接收原始事件。

当多个目的数据库需要相同的转换时，相同的转换可以进行多次。

在应用过程出列过程中的基于规则的转换错误

如果在应用过程出列过程中运行转换函数时发生错误，那么导致错误的事件不会出列，包含事件的事务不会被应用，错误返回应用过程，以及应用过程失效。在应用过程启动之前，用户必须变更或除去基于规则的转换以避免错误。

与网关集成

根据一实施例，通过(1)读取LCR来识别LCR中反映的变更，(2)构造一个将导致需要的变更的数据库命令(例如一个SQL命令)，以及(3)对数据库执行数据库命令，应用过程可以用于将LCR的集合“应用”到数据库。

根据一实施例，应用过程可以用于为不同于最初作出反映在LCR中的变更的数据库构造一个远程SQL语句。当在远程数据库内执行时，SQL语句将导致在远程数据库上作出需要的变更。

一旦这种远程SQL语句被构造，SQL语句可以通过网关发送到远程数据库。例如，必要时，当远程数据库是一种不同于源数据库类型的数据库时，网关可以用于转换查询。例如，响应于Oracle数据库中作出的变更，创建LCR的集合。基于LCR，应用过程可以构造一个远程SQL查询，将SQL查询发送给网关。然后必要时，网关可以在将查询转发给非-Oracle数据仓库之前转换SQL。然后，响应于最初基于Oracle数据库作出的变更的LCR，非-Oracle数据仓库可以执行查询，以异步地和远程地实现变更。

与闪回集成

各种数据库语言，诸如SQL(结构化查询语言)，支持在本文称作“指针(cursors)”的特殊目的的结构。在获取特定的查询语句的结果之前，DBMS可以为语句(诸如句法分析、语义分析和查询计划产生)执行大量的预备工作。指针储存这个预备工作多数的结果。因此，当查询语句到达时，DBMS先试图使该语句与已经为其创建指针的语句匹配。如果发现匹配，指针被查询语句共享，开销工作被避免。

“闪回指针”是用于存取过去数据的特定类型的指针。响应于“闪回查询”的接收，创建闪回指针。不像传统的查询，闪回查询指定闪回时间，并在指定的闪回时间数据存在时返回数据。一项用于处理闪回查询的技术在JONATHAN D.KLEIN等人于2000年9月29日提交的标题为“用于提供精细度的暂时数据库存取的系统和方法(SYSTEM AND METHOD FOR PROVIDINGFINE-GRAINED TEMPORAL DATABASE ACCESS)”的第No.09/676,305号专利申请中加以描述，该申请的内容结合于此作为参考。

根据一实施例，闪回查询和指针可以与信息共享系统100结合使用，以确定如何以下面的方式处理变更：(1)与变更异步，以及(2)在变更的同时考虑系统的状态。

例如，假设用户在时刻T10对源数据库作出变更，该变更反映在源数据库的重作日志中。最终，捕获过程读取日志以及产生对应于该变更的LCR。然后将LCR储存在中间存储区。

根据一实施例，在源数据库保持(提交)变更的时刻被储存在LCR中。最终，应用过程读取LCR并将之传送给更新处理程序。到更新处理程序接收LCR的时刻，系统的状态相对于时刻T10的系统的状态发生了极大地改变。更新处理程序可以从LCR读取变更时间T10并执行闪回查询，以查看数据库系统在初始发生变更的时刻(在时刻T10)存在的状态。然后，响应于基于在T10的数据库系统的条件的变更，更新处理程序可以决定采取什么动作。

闪回查询一般能够将相同类型的操作指定为标准查询。因此，更新处理程序查看系统的前面状态所使用的闪回查询可以包括利用在那个前面的时刻存在的值执行复杂的操作。例如，闪回查询可以执行复杂的结合和比较，这些结合和比较均将根据前一个时刻存在的数据值执行，以确定响应于识别在该前一时刻所作的变更的LCR采取什么动作。

标记和循环避免

如上所述，可以配置信息共享系统100的各种组件，使得特定的事件主要启动一个复杂的活动链。由于链中的每个活动(例如，事件从一个中间存储区到另一中间存储区的传播)本身可以启动另一活动链，循环有可能形成。例如，假设信息共享系统100的组件用于将对第一数据库作出的变更传播到第二数据库，并将对第二数据库作出的变更传播到第一数据库。在这种情形下，与第一数据库中的变更相关联的事件将被传播并应用到第二数据库。然而，第二数据库的事件的应用程序将组成对第二数据库的变更。用于第二数据库的该变更的事件将(没有用于循环避免的机制)被传播回以及应用于第一数据库。第二数据库的事件的应用程序将组成对第一数据库的“变更”，这将导致整个过程自我重复。根据一实施例，信息共享系统100的各种组件以避免延续这种循环的方式设置标记并检查标记。

对标记的介绍

根据一实施例，重作日志中的每个重作输入有一个与之相关联的标记。标记的数据类型是RAW。默认地，当用户或应用程序产生重作输入时，对于每个重作输入，标记的值为NULL。NULL标记不占用重作输入的空间。

机制被提供以允许用户配置信息共享系统100的组件来定制组件在信息共享操作中的各种阶段如何(1)设置标记值、(2)检查标记值、以及(3)解释和使用标记值。例如，标记可以用于决定LCR是否包含产生于本地数据库或不同数据库的变更，因此用户可以避免变更循环(把LCR发送回产生它的数据库)。标记也可以用于其它LCR跟踪目的。用户也可以使用标记为每个LCR指定目的数据库集合。

根据一实施例，各种机制被提供以允许用户控制重作日志中产生的标记值。这些机制包括但不局限于下文称作SET_TAG、CREATE_APPLY以及ALTER_APPLY的程序。

SET_TAG程序用于指定目前会话中产生的重作日志的值。当在会话中作出数据库变更时，标记成为记录变更的重作输入的一部分。不同的会话可以有相同的标记设置或不同的标记设置。

CREATE_APPLY以及ALTER_APPLY程序用于控制在应用过程运行时产生的重作标记的值。被应用过程协调器协调的所有会话使用这一标记设置。默认地，由应用过程产生的重作输入有一个为十六进制的′00′(双零)的标记值。

这些标记成为被捕获过程从重作日志获取变为所捕获的LCR的一部分。基于用于捕获过程的规则集中的规则，用于变更的重作输入中的标记值可以确定是否捕获变更。

类似地，一旦标记是LCR的一部分，标记值可以确定传播过程是否传播LCR以及应用过程是否应用LCR。转换、DML处理程序或错误处理程序的行为也可以根据标记值作出。另外，用户可以使用用于LCR的SET TAG组成程序为现有的LCR设置标记值。例如，用户可以在转换过程中在LCR中设置标记。

根据一实施例，用户创建规则，默认地只有标记为NULL时，每个规则包含一个评价为TRUE的条件。在DML规则中，条件如下：

:dml.is null tag()＝′Y′

在DDL规则中，条件如下：

:ddl.is null tag()＝′Y′

考虑具有单一规则的规则集，并假设该规则包含这一条件。在这种情况下，捕获过程、传播过程和应用过程表现为如下方式：

·只要重做日志中用于变更的标记为NULL以及其它规则条件对该变更评价为TRUE，捕获过程捕获该变更。

·只要LCR中的标记为NULL以及其它规则条件对LCR评价为TRUE，传播过程传播包含LCR的事件。

·只要LCR中的标记为NULL以及其它规则条件对LCR评价为TRUE，应用过程应用包含LCR的事件。

特别地，下面的程序被提供以默认地创建包含下面条件之一的规则：

·ADD_GLOBAL_PROPAGATION_RULES

·ADD_GLOBAL_RULES

·ADD_SCHEMA_PROPAGATION_RULES

·ADD_SCHEMA_RULES

·ADD_SUBSET_RULES

·ADD_TABLE_PROPAGATION_RULES

·ADD_TABLE_RULES

如果用户不需要创建的规则包含这一条件，那么他们可以当用户运行这些程序时，设置include_tagged_lcr参数为真。这种设置导致没有与规则中的标记相关的条件。所以，LCR的规则评价不依赖于标记的值。

例如，考虑将在dbs1.net源数据库产生的hr.locations表的所有的DML变更评价为TRUE的表-级规则。假设运行ADD_TABLE_RULES程序产生该规则：

BEGIN

 DBMS_STREAMS_ADM.ADD_TABLE_RULES(

    Table_name          ＝>  ′hr.locations′，

    streams_type        ＝>  ′capture′，

    streams_name        ＝>  ′capture′，

    queue_name          ＝>  ′streams_queue′，

    include_tagged_lcr  ＝>  false，--注意参数设置

    source_database     ＝>  ′dbs1.net′，

    include_dml         ＝>  true，

    include_ddl         ＝>  false)；

END；

注意include_tagged_lcr参数被设置为假，该设置是默认的。ADD_TABLE_RULES程序利用类似于下面的规则条件生成一个规则：

(((:dml.get_object_owner()＝′HR′and:dml.get_object_name()＝′LOCATIONS′))and:dml.is_null_tag()＝′Y′and:dml.get_source_database_name()＝′DBS1.NET′)

如果捕获过程使用包含该规则的规则集，那么如果用于重做输入中的变更的标记是非-NULL值，诸如′0′或′1′，该规则评价为FALSE。因此，如果重做输入包含对hr.locations表的行变更，那么只要用于重做输入的标记为NULL，该变更被捕获。

然而，假设当运行ADD_TABLE_RULES时，include_tagged_lcr参数被设置为TRUE：

BEGIN

 DBMS_STREAMS_ADM.ADD_TABLE_RULES(

    table_name          ＝>  ′hr.locations′，

    streams_type        ＝>  ′capture′，

    streams_name        ＝>  ′capture′，

    queue_name          ＝>  ′streams_queue′，

    include_tagged_lcr  ＝>  true，--注意参数设置

    source_database    ＝>  ′dbs1.net′，

    include_dml        ＝>  true，

    include_ddl        ＝>  false)；

END；

在这种情况下，ADD_TABLE_RULES程序利用类似于下面的规则条件生成一个规则：

(((:dml.get_object_owner()＝′HR′and:dml.get_object_name()＝′LOCATIONS′))and:dml.get_source_database_name()＝′DBS1.NET′)

注意没有与该标记有关的条件。如果捕获过程使用包含该规则的规则集，那么如果hr.locations表的DML变更的重做输入中的标记是非-NULL值，诸如′0′或′1′，该规则评价为TRUE。如果标记为NULL，该规则也评价为TRUE。因此，如果一个重做输入包含对hr.locations表的DML变更，那么该变更被捕获而不管标记的值。

如果用户正使用全局规则捕获和应用整个数据库的DDL变更，那么联机备份语句将默认地被捕获、传播和应用。典型地，数据库管理员不需要复制联机备份语句。相反，他们仅仅需要联机备份语句在它们最初被执行的数据库上运行。为避免复制联机备份语句，用户可以使用下面策略之一：

·包括一个或多个对在用户联机备份程序中的SET TAG程序的调用，将会话标记设置为一个将导致联机备份语句被捕获过程忽略的值。

·使用应用过程的DDL处理程序以避免应用联机备份语句。

标记和应用过程

当应用过程应用DML或DDL变更时，它在目的数据库的重做日志中生成输入。例如，如果应用过程应用更新表中一行的变更，那么该变更被记录在目的数据库的重做日志中。用户可以通过设置在DBMS_APPLY_ADM包中的CREATE_APPLY或ALTER_APPLY程序中的apply_tag参数控制这些重做输入中的标记。例如，应用过程可以生成等于十六进制值′0′(零)或′1′的重做标记。

由应用过程在重做日志中生成的默认标记值是′00′(双零)。如果用户使用程序创建应用过程，该值是应用过程的默认的标记值。除了该值是非-NULL值之外，该值没有特殊之处。该值是非-NULL值是重要的，这是因为由某些过程默认地创建的规则包含一个条件，只有标记在重做输入或LCR中为NULL，该条件才评价为TRUE。用户在使用ALTER_APPLY程序中可以为现有的应用过程变更标记值。

如果DML处理程序、DDL处理程序或消息处理程序调用SET_TAG程序，那么由处理程序生成的任何随后的重做输入将包括在SET_TAG调用中指定的标记，即使用于应用过程的标记不同。当处理程序退出时，由应用过程生成的任何随后的重做输入具有为应用过程指定的标记。

利用标记避免变更循环

在包括一个以上双向共享数据的数据库的环境中，用户可以使用标记避免变更循环。变更循环意味着将变更发送回产生变更的数据库。通常，变更循环应该被避免，这是因为它可以导致每个变更通过无限循环返回到产生它的数据库。这种循环可以导致数据库中产生的不需要数据，并给网络和环境的计算机资源增加负担。

使用标记和适当的规则用于捕获过程、传播过程和应用过程，用户可以避免这种变更循环。下面的部分描述各种环境以及标记和规则如何可以被用于避免在这些环境中的变更循环：

·每个数据库都是用于共享的数据的源和目的数据库

·主数据库与几个从属数据库共享数据

·主数据库与几个扩展的从属数据库共享数据

每个数据库都是用于共享的数据的源和目的数据库

该情形包括一种环境，在该环境下，每个数据库都是对于每个其它数据库的源数据库，每个数据库都是每个其它数据库的目的数据库。每个数据库都与每个其它数据库直接通信。

例如，考虑一种在三个Oracle数据库：mult1.net、mult2.net和mult3.net之间复制hr模式中的数据库对象和数据的环境。对hr模式中的表的DML和DDL作出的变更在该环境中的所有三个数据库被捕获并传播到环境中的每个其它数据库。图18A-18C举例说明了一个其中每个数据库都是源数据库的环境的实例。

用户可以通过以下面的方式配置这种环境来避免变更循环：在每个数据库配置一个应用过程来为来自每个源数据库的变更生成非-NULL重做标记。如果用户使用一个程序创建应用过程，那么应用过程默认地在重做日志中生成具有一个值′00′的非-NULL标记。在这种情况下，应用过程不要求进一步的动作以生成非-NULL标记。

如果用户使用CREATE_APPLY程序，那么不设置应用标记参数。此外，应用过程默认地在重做日志中生成具有值′00′的非-NULL标记，且不要求进一步的动作。

只要用于该变更的重做输入中的标记为NULL，在每个数据库配置捕获过程以捕获变更。用户通过保证捕获过程使用的规则集中的每个DML规则都具有下面的条件来实现这一目标：

:dml.is is_null_tag′Y′

每个DDL规则应该具有下面的条件：

:ddl.is_null_tag()＝′Y′

这些规则条件表明，只要变更的标记为NULL，捕获过程就捕获一个变更。

该配置阻止了变更循环，这是因为应用过程所应用的所有变更决不会被重新捕获(它们初始在源数据库被捕获)。每个数据库都将它对hr模式的所有变更发送到每个其它数据库。因此，在这种环境下，没有变更被丢失，使所有数据库同步。图19举例说明了标记如何可以被用于多源环境中的数据库中。

主数据库与几个从属数据库共享数据

该情形包含一种信息共享系统100环境，在该环境下，一个数据库是主数据库，该主数据库与几个从属数据库共享数据。从属数据库仅仅与主数据库共享数据。从属数据库不直接互相共享数据，但相反，通过主数据库间接地互相共享数据。该类型的环境有时被称作“轮轴和轮辐”环境，主数据库是轮轴，从属数据库是轮辐。

在这种环境下，变更以下面的方式被捕获、传播和应用：

主数据库捕获对共享数据的本地变更并将这些变更传播到所有的从属数据库，其中，这些变更被本地应用在每个从属数据库。

每个从属数据库捕获对共享数据的本地变更并将这些变更仅仅传播到主数据库，其中，这些变更被本地应用在主数据库。

主数据库本地应用来自每个从属数据库的变更。那么，这些变更在主数据库被捕获并传播到所有的从属数据库(除了产生变更的那个数据库)。在这些变更已经通过主数据库之后，每个从属数据库本地应用来自其它从属数据库变更。该配置是应用转递的一个实例。

一个可供替换的情形可以使用队列转发。如果该环境使用队列转发，那么应用在主数据库的来自从属数据库的变更不会在主数据库上被捕获。相反，这些变更被从主数据库的队列转发到所有从属数据库(除了那个产生该变更的从属数据库)。

例如，考虑在名称为ps1.net的主数据库和三个名称为ps2.net、ps3.net和ps3.net的从属数据库之间复制hr模式中的数据库对象和数据的环境。hr模式中的表的DML和DDL变更被捕获于环境中的主数据库和三个从属数据库。那么，这些变更如之前所描述的被传播和应用。该环境使用应用转发，不是队列转发，以通过主数据库在从属数据库之间共享数据。图20举例说明了一个具有一个主数据库和多个从属数据库的环境的实例。

用户可以通过以下方式配置环境来避免变更循环：在主数据库ps1.net配置每个应用过程，以生成表明它正接收的变更来自的站点的非-NULL重做标记。在这个环境下，主数据库具有至少一个它接收的变更来自的每个从属数据库的应用过程。例如，如果主数据库上的应用过程接收来自ps2.net从属站点的变更，那么该应用过程可以为它应用的所有变更生成一个等于十六进制′2′的原始值。用户通过把DBMS_APPLY_ADM包中的CREATE_APPLY或ALTER_APPLY程序中的应用标记参数设置为非-NULL值实现这一目标。

例如，运行下面的程序以创建一个生成具有等于十六进制值′2′的标记的重做输入的应用过程。

BEGIN

 DBMS_APPLY_ADM.CREATE_APPLY(

    queue_name     ＝>  ′strmadmin.streams_queue′，

    apply_name     ＝>  ′apply_ps2′，

    rule_set_name  ＝>  ′strmadmin.apply_rules-ps2′，

    apply tag      ＝>  HEXTORAW(′2′)，

    apply_captured＝>true)；

END；

在每个从属数据库配置应用过程以生成非-NULL重做标记。只要标记的确切值为非-NULL，则它是无关紧要的。在该环境下，每个从属数据库具有一个应用来自主数据库的变更的应用过程。

如果用户使用在DBMS INFORMATION SHARING SYSTEM100 ADM包中的一个程序来创建应用过程，那么该应用过程默认地在重做日志中生成具有值′00′的非-NULL标记。在这种情况下，应用过程不要求进一步的动作来生成非-NULL标记。

例如，假设在从属数据库不存在应用过程，在每个从属数据库运行ADD_SCHEMA_RULES程序以创建一个生成具有等于十六进制值′00′的标记的非-NULL重做输入的应用过程。

BEGIN

 DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(

    schema_name      ＝> ′hr′，

    streams_type     ＝> ′apply′，

    streams_name     ＝> ′apply′，

    queue_name       ＝> ′strmadmin.streams_queue′，

    include_dml      ＝> true，

    include_dml      ＝> true，

    source database  ＝> ′ps1.net′)；

END；

配置主数据库的捕获过程以捕获对共享数据的变更而不考虑标记。当用户运行生成捕获规则的程序之一时，用户通过将include_tagged_lcr参数设置为真(true)实现这一目标。如果用户为主数据库的捕获过程创建规则，那么保证这些规则不包含is_null_tag条件，这是因为这些条件包含重做日志中的标记。

例如，在主数据库运行下面的程序以产生DML捕获过程规则和DDL捕获过程规则，这两个规则的每一个都具有评价hr模式中的变更为TRUE的条件，而不管该变更的标记：

BEGIN

 DBMS_STREAMS_ADM.ADD_SCHEMA_RULES(

    schema_name         ＝>  ′hr′，

    streams_type        ＝>  ′capture′，

    streams_name        ＝>  ′capture′，

    queue_name          ＝>  ′strmadmin.streams_queue′，

    include_tagged_lcr  ＝>  true，--注意参数设置

    include_dml         ＝>  true，

    include_ddl         ＝>  true)；

END；

只要重做输入中变更的标记为NULL，就在每个从属数据库配置捕获过程以捕获变更。用户通过保证从属数据库上的捕获过程使用的规则集中的每个DML规则具有下面的条件实现这一目标：

:dml.is_null_tag()＝′Y′

DDL规则应该具有下面的条件：

:ddl.is_null_tag()＝′Y′

这些规则表明只要用于变更的标记为NULL，捕获过程就捕获一个变更。如果用户使用DBMS INFORMATION SHARINGSYSTEM 100 ADM包生成规则，那么每个规则默认地具有这些条件之一。如果用户使用DBMS RULE ADM包为从属数据库上的捕获过程创建规则，那么保证每个规则包含这些条件之一。

配置一个从主数据库上的队列到每个从属数据库上的队列的传播过程。每个传播过程都应该使用规则集，该规则集包含指示该传播过程把主数据库上的队列中的所有LCR(除了产生于从属数据库的变更)传播到从属数据库上的队列的规则。

例如，如果传播过程传播对从属数据库ps2.net的变更，这些变更的标记等于十六进制值′2′，那么用于传播的规则应该把与hr模式有关的所有LCR传播到从属数据库(除了具有标记为′2′的LCR)。对于行LCR，这种规则应该包括下面的条件:dml.get_tag()！＝HEXTORAW(′2′)

对于DDL LCR，这种规则应该包括下面的条件：:ddl.get_tag()！＝HEXTORAW(′2′)

用户可以使用CREATE_RULE程序创建具有这些条件的规则。

配置一个从每个从属数据库上的队列到主数据库上的队列的传播过程。在从属数据库之一上的一个队列仅仅包含由从属数据库上的用户会话和应用程序所作的本地变更，而不是由应用过程作的变更。所以，这些传播不需要进一步的配置。

这种配置以下面的方式阻止变更循环：

·产生于从属数据库的变更决不会被传播回那个从属数据库。

·产生于主数据库的变更决不会被传播回主数据库。

·对环境中任何数据库上的共享数据的所有变更被传播到环境中的每个其它数据库。

因此，在该环境下，没有变更被丢失，所有的数据库是同步。

主数据库与几个扩充的从属数据库共享数据

在该环境下，一个主数据库与几个从属数据库共享数据，但从属数据库有其它的从属数据库与它们相连，这些其它的从属数据库将被称作远程从属数据库。该环境是一种在“主数据库与几个从属数据库共享数据”中描述的环境的扩充。

远程从属数据库不直接与主数据库共享数据，但相反，间接地通过一个从属数据库与主数据库共享数据。因此，所共享的数据存在于主数据库、每个从属数据库和每个远程从属数据库。在这些数据库的任何一个上的变更都被捕获和传播到所有的其它数据库。图23举例说明了一种具有一个主数据库和多个扩充的从属数据库的环境。

在这种环境下，用户可以以下面的方式避免变更循环：

以在“一个主数据库与几个从属数据库共享数据”中描述的实例中配置相同的方式配置主数据库。

以类似于在“一个主数据库与几个从属数据库共享数据”中描述的例子中配置每个从属数据库的方式配置每个远程从属数据库。仅有的区别是远程从属数据库直接与从属数据库而不是主数据库共享数据。

在每个从属数据库，配置一个应用过程以应用来自主数据库的具有重作标记值等价于十六进制值′00′的变更。该值是用于应用过程的默认标记值。

在每个从属数据库，配置一个应用过程以应用来自每个具有一个用于该远程从属数据库唯一的重作标记值的远程从属数据库的变更。

在每个从属数据库配置捕获过程以捕获所有对重作日志中的共享数据的变更，而不管用于该变更的标记值。

配置一个从每个从属数据库上的队列到主数据库上的队列的传播过程。该传播过程应该使用一个规则集，该规则集具有指示该传播过程将从属数据库上的队列中的所有LCR(除了产生于主数据库的变更)传播到主数据库上的队列的规则。只要LCR中的标记不等于′00′，用户通过把一个条件添加到评价为TRUE的规则上，来实现这一目标。例如，为行LCR输入一个类似于下面的条件：

:dml.get_tag()！＝HEXTORAW(′00′)

配置一个从每个从属数据库上的队列到每个远程从属数据库上的队列的传播过程。该传播过程应该使用一个规则集，该规则集具有指示该传播过程将从属数据库上的队列中的所有LCR(除了产生于远程从属数据库的变更)传播到远程从属数据库上的队列的规则。只要LCR中的标记不等于远程从属数据库的标记值，用户通过把一个条件添加到评价为TRUE的规则上，来实现这一目标。例如，如果远程从属数据库的标记值等于十六进制值′19′，那么为行LCR输入一个类似于下面的条件：

:dml.get_tag()！＝HEXTORAW(′19′)

通过以这种方式配置环境，用户阻止变更循环，产生于任何数据库的任何变更不会丢失。

具有从数据库重做流捕获的消息的磁盘备份和恢复的存储器内的流

数据库以稳定的和可恢复的方式在持久电子数据存储介质(例如，软盘、硬盘或磁带)上储存和组织信息。数据库也为它对存储介质所做的每个变更生成重做和撤销信息流。重做/撤销流主要用于在崩溃之后将数据库恢复到一个一致(consistent)的点。

然而，如上所述，重做和撤销信息可以用于其它目的。例如，重做日志可以用于创建一个数据库(或在数据库内的所选对象)的副本以及保持该副本与原始副本一致。创建副本的一个原因是出于在原物被破坏的情况下备份的目的。用于创建副本的另一原因是通过创建“更接近于”将要查询或修改它的用户的副本允许数据更快地被存取。

为创建一个副本，初始复制由原本(initial)构成，从那一点起对原物的任何变更被传输和应用到该副本。该变更可以被直接传输或经由中间站点传输。该传输通常通过一个数据网络电子传送数据或在一些情况下通过物理地传送存储介质来进行。类似地，任何对副本的变更被传输和应用于原本。如果由于同时对不同站点上的数据条目修改而出现差异，该差异需要由内置于数据库或由数据库管理员提供的冲突解决功能来解决。

基于对原始数据库对象的变更创建和更新一个副本仅仅是变更如何被“应用”的一个实例。然而，变更的应用程序可以包含任何类型的动作，或可以发起一个长的活动链。例如，变更的应用程序可以包括给对被变更的数据库对象感兴趣的订阅者生成一个消息。

一个数据库系统仅仅是一个被变更以及变更被记入日志的系统的实例。本文描述的方法不局限于任何特定类型的变更-生成系统。然而，出于解释的目的，将给出实例，其中最初生成该变更的系统和被应用变更的系统都是数据库。

出于解释的目的，最初作出变更的系统被称作源站点，被应用变更的系统被称作目的站点。然而，应该提到一个变更可以由最初被变更的相同系统应用。在这些情况下，源站点和目的站点是相同的站点。

典型地，对数据库对象的变更在变更应用于目的站点之前被存储在持久存储介质上。存储可以在源站点、中间站点、目的站点或上面所有站点上。不幸地，在应用变更之前持久地储存变更易于阻碍应用操作的性能。性能的降低是由于自从发明计算机以来，持久存储介质通常在储存和取回数据方面比暂时存储介质慢10-100倍。

为避免在应用变更之前由持久存储变更造成的延迟，下文描述的方法允许在源站点生成它们的时刻和在目的站点应用它们的时刻之间将变更储存在暂时存储介质，诸如RAM存储器中。

根据一实施例，其中源站点和目的站点是数据库系统，通过读取源数据库系统的重做/撤销流以及在暂时存储器中储存的变更来捕获变更。然后变更数据被传输到另一数据库系统上的暂时存储器，在那里，它被应用或转发到另一数据库系统，或者被应用和转发到另一数据库系统。

暂时存储器的内容以一种先进先出(FIFO)的方式被组织。出于解释的目的，用于以这种方式储存变更数据的存储器组件应在下文被称作“FIFO缓冲器”。现代的计算机装配多个处理单元(或CPU)。出于解释的目的，被指定完成捕获变更、传播变更和应用变更的任务的CPU应分别被称作捕获引擎、传播引擎和应用引擎。

参照图24，它是一个举例说明变更信息从源站点2400通过一个中间站点2404到目的站点2402的存储器内的流的框图。如上面所提到的，可以没有或有几个中间站点。这样，其中有一个中间站点2404的实施例仅仅是出于解释的目的加以举例说明。

如图24中所示，对源站点2400上的原始表的更新导致生成反映变更被插入一个日志文件的数据。捕获引擎读取日志文件并生成流进源站点的易失存储器2410的变更数据。传播引擎(未示出)把变更数据从源站点的易失存储器2410传播到中间站点2404的易失性存储器2414。传播引擎(未示出)将变更数据从中间站点2404的易失性存储器2414传播到目的站点2402的易失性存储器2412。然后应用引擎从目的站点2402上的易失性存储器2412读取变更数据，并应用在目的站点2402。在图24中举例说明的情形中，基于对源站点上的原始表的更新，位于目的站点2402变更数据通过修改一个副本被应用。

应用变更的序列通常应该基于初始进行变更的序列。根据一实施例，图24中示出的各种组件采取下面的措施以保证变更的顺序不会丢失：

·重做流中的每个变更被分配一个唯一且递增的号码，本文被称作变更序号(或CSN)。

·捕获引擎以CSN顺序将变更添加到FIFO缓冲器中。

·传播引擎传输变更时保持CSN顺序。

·应用引擎使用该序列确定应用变更的顺序。

因为在生成变更数据的时刻和应用过程消费变更数据的时刻之间变更数据不被储存到持久存储器，示出的复制操作的性能极大地被改进。然而，在复制操作过程中将变更数据储存到持久存储器的故障有某些恢复结果，这在下文中将被提到。

使用CSN以取得“恰好一次”行为

不幸地，储存在暂时存储器中的信息可以在故障发生时被从那个存储器永久地删除。这种信息损失可以在要求变更被应用在目的站点恰好一次的系统中产生灾难性影响。特别地，如果不采取预防措施，捕获引擎和应用引擎都不知道在发生故障之前哪些变更被发送但还未被应用。这样，存在很大的危险，即捕获引擎将重新发送以及应用引擎将重新应用已被应用的变更。相反地，存在一个危险，即捕获引擎将不重发送，以及应用引擎将决不应用已被发送但还未在故障之前被应用的变更。

根据一实施例，除了保证正确的应用顺序，CSN被用于保证在故障之后变更被应用恰好一次。根据一实施例，通过使应用引擎持久地记录最近应用的变更的原始CSN来取得恰好一次的行为。当新变更被应用时，在图24中作为LAST-APPLIED CSN示出的值连续地被应用引擎更新。由于LAST-APPLIED CSN被储存在非易失性存储器上，在故障之后将可使用，甚至当故障包括存储LAST-APPLIED CSN的站点。如将在下文更为详细地描述的，故障之后发现LAST-APPLIED CSN的能力保证应用引擎不会重新应用之前已应用的变更。

根据一实施例，除了储存LAST-APPLIED CSN，应用引擎定期地通知传播引擎目前的LAST-APPLIED CSN。用于传输该信息的消息本文被称作确认，或“ACK”。参照图24，ACK从目的站点2402发送到中间站点2404，从中间站点2404发送到源站点2400。

虽然源站点2400以这种方式获知LAST-APPLIED CSN，到源站点2400接收ACK的时刻，ACK中识别的LAST-APPLIED CSN值将通常是过时的。换句话说，到ACK消息被源站点2400接收到的时刻，应用引擎将已应用除了与ACK消息中显示的LAST-APPLIED CSN值相关的变更的变更。

虽然过时，在源站点2400接收到的LAST-APPLIED CSN值仍有价值，这是因为源站点2400了解等于那个CSN值的所有变更被保证已被应用引擎应用。所以，根据一实施例，以少见的间隔(infrequent intervals)，源站点2400持久地储存最近已在ACK消息中接收到的CSN值。以这种方式储存的最近的CSN在此被称作LAST ACK CSN，因为它是最新的CSN(1)在ACK消息中在该站点被接收，以及(2)持久地被储存在该站点。为了避免与频繁的磁盘存取相关的开销，LAST ACK CSN被储存到持久存储器的频率可以极大地低于ACK消息被接收的频率。这样，持久储存的LASTACK CSN可能实际上不是最近ACK消息中接收到的CSN。

在发生故障的情况下，源站点2400需要仅仅重新发送CSN值大于储存在源站点的LAST ACK CSN值的变更。特别地，如果捕获数据库出现故障，FIFO缓冲器2410的内容丢失。在这种情况下，捕获引擎使从源站点2400上被记录的LAST ACK CSN开始的变更重新排队进入FIFO缓冲器2410。这样，捕获引擎将重新发送(1)所有之前被发送但还未被应用的变更，以及潜在地(2)一些之前被发送和应用的变更。然而，通常属于第二类的变更的数量很小，因为它将仅仅包括那些被应用以及CSN大于储存在源站点的LASTACK CSN的变更。

根据一实施例，源站点和目的站点之间的一个或多个中间站点以一种类似于源站点的方式用于储存LAST ACK CSN。特别地，除了向上转发任何它们接收的ACK消息，以少见的间隔在转发ACK中包含的传播引擎持久地记录ACK中包含的CSN。例如，在图24中，中间站点2404被示出持久地储存一个LAST ACK CSN。

在一实施例中，LAST ACK CSN被储存在一中间站点，LASTACK CSN被用于响应于中间站点的故障以限制必须做的工作。特别地，如果中间站点2404崩溃，那么中间站点2404读取储存在中间站点2404的LAST ACK CSN，以及请求中间相邻上游站点(在这种情况下，源站点2400)仅仅重新发送那些表示LAST ACK CSN之后的时刻的变更。

如上所述，一个站点可能碰巧停止对已被应用的重新传播变更。根据一实施例，下游站点有责任通过记住它们已传播和/或应用的最高CSN来忽略与这种完全相同的CSN相关的变更。例如，假设源站点2400(1)记录一个值为30的LAST ACK CSN，以及(2)把具有CSN为50的变更传播到一中间站点2404之后发生故障。进一步假设具有CSN为50的变更最终被传播和应用于目的站点2402。

在这种情形下，当源站点2400被重新启动时，源站点2400将开始重新发送在CSN 30之后开始的变更。这样，在那些变更已被传播和应用之后，中间站点2404将接收与CSN 31至CSN 50相关的变更。然而，由于中间站点2404知道它已传播的最后的变更的CSN，中间站点2404知道不用重新传播与CSN 31至CSN 50相关的变更。

作为另一实例，假设在中间站点2404崩溃之前，中间站点2404(1)记录一个值为30的LAST ACK CSN，以及(2)将具有CSN为50的变更传播到一目的站点2402。进一步假设具有CSN为50的变更被应用于目的站点2402。

在这种情形下，当中间站点2404被重新启动时，中间站点2404将请求源站点2400重新发送在CSN 30之后开始的变更。中间站点2404将接收和重新发送给目的站点2402与CSN 31至CSN 50相关的变更，在这之前那些变更已被应用。然而，由于目的站点2402知道LAST APPLIED CSN，目的站点2402知道不用重新应用与CSN 31至CSN 50相关的变更。

根据一实施例，如果目的数据库不能像变更进入以及内存用完一样快速地应用变更，那么目的数据库可以将单独的一组CPU专门用于将变更溢出到持久存储器并释放用于这些变更的内存。这些CPU这儿被称作“溢出引擎”。变更以CSN递增的顺序被溢出，一个被溢出的CSN被ACK(确认)至传播引擎，好像它已被应用。在这些情况下，应用引擎首先查看持久队列中的变更(如果该持久队列不是空的)，然后一旦持久队列是空的，就应用来自FIFO缓冲器的变更。

过程故障恢复

在一些发生故障的情形下，不是易失性存储器中的所有信息都丢失。例如，在图24中所示的系统中，捕获引擎可能发生故障但不丢失储存在源站点2400的易失性存储器中的所有数据。为了从这种故障中快速恢复，LAST PROCESSED CSN可以保存在易失性存储器中。由一个引擎储存的LAST PROCESSED CSN表明被该引擎最近处理过的变更的CSN。例如，源站点2400上的捕获过程可以储存一个表明应用引擎最近放入FIFO缓冲器2410中的变更的CSN的LAST PROCESSED CSN。类似地，在中间站点2404上的传播引擎可以储存一个表明最近传播到目的站点2402的变更的CSN的LAST PROCESSED CSN。

在引擎发生故障而不丢失相应LAST PROCESSED CSN的情况下，该LAST PROCESSED CSN(一般将比LASTACK CSN更新)可以用于确定该引擎在重新启动时应该从何处开始工作。例如，当重新启动时，源站点2400的捕获引擎可以检查LAST PROCESSEDCSN来确定哪些变更已排队进入FIFO缓冲器2410。

“恰好一次”行为和事务

在一些环境下，被捕获、传播和应用的变更可以属于事务。事务是作为单个原子操作的“持久”操作的集合。在变更属于事务的环境下，用于各种事务的变更可以相对于CSN顺序互相交错。例如，用于第一事务TX1的变更可以被赋值为10、11、15和17的CSN，而用于第二事务TX2的变更可以被赋值为12、13、14、16、18和20的CSN。

在大多数系统中，整个事务将被指定一个表明该事务何时被认为已完成的CSN。指定给一个事务、在本文被称作“提交CSN”的“完成时间”号通常是与事务中最后一次变更相关的CSN。例如，事务TX1的提交CSN是17，而事务TX2的提交CSN是20。

根据一实施例，被应用引擎持久储存的LAST APPLIED CSN是通过应用引擎提交的最后事务的提交CSN，不仅仅是应用引擎应用的最后变更的CSN。这样，在这种情况下，LAST APPLIED CSN可以被称作LAST COMMITTED CSN。通过仅仅持久地保存LASTCOMMITTED CSN，而不是最近变更的CSN，需要被更新的持久储存的信息的频率极大地降低。

这样，当应用引擎完成对TX1的执行，应用引擎将更新LASTCOMMITTED CSN来反映值为17的CSN。然而，应用引擎不将在应用与CSN 18相关的TX2的变更之后更新LAST COMMITTEDCSN为18。更确切地说，一旦TX2完全被应用，LAST COMMITTEDCSN将仅仅从17变更，在该时刻，LAST COMMITTED CSN将被变更为20。

在一以这种方式持久保存LAST COMMITTED CSN的实施例中，该LAST COMMITTED CSN反映了已被应用引擎完全应用的最后事务的提交时间。除LAST COMMITTED CSN以外，引用引擎可以为每个还未被完全应用的事务保存一个HIGHEST-SO-FARCSN在易失性存储器中。用于事务的HIGHEST-SO-FAR CSN是该应用引擎已用于那个事务的最近变更的CSN。这样，虽然应用引擎将不在应用与CSN 18相关的TX2的变更之后，将LASTCOMMITTED CSN更新为18，但应用引擎将在应用与CSN 18相关的TX2的变更之后将用于TX2的HIGHEST-SO-FAR更新为18。

基于LAST APPLIED CSN和HIGHEST-SO-FAR CSN，应用引擎可以容易地识别和删掉任何已被应用的变更的副本。特别地，应用引擎删掉已被应用的变更，通过删掉：(1)那些属于已提交小于或等于LAST COMMITTED CSN的CSN的事务的变更，以及(2)那些具有小于或等于变更所属的事务的HIGHEST-SO-FAR CSN的CSN的变更。

例如，假设LAST COMMITTED CSN是17。如果应用引擎接收一个与TX1和CSN 15相关的变更，那么应用引擎将删掉该变更，这是因为TX1的提交CSN不大于LAST COMMITTED CSN(也就是17)。另一方面，如果TX2的提交CSN是20，以及应用引擎接收与TX2和CSN 12相关的变更，那么应用引擎将把12与TX2的HIGHEST-SO-FAR CSN相比较。如果TX2的HIGHEST-SO-FARCSN等于或大于12，那么应用引擎将删掉与CSN 12相关的变更。另一方面，如果TX2的HIGHEST-SO-FAR CSN小于12，那么应用引擎将应用该变更。

最老的CSN

根据一实施例，当正被应用的变更是事务的一部分时，被应用引擎向上游发送的ACK消息包括一个OLDEST CSN值，而不是一个LAST APPLIED CSN。该OLDEST CSN是所有未被提交的事务的最老的变更CSN。根据一实施例，OLDEST CSN值持久地被应用引擎存储，并定期地使用ACK消息向上游传送。

用于事务的最老的变更CSN将通常是与该事务所作的第一变更相关的CSN。为了使OLDEST CSN保持最新，当与当前的OLDEST CSN相关的事务完全被应用时，应用引擎“增加”OLDESTCSN。例如，考虑下面的三个事务：

具有在CSN 12、13、17、20的变更的TX1

具有在CSN 11、14、15、18、19和23的变更的TX2

具有在CSN 16、21、22、24和25的变更的TX3

如果TX1、TX2和TX3仅仅是该应用程序接收的变更所针对的未被提交的事务，那么OLDEST CSN将是11(来自任何未被提交的事务的最老的变更CSN)。假设应用引擎先结束应用TX1。在那一点，LAST COMMITTED CSN将被变更为20，但OLDEST CSN不会变更，这是因为TX1不是与OLDEST CSN相关的事务。

如果应用引擎然后结束应用TX2，那么OLDEST CSN将被更新为16，因为唯一未被提交的事务将是TX3，TX3的最老的变更CSN是16。在这一点，LAST COMMITTED CSN也将变更为23。

通过以这种方式保存OLDEST CSN，所有与小于OLDEST CSN的变更CSN相关的变更被保证已被应用。这样，在发生故障的情况下，应用引擎读取持久存储的OLDEST CSN，并请求上游组件重新发送从OLDEST CSN处开始的变更信息是安全的。

事务的无序应用程序

在上面给出的描述中，假设事务按照它们提交CSN的顺序被应用。这样，如果变更是用于具有CSN高于LAST COMMITTEDCSN的事务，可以假设该变更还未被应用。然而，根据一实施例，应用引擎能够并行地按能够保证一致性而不保证所有事务将被按照它们提交CSN的顺序应用的顺序应用变更。

例如，假设事务TX1、TX2和TX3分别具有提交CSN 17、20和25。根据一实施例，如果TX3不依赖于TX2，那么应用引擎可以在提交TX2之前提交TX1和TX3。当TX3提交时，LASTCOMMITTED CSN将被更新到25。然而，TX2还未被提交。所以，如果发生崩溃，那么与TX2相关的变更将在崩溃之后被删掉，即使那些变更在崩溃之前未被提交。

另一方面，假设在TX3被应用之后没有崩溃。更确切地说，假设应用引擎继续应用TX2，然后崩溃发生。在TX2被应用之后，LAST COMMITTED CSN将被更新到20，因为20是将被应用的最后事务(TX2)的被提交的CSN。基于LAST COMMITTED CSN为20以及TX3具有一个为25的提交CSN，应用引擎将在崩溃之后重新应用TX3，即使TX3在崩溃之前已被完全应用。

这样，在事务可以不按提交CSN顺序被应用的环境下，LASTCOMMITTED CSN可以不为应用引擎提供足够的信息来确定变更是否应该被应用或删掉。这样，根据事务可以无序地被应用的实施例，保存LOW WATERMARK CSN和OLDEST CSN。这些值的每一个的含义和使用将在下文更加详细地加以描述。

低水位标CSN(LOW WATERMARK CSN)

根据一实施例，LOW WATERMARK CSN是CSN，使得所有具有低于或等于LOW WATERMARK CSN的提交CSN的事务被保证已被应用。在事务总是按CSN提交顺序应用的系统中，LOWWATERMARK CSN与LAST WATERMARK CSN相同。然而，在事务不总是按CSN提交顺序应用的系统中，LOW WATERMARKCSN有可能小于最近被应用的事务的提交CSN。

为了使LOW WATERMARK CSN保持最新，当(1)应用引擎结束应用具有高于当前LOW WATERMARK CSN的提交CSN的事务，以及(2)未被应用的事务具有一个低于刚被应用的事务的提交CSN的提交CSN，应用引擎“增加”LOW WATERMARK CSN。

例如，假设事务TX1、TX2和TX3分别具有为17、20和25的提交CSN。假设(1)TX1已被应用，(2)当前的LOWWATERMARK CSN是17，以及(3)应用引擎在TX2之前应用TX3。当TX3被完全应用时，LOW WATERMARK CSN不被更新，这是因为未被应用的事务(TX2)具有一个比TX3的提交CSN更低的提交CSN。在TX2被应用之后，LOW WATERMARK CSN被更新到25，由于所有具有提交次数在或低于25的事务已被应用。

高于标记应用的事务(ABOVE-MARK APPLIEDTRANSACTIONS)

已被应用的具有提交CSN高于LOW WATERMARK的事务在这儿被称作ABOVE-MARK APPLIED事务。在上面给出的实施例中，当TX3在TX2之前被完全应用时，TX3变成一个ABOVE-MARK APPLIED事务。根据一实施例，除LOWWATERMARK CSN以外，应用引擎持久地储存关于ABOVE-MARK APPLIED事务的信息。根据一实施例，关于ABOVE-MARK APPLIED事务的信息被保存在易失性存储器中的散列表中，散列表在持久存储器上被备份。

使用低水位标、最老的CSN以及高于标记的信息以确定在何处删掉变更

在将LOW WATERMARK CSN、关于ABOVE-MARK APPLIED事务的信息以及OLDEST CSN保存在持久存储器上的实施例中，应用引擎删掉已被应用的变更，通过删掉：(1)那些与低于OLDEST CSN的CSN相关的变更，(2)那些属于具有提交CSN小于LOW WATERMARK CSN的事务的变更，(3)那些具有CSN小于或等于该变更所属的事务的HIGHEST-SO-FAR的变更，以及(4)那些属于ABOVE-MARK APPLIED事务的变更。

例如，假设LOW WATERMARK CSN是18，以及TX3(具有为25的提交时间)是ABOVE-MARK APPLIED事务。在这些条件下，应用引擎删掉任何与具有提交CSN小于18的事务相关的变更。类似地，即使许多与TX3相关的变更可能与在为18的LOWWATERMARK CSN以上的CSN相关，所有与TX3相关的变更都将被删掉，这是由于TX3是ABOVE-MARK APPLIED事务。另一方面，如果应用引擎接收与未被提交的事务TX2相关的变更以及该变更具有为12的CSN，那么应用引擎将12与HIGHEST-SO-FARCSN相比较。如果TX2的HIGHEST-SO-FAR CSN等于或大于12，那么应用引擎将删掉与CSN 12相关的变更。另一方面，如果TX2的HIGHEST-SO-FAR CSN小于12，那么应用引擎将应用该变更。

当应用引擎继续应用事务时，LOW WATERMARK值将增加。当LOW WATERMARK CSN增加时，它可以传送之前已是ABOVE-MARK APPLIED事务的事务的提交CSN。根据一实施例，用于跟踪ABOVE-MARK APPLIED事务的散列表定期地被删除，以除去所有用于之前ABOVE-MARK APPLIED事务的信息，以上LOW WATERMARK CSN已随后增加超过该事务的提交CSN。

在保存OLDEST CSN的实施例中，ACK消息将OLDEST CSN传送到上游实体。例如，再次参照图24，定期从目的站点2402发送到中间站点2404的ACK消息包含当前的OLDEST CSN。中间站点2404定期地保存该信息并将它以ACK消息的形式转发到源站点2400。源站点2400也定期地将该信息储存到持久存储器。

应用引擎的流程图

参照图25，它是示出根据本发明的实施例的应用引擎执行的步骤的流程图，该应用引擎使用持久储存的LOW WATERMARK、持久存储的OLDEST CSN、识别ABOVE-MARK APPLIED事务的持久储存的数据、非持久储存的HIGHEST-SO-FAR CSN，以完成恰好一次的行为。

在步骤2502，应用引擎接收一个条目。该条目具有CSN且属于一个事务。在步骤2503，应用引擎确定该条目是否具有小于OLDEST CSN的CSN。如果该条目具有小于OLDEST CSN的CSN，那么该条目在步骤2510被删掉。另一方面，如果该条目具有等于或大于OLDEST CSN的CSN，那么控制进行到步骤2504。

在步骤2504，应用引擎确定该条目是否属于具有执行时间小于或等于当前LOW WATERMARK的事务。如果该条目属于具有执行时间小于当前LOW WATERMARK的事务，那么该条目在步骤2510被删掉。另一方面，如果CSN属于具有执行时间大于当前LOWWATERMARK的事务，那么控制进行到步骤2506。

在步骤2506，应用引擎确定该条目是否属于ABOVE-MARKAPPLIED事务。如果该条目属于ABOVE-MARK APPLIED事务，那么在步骤2510该条目被删掉。如果该条目不属于ABOVE-MARKAPPLIED事务，那么控制进行到步骤2508。

在步骤2508，应用引擎确定该条目的CSN是否小于或等于用于该条目所属的事务的HIGHEST-SO-FAR CSN。如果该条目的CSN小于或等于用于该条目所属的事务的HIGHEST-SO-FAR CSN，那么该条目在步骤2510被删掉。如果该条目的CSN大于用于该条目所属的事务的HIGHEST-SO-FAR CSN，那么该条目在步骤2512被应用。

在该条目被应用之后，在步骤2514，应用引擎更新用于该事务的HIGHEST-SO-FAR CSN。在步骤2516，应用引擎确定该条目所属的事务是否已被完全应用。如果该条目所属的事务已被完全应用，那么控制进行到步骤2518。如果该条目所属的事务还未被完全应用，那么进行该条目的处理(步骤2524)。

在步骤2518，应用引擎确定LOW WATERMARK是否需要被更新。如果不存在具有提交CSN小于刚被应用的事务的提交CSN的未被应用的事务，那么更新LOW WATERMARK。控制到步骤2520。

在步骤2520，如果合适，OLDEST CSN被更新。特别地，如果刚被应用的事务包含最老的还未被应用的变更，那么OLDESTCSN被更新，以反映剩余的未被应用的事务的最老的变更CSN。

在步骤2522，如果合适，ABOVE-MARK APPLIED事务信息被更新。特别地，如果刚被应用的事务高于当前的LOWWATERMARK，以及在步骤2518，LOW WATERMARK未被增加到或超过事务的提交时间，那么该事务是ABOVE-MARK APPLIED事务，ABOVE-MARK APPLIED事务信息被更新以包括该事务。在ABOVE-MARK APPLIED事务信息被更新之后，进行该条目的处理(步骤2524)。

虽然上述的实例在基于从另一站点接收到的变更信息在目的站点进行变更的应用引擎的环境下被给出，但本文描述的技术不局限于任何特定的环境。例如，被应用引擎接收的“条目”可以是需要恰好一次被处理的任何形式的信息。而且，被应用引擎“应用”该条目的实际步骤将根据实现到实现的不同而不同。例如，该“条目”可以是独立的条目的订单，“事务”可以相当于包括一组条目订单的购买订单，条目的“应用”可以包括为购买订单生成帐单。

利用信息共享系统100复制DDL

如上所述，存在许多有利于保存一个数据库对象几个副本的情况。上面给出的许多实施例描述了信息共享系统100如何可以用于保证每个副本中包含的数据与同一数据库对象的所有其它副本中包含的数据一致。特别地，信息共享系统100可以用于将对任一副本的变更传播和应用到其它每个副本驻留的站点。

除了保持一个对象的副本内包含数据的一致性之外，信息共享系统100可以用于保持副本本身结构的一致性。特别地，数据定义语言(DDL)语句是定义、变更数据库的结构以及删除数据库对象(诸如表)的数据库命令。当DDL语句在对象的副本上执行时，那个副本的结构将被变更，将不在与相同对象的其它副本的结构保持一致。根据一实施例，信息共享系统100用于以允许其它副本的结构与被变更的副本保持一致的方式把DDL语句传播和应用到其它副本。

而且，信息共享系统100可以用于自动创建初始副本。例如，假设一个用户发布一个DDL语句以在数据库A中创建表T1。根据本发明的一实施例，该DDL语句的记录被生成并储存到数据库A的重做日志中。用于挖掘数据库A的重做日志的捕获过程可以从重做日志捕获DDL语句并基于DDL语句生成一个事件。然后将该事件储存到中间存储区，最终被传播到一个或多个其它数据库。在那些其它数据库的每个数据库，应用引擎可以用于通过在那些数据库内发布一个相应的DDL语句“应用”该事件。那些DDL语句的执行将导致表T1的副本的创建在每个数据库内进行。

应该提到以这种方式复制DDL不要求在信息共享系统之间的任何停顿，以及不存在信息共享系统上所做的行为的限制。特别地，以这种方式复制DDL不要求对象/系统上的用户行为的暂停且不考虑DDL的复杂性或性质。

生成关于DDL操作的信息

在生成用于DDL操作重做信息的系统中，仍可以有作为DDL操作结果而生成的重做信息。例如，假设一个DDL操作导致在数据库内的表的创建。表的创建可以包括将一行或多行数据插入到现有系统表的DML操作，该现有系统表用于储存关于数据库不同表的元数据。响应于对那些系统表内的数据作出的变更，可以生成DML重做信息。然而，如果可能，仅仅基于响应于对那些系统表的更新而生成的重做信息，试图重构导致对系统表的内容的变更的特定DDL操作将是极端困难的。这样，生成有关那些DDL操作的特定信息在需要DDL操作异步复制的情况下提供了极大的好处。

根据一实施例，为DDL操作生成的重做信息包括相关性信息(也就是被DDL依赖/影响的对象)。一般而言，这种相关性信息不能从作为DDL操作的结果生成的DML重做操作重构。

在上面给出的实例中，初始执行DDL操作的数据库(“源”数据库)用于生成用于DDL操作的重做信息。由于生成用于DDL操作的重做，DDL操作能够精确地被挖掘源数据库的重做日志的捕获过程捕获。由于DDL操作精确地被捕获，它可以精确地被应用于理想的目标数据库。根据一实施例，其中，为DDL操作生成的重做信息包括反映被源数据库执行的DDL语句的字符串。

在重做日志内储存关于DDL操作的特定信息仅仅是一个DDL操作如何在源数据库内被记录的实例。本文描述的复制方法不局限于任何特定的DDL操作记录方法。只要DDL操作的精确描述可以被重构，信息共享系统100就可以用于异步地将DDL变更传播和应用于其它数据库系统。

多向的DDL复制

信息共享系统100可以用于在使用信息共享系统100来共享信息的任何系统之间执行DDL复制。因此，双向和多向DDL复制是可能的。例如，信息共享系统100可以用于在五个数据库之间复制DDL，使得在五个数据库系统的任一系统上执行的DDL语句将导致相应的DDL语句在其它四个数据库系统上被执行。

在这种五-路(five-way)复制的情形下，在第一数据库系统上创建的表可以在第二数据库系统上被添加一列，在第三数据库系统上被删除一列。当进行这些变更的每个变更时，在其它四个数据库系统的每一个系统上进行相应的变更。特别地，在第一数据库系统上的表的创建可以导致在其它四个数据库系统上的表的副本的创建。随后在第二数据库系统上添加一列将导致对其它四个数据库系统的每一个系统上的表的副本添加相应的一列。随后从第三数据库系统上删除一列将导致从其它四个数据库系统的每一个系统上的表的副本上删除相应的列。虽然这些所有的DDL操作正在不同的数据库之间被复制，行为(包括DDL和DML操作)可以不受任何限制地继续在数据库上发生，甚至在DDL操作的目标的表上发生。

在上面给出的五-路复制情形下，所有的DDL变更以与变更在产生它们的数据库系统内被执行的变更完全相同的方式被传播和在数据库系统的每个系统上执行。然而，不需要这样。如上面所详细解释的，复制过程中包含的每个组件的操作包括捕获引擎、传播引擎和应用引擎，可以利用规则引擎登记规则定制。那些规则在精细粒度级别可以指定每个组件如何操作。例如，该规则可以指定一个选择标准，其中仅仅那些满足该选择标准的DDL变更被捕获、传播和/或应用。而且，那些规则可以指定在DDL变更信息上执行的转换，其中该转换可以在DDL变更的捕获、传播和/或应用过程中应用。

表之外的其它对象的DDL复制

在上面给出的实例中，被复制的DDL操作是包括一个表的操作。然而，信息共享系统100可以用于复制任何形式的DDL操作。例如，响应于添加到一特定的数据库系统的用户，信息共享系统100可以用于在一个或多个数据库系统中创建一个新用户。类似地，响应于添加到一特定的数据库系统的用户，信息共享系统100可以用于在一个或多个数据库系统中创建新的权限。

被DDL命令创建和/或变更的其它类型的数据库对象包括但不局限于查看、触发、程序、索引、序列、同义词、回滚段、大纲、数据库链接、物化的查看、物化的查看日志等。在此描述的方法可以用于复制创建或变更任一这种类型的对象的DDL。如上面提到的，对数据库的活动没有限制，而DDL正被复制用于任一这些其它类型的数据库对象。

应用被复制的DDL变更

考虑一种情形，其中(1)作出对一个对象的DML变更的第一集合，然后(2)在该对象上执行DDL操作，然后(3)作出对该对象的DML变更的第二集合。如果对该对象的DML变更和DDL变更正被复制，那么在对副本进行DDL变更之前，目的地应用DML变更的第一集合，以及在对副本进行DDL变更之后，应用DML变更的第二集合。

根据一实施例，一种机制被提供用于跟踪DML变更和DDL变更之间的相关性。例如，在上面给出的情形下，DDL操作依赖于第一集合的DML变更，第二集合的DML变更依赖于DDL操作。通过跟踪该相关性信息，并把相关性信息传送给复制DML和DDL变更的目的站点，目的站点可以保证变更以适当的顺序执行。

值得注意地，在一个数据库对象上执行的DDL可以在另一数据库上产生影响。在这些情况下，第二对象具有在第一对象上的相关性。在第二对象上执行的DML操作可以受到在第一对象上执行的DDL操作的影响。因此，相关性跟踪机制使用关于对象之间的相关性的信息，来确定DDL和DML操作之间的相关性以正确的顺序应用于目的站点，如所表示的相关性关系。另外，该相关性信息可以用于确定其它哪些动作可以与DDL操作同时实施。例如，数据库服务器可以用于并行地执行操作，诸如复制DDL和DML操作，只要操作之间不存在相关性。

变更信息的XML模式

在上面给出的许多实例中，信息共享系统100用于与一个或多个“目的”系统共享关于在一个“源”系统内作出的变更的信息。用于传送变更信息的记录的结构可以从一个实现到另一个实现变化。本文描述的方法不依赖于用于记录的任何特定的结构。

根据一实施例，不同条变更信息(看标题为“逻辑变更记录”的部分)被存储在符合XML模式的结构中。在一实施例中，LCR的结构符合下面的XML模式：

schema xmlns＝″http://www.w3.org/2001/XMLSchema″

       targetNamespace＝″http://xmlns.oracle.com/streams/schemas/lcr″

       xmlns:lcr＝″http://xmlns.oracle.com/streams/schemas/lcr″

       xmlns:xdb＝″http://xmlns.oracle.com/xdb″

       version＝″1.0″>

<simpleType name＝″short_name″>

     <restriction base＝″string″>

        <maxLength value＝″30″/>

     </restriction>

</simpleType>

<simpleType name＝″long_name″>

     <restriction base＝″string″>

        <maxLength value＝″4000″/>

     </restriction>

</simpleType>

<simpleType name＝″db_name″>

     <restriction base＝″string″>

        <maxLength value＝″128″/>

        </restriction>

</simpleType>

<！--Default session parameter is used if format is not specified-->

<complexType name＝″datetime_format″>

    <sequence>

       <element name＝″value″type＝″string″/>

       <element name＝″format″type＝″string″minOccurs＝″0″/>

    </sequence>

</complexType>

<complexType name＝″anydata″>

    <choice>

       <element name＝″varchar2″type＝″string″xdb:SQLType＝

       ″VARCHAR2″/>

       <！--Represent char as varchar2.xdb:CHAR blank pads upto 2000

       bytes！-->

       <element name＝″char″type＝″string″xdb:SQLType＝

       ″VARCHAR2″/>

       <element name＝″nchar″type＝″string″xdb:SQLType＝

       ″NVARCHAR2″/>

       <element name＝″nvarchar2″type＝”string″xdb:SQLType＝

       ″NVARCHAR2″/>

         <element name＝″number″type＝″double″xdb:SQLType＝

         ″NUMBER″/>

         <element name＝″raw″type＝″hexBinary″xdb:SQLType＝

            ″RAW″/>

         <element name＝″date″type＝″lcr:datetime_format″/>

         <element name＝″timestamp″type＝″lcr:datetime_format″/>

         <element name＝″timestamp_tz″type＝″lcr:datetime_format″/>

         <element name＝″timestamp_ltz″type＝″lcr:datetime_format″/>

         <！--Interval YM should be according to format allowed by SQL-->

         <element name＝″interval_ym″type＝″string″/>

         <！--Interval DS should be according to format allowed by SQL-->

         <element name＝″interval_ds″type＝″string″/>

      </choice>

</complexType>

<complexType name＝″column_value″>

     <sequence>

        <element name＝″column_name″type＝″lcr:long_name″/>

        <element name＝″data″type＝″lcr:anydata″/>

        <element name＝″lob_information″type＝″string″miOccurs＝″0″/>

        <element name＝″lob_offset″type＝″nonNegativeInteger″

              minOccurs＝″0″/>

        <element name＝″lob_operation_size″type＝″nonNegativeInteger″

        minOccurs＝″0″/>

     </sequence>

</complexType>

<element name＝″ROW_LCR″>

<complexType>

    <sequence>

       <element name＝″source_database_name″type＝″lcr:db_name″/>

       <element name＝″command_type″type＝″string″/>

       <element name＝″object_owner″type＝″lcr:short_name″/>

       <element name＝″object_name″type＝″lcr:short_name″/>

       <element name＝″tag″type＝″hexBinary″xdb:SQLType＝″RAW″

       minOccurs＝″0″/>

       <element name＝″transaction_id″type＝”string″minOccurs＝″0″/>

         <element name＝″scn″type＝″double″xdb:SQLType＝″NUMBER″

         minOccurs＝″0″/>

         <element name＝″old_values″minOccurs＝″0″>

         <complexType>

            <sequence>

               <element name＝″old_value″type＝″lcr:column_value″

                     maxOccurs＝″unbounded″/>

      </sequence>

   </complexType>

</element>

<element name＝″new_values″minOccurs＝″0″>

<complexType>

   <sequence>

        <element name＝″new_value″type＝″lcr:column_value″maxOccurs

              ＝″unbounded″/>

   </sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

<element name＝″DDL_LCR″>

<complexType>

<sequence>

   <element name＝″source_database_name″type＝″lcr:db_name″/>

   <element name＝″command_type″type＝″string″/>

   <element name＝″current_schema″type＝″lcr:short_name″/>

   <element name＝″ddl_text″type＝″string″/>

   <element name＝″object_type″type＝″string″minOccurs＝″0″/>

   <element name＝″object_owner″type＝″lcr:short_name″minOccurs＝″0″/>

   <element name＝″object_name″type＝″lcr:short_name″minOccurs＝″0″/>

   <element name＝″logon_user″type＝″lcr:short_name″minOccurs＝″0″/>

   <element name＝″base_table_owner″type＝″lcr:short_name″

   minOccurs＝″0″/>

   <element name＝″base_table_name″type＝″lcr:short_name″

   minOccurs＝″0″/>

   <element name＝″tag″type＝″hexBinary″xdb:SQLType＝″RAW″

   minOccurs＝″0″/>

   <element name＝″transaction_id″type＝″string″minOccurs＝″O″/>

   <element name＝″scn″type＝″double″xdb:SQLType＝″NUMBER″

   minOccurs＝″0″/>

     </sequence>

</complexType>

</element>

</schema>

该典型的XML模式包含用于每一种不同类型的变更信息的部分。例如，根据本发明的一实施例，紧跟标记<elementname＝″DDL_LCR″>的部分指定了与DDL变更相关的记录的结构。类似地，根据本发明的一实施例，紧跟标记<elementname＝″ROW_LCR″>的部分指定了与对表的一行进行的DML变更相关的记录的结构。

硬件综述

图26是一个示出在其上可以实施本发明的一实施例的计算机系统2600的框图。计算机系统2600包括总线2602或其它用于传送信息的通信机制，以及一个与总线2602相连用于处理信息的处理器2604。计算机系统2600也包括主存储器2606，诸如随机存取存储器(RAM)或其它动态存储设备，该主存储器2606连接到总线2602用于储存信息和被处理器2604执行的指令。主存储器2606也可以用于在处理器2604执行指令过程中储存暂时变量或其它中间信息。计算机系统2600还包括一个只读存储器(ROM)2608或其它连接到总线2602用于储存静态信息和用于处理器2604的指令的静态存储设备。存储设备2610诸如磁盘或光盘被提供并连接到总线2602用于储存信息和指令。

计算机系统2600可以经由总线2602连接到显示器2612，诸如阴极射线管(CRT)用于将信息显示给计算机用户。输入装置2614包括文字键、数字键和其它键，被连接到总线2602用于将信息和命令选择传送给处理器2604。另一类型的用户输入装置是光标控制器2616，诸如鼠标、跟踪球或用于将方向信息和命令选择传送给处理器2604以及控制光标在显示器2612上移动的光标方向键。该输入装置通常具有两个轴向的自由度，第一个轴(例如x)和第二个轴(例如y)，这两个自由度允许装置在平面上指定位置。

本发明涉及了使用计算机系统2600实施本文所述的方法。根据本发明的一实施例，那些方法由计算机系统2600实施来响应处理器2604执行主存储器2606中包含的一个或多个指令的一个或多个序列。这种指令可以从另一计算机可读介质诸如存储装置2610读进主存储器2606。对主存储器2606中包含的指令序列的执行导致处理器2604实施本文所述的过程步骤。在另外的实施例中，硬件电路可以用于取代或与软件指令结合来实施本发明。这样，本发明的实施例不局限于硬件电路和软件的任何特定结合。

本文使用的术语“计算机可读介质”指的是任何参与提供指令给处理器2604以便执行的介质。这种介质可以采取许多形式，包括但不局限于非-易失性介质、易失性介质和传输介质。非-易失性介质包括例如光盘或磁盘，诸如存储装置2610。易失性介质包括动态存储器，诸如主存储器2606。传输介质包括同轴电缆、铜线和光纤，包括包含总线2602的电线。传输介质也可以采取声波或光波的形式，诸如那些在无线电波和红外线数据通信过程中生成的波。

计算机可读介质的常见形式包括例如软盘、软磁盘、硬盘、磁带、或任何其它的磁介质、CD-ROM、任何其它的光学介质、穿孔卡片、纸带、任何其它带空结构的物理介质、RAM、PROM、以及EPROM、FLASH-EPROM、任何其它的存储芯片或录音带盒、下文所述的载波、或计算机可以读取的任何其它的介质。

各种形式的计算机可读介质可以参与传送一个或多个指令的一个或多个序列给处理器2604以便执行。例如，该指令可以初始存放在远程计算机的磁盘上。远程计算机可以将指令装入它的动态存储器并使用一个调制解调器通过电话线发送指令。计算机系统2600本地的调制解调器可以接收电话线上的数据并使用红外线发射器将数据转换成红外线信号。一个红外线探测器可以接收红外线信号中传送的数据，适当的电路可以将数据放在总线2602上。总线2602将数据传送到主存储器2606，处理器2604从主存储器2606取回并执行指令。主存储器2606接收到的指令在处理器2604执行之前或之后可选地存储在存储装置2610。

计算机系统2600还包括一个连接到总线2602的通信接口2618。通信接口2618提供到网络链路2620的双向数据通信连接，网络链路2620连接到本地网络2622。例如，通信接口2618可以是一个综合业务数字网(ISDN)卡或调制解调器来提供到相应类型的电话线的数据通信连接。作为另一实施例，通信接口2618可以是一个局域网(LAN)卡来提供到兼容的LAN的数据通信连接。无线线路也可以被实现。在任何这种实现中，通信接口2618发送和接收传送描述各种类型信息的数字数据信息共享系统100的电信号、电磁信号或光信号。

网络链路2620通常提供通过一个或多个网络到其它数据装置的数据通信。例如，网络链路2620可以提供通过本地网络2622到主机计算机2624或到由Internet服务提供商(ISP)2626操作的数据装置的连接。ISP 2626反过来提供通过现在通常称为“Internet”2628的世界范围的分组数据通信网络的数据通信服务。本地网络2622和Internet 2628都使用携带数字数据信息共享系统100的电信号、电磁信号或光信号。传送数字数据到和来自计算机系统2600的通过各种网络的信号和网络链路2620上以及通过通信接口2618的信号是传输信息的载波的典型形式。

计算机系统2600可以通过网络、网络链路2620和通信接口2618发送消息和接收数据，包括程序代码。在Internet的实施例中，服务器2630可以通过Internet 2628、ISP 2626、本地网络2622以及通信接口2618传送被请求的应用程序代码。

被接收的代码可以在接收时由处理器2604执行，和/或储存在存储装置2610或其它非-易失性存储器以用于以后的执行。以这种方式，计算机系统2600可以获得载波形式的程序代码。

在上述的说明书中，本发明的实施例已参照许多根据实现的不同而不同的特定细节被描述。这样，什么是发明以及申请人打算使什么成为发明的唯一指标是从本申请以这种权利要求发布的特定形式发布包括任何随后的纠正的权利要求集。这儿明确阐述的任何对这种权利要求中包含的术语的定义将决定权利要求中使用的这种术语的含义。所以，无局限性、组成部分、属性、特征、在权利要求中未被明确陈述的优点或属性应该以任何方式限制这种权利要求的范围。相应地，该说明书和附图以一种举例说明而不是局限性的方式被看待。

Claims (27)

1.一种用于共享信息的方法，所述方法包括以下步骤：

由显式捕获过程通过作出经过与中间存储区相关的API的显式调用，将一个或多个信息条目的第一集合添加到所述中间存储区；

由隐式捕获过程基于发生在与所述隐式捕获过程相关的系统中的事件，自动地将一个或多个信息条目的第二集合添加到所述中间存储区中；以及

由消费过程消费储存在所述中间存储区中的信息条目。

2.根据权利要求1所述的方法，其中，所述自动地添加一个或多个信息条目的第二集合的步骤由基于在数据库系统内生成的日志的内容，将信息条目插入所述中间存储区中的捕获过程执行。

3.根据权利要求2所述的方法，其中，所述中间存储区由所述数据库系统管理。

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

所述日志识别在所述数据库系统内作出的变更；以及

所述一个或多个信息条目的集合包括反映所述变更的集合的记录。

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

所述变更的集合是反映在所述日志中的所有变更的子集；以及

所述捕获过程基于储存在所述数据库系统内的元数据中表明的规则选择将哪些变更反映在所述记录中。

6.根据权利要求1所述的方法，其中所述显式捕获过程、所述隐式捕获过程和所述消费过程是信息共享系统中的组件；以及

所述方法还包括以下步骤：

所述信息共享系统接收指定表明至少一个所述组件如何操作的一个或多个规则的规则数据；以及

通过将表示所述一个或多个规则的元数据储存在所述信息共享系统内，登记所述规则数据；

所述至少一个组件读取所述元数据以及以所述元数据中指定的方式操作。

7.根据权利要求6所述的方法，其中，所述规则数据包括表明所述至少一个组件如何转换信息条目的规则。

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

所述信息共享系统包括数据库系统；

登记所述规则数据的步骤包括将表示所述一个或多个规则的所述元数据储存在所述数据库系统内；以及

所述至少一个组件是在所述数据库系统内执行的过程。

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

所述隐式捕获过程将表明所述信息条目与发生在所述系统中的事件对应的标记值储存在一个或多个信息条目的所述第二集合的每个信息条目内；以及

使用所述标记值以避免循环，否则所述循环导致所述事件将在所述系统内重新被应用。

10.根据权利要求9所述的方法，还包括以下步骤：

将所述信息条目从所述中间存储区传播到第二系统；

通过将与所述信息条目相关的事件应用到所述第二系统中，在所述第二系统内作出变更；

其中，所述第二系统用于将所述第二系统内的变更传播到第一系统；以及

其中，使用所述标记值以避免循环的步骤包括：基于所述信息条目中的标记值，阻止所述变更传播到所述第一系统。

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

所述系统是第一系统；以及

所述隐式捕获过程在相对于所述第一系统遥远的第二系统内执行。

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

所述方法还包括将日志从所述第一系统传送到所述第二系统的步骤；以及

所述隐式捕获过程基于包含在所述日志中的信息生成所述信息条目的第二集合。

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

所述第一系统是第一数据库系统；

所述第二系统是第二数据库系统；

所述日志是由所述第一数据库系统生成的重做日志；以及

所述信息条目的第二集合识别在所述第一数据库系统内作出的变更。

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

所述中间存储区驻留在所述第二数据库系统中；以及

所述方法还包括使用应用过程从所述中间存储区读取所述信息条目的第二集合以及基于所述信息条目的第二集合在所述第二数据库系统内发生变更的步骤。

15.一种用于共享信息的方法，所述方法包括以下步骤：

捕获过程，基于在与所述捕获过程相关的第一系统内发生的事件，自动地将一个或多个信息条目的集合添加到中间存储区；以及

所述捕获过程将表明所述每个信息条目与发生在所述第一系统内的事件对应的标记值储存在所述一个或多个信息条目的集合的每个信息条目内；

将信息条目从所述中间存储区传播到第二系统；

通过在所述第二系统内应用与信息条目相关的事件，在所述第二系统内作出变更；

其中，所述第二系统用于将所述第二系统内的变更传播到所述第一系统；以及

基于所述信息条目中的标记值，使用所述标记值，通过阻止所述变更传播到所述第一系统以避免循环。

16.一种用于共享信息的方法，所述方法包括以下步骤：

捕获过程自动地执行以下步骤：

检查在第一数据库系统内生成的重做日志文件；

基于在所述重做日志文件中表明的事件，将一个或多个信息条目的集合添加到中间存储区中；以及

消费过程，通过读取所述中间存储区中的信息条目以及基于在所述重做日志文件中表明的事件导致在第二数据库系统内作出变更，自动地处理来自所述中间存储区的信息条目。

17.根据权利要求16所述的方法，其中，导致在所述第二数据库系统内作出变更的步骤包括：在所述第二数据库系统内保存所述第一数据库系统内的一个或多个数据库对象的副本，其中，所述一个或多个数据库对象是所述第一数据库系统内的可复制对象的子集。

18.根据权利要求16所述的方法，其中，导致变更的步骤包括以下步骤：

构造数据库命令以导致所述变更；以及

将所述数据库命令提交给所述第二数据库系统。

19.根据权利要求16所述的方法，其中，所述第一数据库系统是与所述第二数据库系统不同类型的数据库系统。

20.根据权利要求16所述的方法，还包括以下步骤：

接收表示订阅者和订阅者感兴趣的信息的订阅数据；

第二消费过程，自动地从所述中间存储区读取信息条目，以及基于所述订购数据，通知对与信息条目相关的事件感兴趣的订阅者。

21.一种用于共享信息的方法，所述方法包括以下步骤：

在数据库系统内登记捕获规则的集合；

在所述数据库系统内登记传播规则的集合；

基于所述捕获规则的集合，确定发生在所述数据库系统内的哪些事件将被捕获；

通过储存有关中间存储区中的所述事件的信息捕获所述事件；

基于所述传播规则的集合，确定如何从所述中间存储区传播信息；以及

基于确定如何从所述中间存储区传播信息的步骤，从所述中间存储区传播信息。

22.根据权利要求21所述的方法，还包括以下步骤：

登记应用规则的集合；

接收从所述中间存储区传播的所述信息；以及

基于所述应用规则的集合，应用从所述中间存储区接收的所述信息。

23.根据权利要求21所述的方法，其中，捕获所述事件的步骤包括：读取由所述数据库系统生成的日志，以及有选择地将有关在所述日志中识别的事件的信息储存在所述中间存储区中。

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

传播步骤包括将所述信息从所述中间存储区传播到第二中间存储区；以及

所述方法还包括将在所述第二中间存储区内识别的变更应用到第二数据库系统的步骤。

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

所述方法还包括登记应用规则的集合的步骤；以及

基于所述应用规则的集合执行应用变更的步骤。

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

所述方法还包括登记用户程序的步骤；以及

基于所述用户程序执行应用变更的步骤。

27.一种用于共享信息的方法，所述方法包括以下步骤：

捕获过程，将一个或多个信息条目的第一集合添加到中间存储区；

应用过程，自动地从所述中间存储区读取信息条目以及有选择地消费所述信息条目；以及

显式出列过程，通过对与所述中间存储区相关的API进行显式调用，消费来自所述中间存储区的信息条目。

Images