CN103782573A

CN103782573A - 对客户端和应用掩盖服务器停运

Info

Publication number: CN103782573A
Application number: CN201280043498.9A
Authority: CN
Inventors: K·S·尼尔; C·L·科尔瑞恩; D·N·萨博; N·R·艾科达; S·H·罗艾斯科; 周彤; J·D·拉瓦瑞恩
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2011-09-09
Filing date: 2012-09-07
Publication date: 2014-05-07
Anticipated expiration: 2032-09-07
Also published as: US9124670B2; CN107688487A; US9591103B2; CN107688487B; EP2754283B1; US20140229531A1; EP2903239B1; CN103782573B; EP2754283A1; US20150326673A1; WO2013036882A1; US20130066955A1; US8725882B2; EP2903239A1

Abstract

提供用于将在第一服务器实例与客户端之间的第一会话中建立的状态恢复到第二服务器实例与客户端之间的第二会话的方法、设备、和计算机可读介质。通过在第二会话中重复非事务命令保持对于第一会话存在的非事务会话状态。当事务没有在第一会话中完成时，在第二会话中执行事务。第一服务器实例在第一会话中向客户端发送为了在到第一服务器实例的请求中发送的、用于在第一会话中执行的命令的可能重演而维持的信息。如果第一会话变得不可用，则维持的信息可以由第二服务器实例使用以恢复数据库会话，从而对用户、应用、和客户端掩盖停运。

Description

对客户端和应用掩盖服务器停运

对相关申请的交叉引用

本申请涉及并要求以下申请的优先权（1）2011年9月9日提出的题为“RecoveringStateful Read-Only Database Sessions”的申请序列号13/229,641，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；（2）2012年4月16日提出的题为“Idempotence ForDatabase Transactions”的申请序列号13/448,258，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；（3）2012年4月16日提出的题为“Idempotence For Database Transactions”的申请序列号13/448,267，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；以及（4）2012年7月5日提交的题为“PreservingServer-Client Session Context,”的申请序列号13/542,278，其全部内容通过引用而被合并于此，就像这里充分阐述的一样。申请人因此取消母案申请或它的审查历史中的权利要求范围的任何否认。

本申请也涉及（1）2004年8月12日提出的题为“TransparentMigration Of Stateless Sessions Across Servers”的美国专利No.7,747,754，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；（2）2006年5月1日提出的题为“Database Shutdown WithSession Migration”的美国专利No.7,502,824，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；（3）2004年8月12日提出的题为“Transparent Session Migration Across Servers”的美国专利No.7,552,218，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；（4）2005年5月17日提出的题为“Capturing AndRe-Creating The State Of A Queue When Migrating A Session”的美国专利No.7,415,470，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；（5）2007年4月4日提出的题为“MigratingTemporary Data Of A Session”的美国专利No.7,634,512，其全部内容通过引用而被合并于此，就像这里充分阐述的一样；（6）2011年3月30日提出的题为“Application Workload Capture And ReplaySystem”的美国专利No.13/076,313，其全部内容通过引用而被合并于此，就像这里充分阐述的一样。

技术领域

本技术领域涉及恢复运行中的客户端到服务器的事务性和非事务性工作。

背景技术

服务器和客户端

服务器是向一个或多个客户端提供服务的操作软件处理。服务器可以是操作来向客户端提供服务的相关软件的若干不同的服务器实例的服务器实例。客户端在服务器连接上与服务器通信。具体地，客户端将命令发送到服务器，并且服务器执行命令以及可选地将结果发回到客户端。如这里使用的，服务器“操作”是指由服务器按照执行客户端的一个或多个命令采取的功能、进程、其它行动。单个命令可以触发多个服务器操作或可以对应于单个服务器操作。例如，一些命令除了执行数据操作功能之外可以请求服务器返回结果。其它命令仅仅可以请求执行数据操作命令的确认，或可以不请求任何响应。

客户端可以请求在请求中指定的一组命令的执行。在响应中，服务器可以执行该组命令并且向客户端确认该组命令被执行。例如，服务器可以向客户端提供结果或可以仅仅提供该组命令被执行的指示。服务器与客户端之间的连接可以在有计划或非计划的任何时间变得不可用。例如，服务器可以失败，或网络设备或支持服务器与客户端之间的连接的其它资源可以失败。如果服务器与客户端之间的连接在服务器已经对一组命令做出响应之前变得不可用，则客户端不能确定是否已经完成该组命令。

这里分别提供数据库服务器与数据库应用作为服务器和客户端的示例。但是，这里描述的各种技术可以应用于任何服务器-客户端系统。

数据库实例

数据库包括存储在诸如硬盘、随机存取存储器棒、集群或云存储系统之类的一个或多个存储设备上的数据和元数据。此类数据和元数据可以逻辑上被存储在数据库中，例如，根据关系和/或对象-关系数据库结构。数据库应用通过向数据库实例提交使得数据库实例对存储在数据库中的数据执行操作的命令来与数据库服务器的实例（“数据库实例”）交互。数据库命令是访问或修改来自数据库的数据的请求。命令可以使得数据库实例对数据库中的数据执行操作和/或返回来自于数据库中的数据。

在多节点数据库系统中，数据库可以由多个数据库实例服务，并且每个数据库实例可以被配置为访问所有或部分数据库。服务器的实例是诸如在一个或多个计算设备上执行的一个或多个处理之类的综合软件组件和用于在处理器上执行综合软件组件的诸如存储器、存储设备或处理器周期之类的计算资源的分配的组合。数据库实例是综合软件组件和用于访问、修改、或相反利用数据库的计算资源的分配的组合。数据库实例可以被分组成呼叫业务的逻辑域。多个数据库实例可以被安装或配置在单个机器或分离的机器上。在处理数据库命令时，数据库实例可以访问数据库或来自于数据库的信息的高速缓存。在一个示例中，数据库被存储在非易失性存储器中，并且高速缓存被存储在易失性存储器中。

在多个数据库会话共享对相同的数据的访问时，在会话中执行的用户命令可以锁定一部分数据库同时该部分由服务会话的数据库实例使用。例如，用户会话可以锁定用于排外读和/或写访问的部分，并且在所述部分被锁定时其他用户会话被阻止访问和/或修改该部分。然后当数据库实例完成访问和/或修改数据库的那部分时，用户会话释放锁定。在锁定被释放之后，其它实例可以访问和/或修改该部分或获得对该部分的锁定。

数据库命令可以以符合由数据库实例支持的数据库语言的数据库语句的形式被提交到数据库实例。由许多数据库实例支持的数据库语言的一个非限制示例是称为结构化查询语言（“SQL”）的数据操作语言（“DML”），包括由如

的此类数据库服务器（例如，

数据库11g）支持的SQL的专有形式。SQL数据定义语言（“DDL”）指令被发出到数据库服务器以创建或配置数据库对象，诸如表、视图、或复杂类型。虽然SQL作为一个示例被提到，但是存在许多其它示例数据库语言和向数据库陈列的界面，其中的任何一个可以结合这里描述的技术被使用。

进程语言/结构化查询语言（“PL/SQL”）通过提供在进程语言中得到的结构、产生比标准SQL更强大的结构语言来扩展SQL。PL/SQL命令被组织成变量说明的块、包括进程和SQL命令的子命令、和异常处理命令。PL/SQL命令可以被发送给数据库服务器以使得当PL/SQL命令被执行时数据库服务器执行各种动作。数据库服务器也可以接收并且执行基于Java的命令、远程进程调用命令、或符合其它编程语言或结构的命令。

多个数据库命令可以以单个请求的形式被从数据库客户端发送到数据库实例以执行工作。数据库命令可以由数据库实例处理，并且数据库实例可以以对请求中提出的所有命令的单个响应的形式向数据库客户端返回结果。在单个来回请求和响应中处理多个命令可以产生数据库连接的高效利用。换句话说，当允许对使用数据库连接的请求提交多个命令时，客户端一般使用数据库连接以较少频繁地提交请求。

应用和逻辑连接

诸如中层服务器之类的服务器向从数据库请求信息的应用提供数据库实例连接。中层服务器是提供对一个或多个数据库的访问的服务器、向一个或多个数据库服务器分布工作、或管理对一个或多个数据库服务器的连接的服务器。应用是运行在一个或多个计算设备上的使用数据库连接以从数据库检索信息的任何逻辑。可以向应用的用户呈现或显示检索的信息。例如，可以从浏览器访问应用，其中应用从用户接收输入并且向用户呈现信息。应用可以是经由网络入口、通过网络、由用户访问的应用，可以是被安装在用户的机器上的应用，或可以是在多个机器之间分布的应用。

在一个示例中，

应用特定地被配置为从

数据库检索数据，并且向

应用的用户显示信息。当前存在除了

应用的之前应用，并且在没有脱离本公开的情况下，将来可以发展其它数据库应用。

在一个示例中，应用向中层服务器发出对于来自于数据库中的数据的请求。请求可以或可以不响应于用户输入被发送。中层服务器从池中自由的连接当中选择到数据库实例的自由连接。已被选择和/或定制以便由一个客户端或一组客户端使用的数据库连接这里被称为“数据库会话”。数据库连接可以被定制以满足用于特定客户端的数据库会话的特定需要，或连接可以被一般化以使得连接可以用于支持用于各种客户端的各种数据库会话。中层服务器在选择的连接上将客户端请求发送到数据库实例，并且数据库实例访问数据库以处理该请求。数据库服务器通过检索或修改数据库中的数据或通过检索或修改来自于数据库的数据的高速缓存中的数据，来处理请求。当数据库服务器处理请求时，数据库服务器建立用于数据库会话的状态。

中层服务器通常保持连接池，其包括到数据库实例的连接。连接可以指代或者诸如物理端口之类的物理机制，或者逻辑配置，或者两者。可以存在逻辑连接（即，数据库会话）到物理连接的一对一映射。另一方面，可以存在与单个物理连接相关联的多于一个逻辑连接。在一个示例中，连接池中的自由连接仅仅包括没有被分配给用于处理请求的应用的那些连接。当工作完成时，连接被返回到连接池并且可用于随后的应用从池中借用。

数据库会话对应用不可用的效果

当应用使用数据库会话以访问数据库时，应用在数据库会话上建立状态。例如，应用使用数据库会话以获得锁定、创建临时变量或者数据库对象、建立用户特定信息、建立应用特定信息、建立游标信息、创建数据的临时布置或者选择、和/或对数据执行其它部分地完成的操作以用于在数据库会话中进一步处理。如果数据库会话在进一步处理发生之前失败，则锁定、临时变量或者数据库对象、用户特定信息、应用特定信息、游标信息、数据的临时布置或者选择、和/或部分地完成的操作变得对应用不可用，即使应用试图在新的数据库会话中参考此信息。

在一个示例中，如果数据库会话所依赖的数据库实例失败或变得不可用，数据库会话可以失败或变得不可用。大多数情况下，数据库会话的失败引起应用失败，因为进行中的数据库会话丢失。应用的用户必须重启应用或应用的组件并且重新开始登录、打开游标和检索数据、获得锁定、创建临时变量或者数据库对象、建立用户特定信息、建立应用特定信息、建立游标信息、创建数据的临时布置或者选择、和/或部分地完成对数据的操作以用于在数据库会话中进一步处理。在一个示例中，在数据库会话的失败时，用户可以被呈现蓝屏或者用错误消息打断。

在先前的客户端-服务器系统中，如果在客户端与服务器之间存在断开，则客户端看见指示通信失败的错误消息。此错误不通知客户端提交执行了任何提交（commit）操作或者是否进程调用运行到完成执行全部预期的提交和会话状态改变或部分失败，或还更坏的，仍然正在脱离客户端运行。

如果客户端想知道向数据库的提交是否被提交，则客户端可以已经增加定制异常码以查询用于在应用中每个可能的提交点的结果。假定系统可以在任何地方失败，这通常不切实际，因为查询必须是特定于每个提交。在应用被建立并且处于生产中之后，这完全不切实际。此外，因为事务可以在执行查询之后立即提交，所以查询不能给出准确的答案。甚至，在通信失败之后，服务器仍然可以运行提交，而还不知道客户端已经断开。对于PL/SQL或Java操作、或提交到数据库的其它进程，不存在关于进程提交是否运行到完成或被部分放弃的记录。当它可以已经提交时，对于该进程，后续工作可能未被完成。

没能识别最后一个提交已经提交或不久某时应当提交或没有运行到完成可以导致重复的事务提交，以及如用户和软件可能试图再发出持久改变的其它形式的“逻辑损坏”。

现有技术不提供关于在资源变得不可用时由资源执行的工作的信息。例如，应用不知道在有计划或非计划的停运的情况下由资源处理的最后一个操作的结果。如果服务器在执行一组命令时并且在服务器向客户端发送对于该组命令的响应之前停止，则客户端不知道该组命令在停运之前是否由服务器执行。甚至高度复杂的应用可以将停运暴露到终端用户。

由于错过的商业机会、利用坏的数据做出的决定、消除故障费用、和在重启应用或重新做工作中的损失时间，体验资源停运的用户可能沮丧并且可以丢失收入。一些应用警告用户不要点击提交按钮两次，并且在不是用户没有留心警告时，如果允许两个提交完成，则可以创建重复的事务。

在另一个示例中，一旦数据库会话已经失败，用户可以被阻止输入任何信息或引起任何命令在重新加载页面之前被提交到数据库。同时，在没有检查什么数据被存储到数据库的情况下重新加载页面可以导致重复的提交。如果需要的信息不再可用。则应用可以阻止用户提交取决于在失败的数据库会话中丢失的状态的任何命令，或应用可以不正确地行为。在特定示例中，已经向用户呈现的字段可以变灰以指示，为了避免损坏存储在数据库中的数据，字段不再能由应用修改。

即使数据库会话失败转移到第二数据库实例，第二数据库实例可以不具有任何关于在失败之前提交到数据库的事物以外的数据库会话的信息。为了避免损坏数据库中的数据，应用可以将向用户显示的信息复位到匹配已经向数据库提交的数据的信息。换句话说，当数据库实例失败时，用户可以丢失恰好在失败之前已经对用户可用的临时信息。一些丢失信息可以对应于被利用目前不可用的数据库会话的应用和/或用户显示、修改、选择、或布置的信息，或本来要被返回到在目前不可用的数据库会话上的应用和/或用户的信息。用户通常被强迫再次再输入数据的字段。

已经由用户输入、修改、选择、和/或布置的信息的丢失可以导致用户沮丧和在应用或应用组件已经重启之后在信息的再输入、再修改、再选择、和/或再布置中浪费的时间。丢失的信息可以是由用户从其它，例如由视频、语音、电子邮件、或文本消息中检索的信息。在一些情况下，丢失的信息可以不再是可检索的。当用户在失败发生时正在由支持服务提供者帮助时，丢失信息可以是特别昂贵的。信息丢失可以需要与支持服务提供者进一步通信，或甚至可以使得用户不再信任应用、中层服务器、或数据库服务器、或提供应用、中层服务器、和/或数据库服务器的公司。此外，在失败之前用户可以在选择、输入、或修改时间敏感的信息。在失败之后需要用户再输入时间敏感的信息可以导致延迟，其引起用户对商业客户或用户的商业投资的商业、价值、或名声的损失。需要再输入也可以导致对于用户的机会的丢失。例如，用户可以漏掉用户先前已经选择的项或机会。

在本节中描述的方法是可以从事的方法，而不必然是以前构思或从事的方法。因此，除非另有陈述，不假定本节中描述的方法中的任何一个由于它们仅仅包括在本节中而获得现有技术的承认。

快速应用通知

应用开发者开发处理基础软件、硬件、基础通信层、或服务器-客户端系统中的其它资源的报告的停运的应用。例如，自从Oracle10g以来，快速应用通知（“FAN”）在资源到来（即，变得可用）或停止（即，变得不可用）时向应用传送通知，并且应用开发者可以响应于通知自定义它们的应用以改变应用行为。

附图说明

在附图中：

图1示出用于在重演驱动器级别记录工作、指导驱动器、管理重演上下文、和完成事务幂等的示例服务器-客户端工作流。

图2示出用于由连续性管理、重演驱动和用于实现事务的最多一次执行的幂等协议驱动的数据库系统的故障转移的示例服务器-客户端工作流。

图3示出用于客户端-驱动器重演（被定义为重演驱动器）和基于网络逻辑服务器的重演的示例架构和组件放置。

图4示出用于指导客户端存储为了可以或可以不是事务性的命令的可能重演而维持的信息的示例计算机执行的方法。

图5示出用于从客户端接收信息以重演可以或可以不是事务性的命令的示例计算机执行的方法。

图6示出了可以被特定配置为执行这里描述的示例方法的示例计算机系统。

具体实施方式

在下面说明书中，为了说明目的，阐述许多细节以便提供对本发明的彻底了解。但是，将清楚，没有这些细节可以实践本发明。在其它实例中，以方框图形式示出公知的结构和设备以便避免不必要地模糊本发明。

一般概述

这里公开用于恢复数据库会话的状态的技术。所述技术也可以用于确定事务性的一组命令已经完成或部分地完成。例如，如果事务已经提交但是其它事务没有提交，如果对于该组命令存在更多信息用提交结果返回，或如果存在另外更多的工作由服务器进行以完成该组命令，则该组命令可以被部分地完成。虽然所述技术可以参考具体的实施例进行描述，但是这里描述的功能性可以由操作在一个或多个计算设备上的专用软件和/或硬件执行的方法的执行、由在被执行时上的方法的执行的一组一个或多个存储的指令、或由被配置有专用硬件和/或软件以执行方法的一组一个或多个机制来提供。

利用这里描述的技术，建立在第一服务器实例与客户端之间的第一数据库会话上的状态可以被恢复到第二服务器实例与客户端之间的第二数据库会话。影响会话中命令的执行但是不持久到数据库的状态被称为非事务会话状态。诸如对第一会话创建的变量、对象、参考、和设置之类的非事务会话状态可以通过在第二会话中重复非事务命令来保存。只有当事务在第一会话中并未提交时，事务才可以在第二会话中执行。

在一个实施例中，第一服务器实例在第一服务器实例与客户端之间的第一会话中向客户端发送为了在到用于在第一会话中执行的第一服务器实例的请求中发送的命令的可能重演而维持的信息。如果第一会话变得不可用或如果客户端希望将第一会话的状态重建到第二会话，则命令可以被在第二服务器实例与客户端之间的第二会话中重演。如果根据维持的信息在第二会话中重演，则命令将重建在第一会话中在第一服务器实例与客户端之间建立的状态，而不必重新做出在第一会话中已经做出的对数据库的任何改变。如果在第一会话中命令已被完全地执行或部分地执行，则命令可以已经使得第一服务器实例提交事务以对数据库做出改变。在一个实施例中，命令确实使得第一服务器实例完成事务以对数据库做出改变。

图4示出用于指导客户端存储为了可以或可以不是事务性的命令的可能重演而维持的信息的示例计算机执行的方法。在步骤400中，通过检查从连接池出来的第一会话和/或标记会话以开始请求，在第一服务器实例与客户端之间建立第一会话。在步骤401中，请求的开始由客户端发信号并且由第一服务器实例检测。在步骤402中，第一服务器实例从客户端中接收一个或多个命令以用于在第一会话中执行。所述一个或多个命令包括零命令或如果被执行将提交事务以对数据库做出改变的至少一个命令。在步骤404中，第一服务器实例向客户端发送为了一个或多个命令在第二服务器实例与客户端之间的第二会话中的可能重演而维持的信息。信息支持重演，而不用做出在第一会话中已经做出的对数据库的任何改变。对于请求中一组命令，第一服务器实例可以重复步骤402和404。在对于请求中的一组命令，第一服务器实例重复步骤402和404之后，在步骤405中，请求的结束由客户端发信号并且由第一服务器实例检测。为了对请求的结束发信号，会话可以被返回到连接池，和/或请求可以被标记为结束。

第一服务器实例可以通过发送客户端指示来指导客户端维持信息，并且维持的信息可以由第二服务器实例使用以将第一数据库会话的状态恢复到第二数据库会话。在一个实施例中，指示可以被在客户端与第一服务器实例之间发送的消息上背负。例如，指示可以被在包括在第一会话中执行命令的结果的消息上背负。示例指示包括但是不局限于“放在队列N中”、“禁止重演”和“清楚队列N”。

请求是在数据库会话上从应用提交到服务器实例的工作的单元。请求可以包括或参考诸如SQL和PL/SQL之类的数据库命令，和在单个数据库连接上的单个网络请求的其它数据库调用。请求可以由对从连接池离开数据库连接然后签到所做出的调用来划定。

在一个实施例中，中层服务器将逻辑连接分配到请求访问数据库的应用。逻辑连接被直接或间接地映射到多个物理连接中的一个。逻辑连接在没有再分配新的逻辑连接到应用的情况下可以被再分配给新的物理连接。逻辑连接可以被暴露于应用，并且所述应用可以继续参考相同的逻辑连接作为底层的物理连接改变。在一个示例中，特定逻辑连接被表示为暴露于应用的连接对象并且被映射到另一个连接对象，另一个连接对象可以或可以不暴露于该应用，并且其可以或可以不是另一个逻辑连接。经由逻辑连接的分层结构，特定逻辑连接被映射到物理连接。

在一个实施例中，第一服务器实例使得客户端维持与不与事务相关联的信息不同的队列或存储位置中的事务相关联的信息。以这样的方式，在事务完成时关于事务的信息可以被清除或清零，只要在事务队列上的命令也没有变更由较晚命令使用的非事务状态。例如，第一服务器实例可以指导客户端存储与第一队列中的事务有关的第一组信息和不与在第二队列中的事务有关的第二组信息。当完成事务时，第一服务器实例可以根据不持久的状态如何被改变和使用，指导客户端清除或清零存储在第一队列中的信息。如果试图将状态恢复到第二会话，则客户端可以在不重演在重演之前清零的其它命令的情况下重演一些命令。

在一个示例中，第一服务器实例使得客户端维持用于在第一会话中执行的事务和非事务语句的分离的信息组。在示例中，第一组信息可以识别做出还没有在数据库中变成持久的临时改变的语句。当临时改变被使得持久或提交到数据库时，如果这些语句也没有做出非事务状态改变，则第一服务器实例可以有效地指示客户端清除或清零第一组信息。第二组信息可以识别诸如非事务语句之类的在第一会话中完成的事务之前和之后执行的语句，因此不是事务的一部分。取决于检测到的操作模式，清除第一组信息可以保留第二组信息在客户端处完整，以使得在第二组信息中识别的非事务语句仍然可用于重演。重演在第二组信息中的非事务语句可以使得第二服务器实例在第二会话中重建本来在第一会话中建立的非事务状态或如果由客户端在请求中发送的命令组已被执行到完成则将已经在第一会话中建立的非事务状态。

相反地，如果第一组命令中的语句，即事务，也做出非事务状态改变，则当该事务提交时，第一和第二组信息重演可以被禁止并且两个队列被清除。事务内部的这些语句可以设置在数据库中非持久的并且在事务提交之后不能恢复的状态，除非保持第三组命令。例如，变量可以在INSERT或UPDATE语句之后，但是在INSERT或UPDATE已被提交到数据库之前被定义。可以使用清除和禁止来避免当试图重建非事务状态时参考丢失的信息的风险并且避免重复事务的风险。在此第二情况中重演不是有效的，因为它将包括重演提交的事务，除非诸如使用第三组命令在不持续事务状态的情况下重建该状态。

在一个实施例中，命令可以不被放在任何队列中。例如，如果由SELECT请求的信息是在重演时再次需求的元数据，则SELECT语句可以不是重演需要的。这些命令如果它们对重演需要，则可以根据需要被排队。当请求执行时，命令可以被从队列中清除，因为所有数据已被从它们返回并且它们不是建立非事务状态所需的。

如果所有会话状态改变（例如NLS设置、PL/SQL包状态）以部分初始化的形式出现，或相反在所有事务外，并且可以在故障转移时被封装在回调函数中，则限定会话具有静态。如果客户端正在静态中操作，则应用后来不依赖于或参考由在提交的事务期间执行的非事务语句设置的信息，或在请求已经初始化之后不会做出非事务改变。如果事务已经完成，则在非持久的事务期间创建的状态不需要被恢复到第二会话，因为一旦事务已经提交后，后来的命令不依赖于或参考所述信息。因为后来的命令不依赖于在事务内部设置的非事务信息，所以当事务提交时，存储在事务队列中的信息可以从事务队列中安全地清零。这类应用通常被称为数据库不可知论。它不改变PL/SQL变量或在请求执行期间改变非事务状态的其它结构。

如果会话状态改变通过初始化没有被充分地封装并且在故障转移时在回调函数中不能被充分地捕获，而是包含在请求内，则限定会话为具有动态。如果应用正以动态模式操作，则应用可以或可以不依赖于或参考由在事务期间执行的非事务语句设置的信息。因为已经在第一会话中执行的事务不能在第二会话中重复，所以套在事务之内的非事务语句在事务提交并且完成之后可能不可用于在第二会话中重演，除非维持第三组命令。

如果非事务状态没有在请求之内改变，则静态可以被检测。对于静态模式，在提交之后，事务队列被清除并且重演可以继续。如果非事务状态在请求之内改变，则动态可以被检测。动态被进一步特征化为是否在提交的事务期间改变的非事务状态在事务提交之后由命令后来参考。

在对于静态的一个实施例中，第一服务器实例接收请求以执行命令并且在命令的执行之前或期间，检测请求中的事务不仅包括向数据库提交改变的事务命令，而且包括改变会话的状态但是可以不向数据库提交任何改变的命令。不是所有的请求都包括事务命令，更不必说设置非事务会话状态的事务命令了。许多应用默认在事务中不设置非事务会话状态或至少同意不依赖于（或后来使用）在事务期间设备的任何非事务会话状态。不设置非事务会话状态的事务可以在它们完成时被清除以使得这些事务不被重复。

在对于动态的一个实施例中，在检测到提交的事务设置非事务会话状态时，第一服务器实例然后可以确定在该请求中的后来的命令是否使用非事务会话状态。如果在请求中的后来的命令不使用非事务会话状态，则非事务会话状态可以在事务的完成或之后随着事务被清除。当第一服务器实例将指令发送客户端以删除可以被存储在诸如队列之类的第一数据结构中的关于事务的信息时，清除发生。在此情况中，因为状态和事务被清除，并且因为状态不被请求中的后来的命令使用，所以请求中的命令可以在不重建状态并且不重复事务的情况下被重演。

在对于动态的一个实施例中，如果请求中的后来的命令可以使用非事务会话状态，则当事务完成时非事务会话状态不能随着事务清除。在这种情况下，第一服务器实例可以将信息发送到客户端，该信息描述如果被执行则将设置非事务会话状态而不重复事务的命令。在一个示例中，这些命令可以包括来自于事务的许多或所有命令，而不必采取锁定并且排除提交操作。换句话说，即使事务已经完成，第一服务器实例也可以将事务的命令发送到客户端，继之以回滚操作。命令可以被进一步处理以执行诸如取出对数据库中的共享数据对象的锁定、修改数据之类的非事务动作，并且也不违反完整性约束。

在对于动态的一个实施例中，如果在请求中的后来的命令可以使用非事务会话状态，并且如果非事务会话状态在不提交事务的情况下不能被恢复，则第一服务器实例确定后来的命令可以依赖于非事务会话状态的检查点。服务器可以指示客户端记录没有出现在事务中但是可由第二服务器实例使用以恢复由事务做出的非事务会话状态改变的专用命令。在一个示例中，利用透明会话迁移，状态被记录为由事务做出的完全或δ状态改变。此状态改变可以由在不重复任何事务的情况下实行状态改变的一个或多个命令表示。

对于动态，考虑其中请求包括SELECT、INSERT、ALTER、PL/SQL、COMMIT、和SELECT语句的以此顺序的示例。第一SELECT可以被放在非事务队列中。INSERT可以随着ALTER和PL/SQL一起被放在事务队列中，其在事务期间执行。COMMIT的执行使得事务队列在静态中操作时被清零。如果ALTER和PL/SQL仅仅做出非事务改变，则这些可以被放在非事务队列中。此处理保留事务队列为空并且第一SELECT、PL/SQL和ALTER在非事务队列中。

在另一个示例中，如果非事务状态在事务之内改变并且命令不能被定位到非事务队列，则在一个实施例中，服务器实例可以指导客户端清除所有队列并且禁止重演，直到请求结束。当下一个请求开始时重演将再启动。只有当非事务状态改变在成功地提交的事务内被检测到并且非事务状态由后来的命令依赖时，重演被禁止。重演在提交、或者在依赖该状态的命令处被禁止。大部分请求包含不多于一个提交并且将提交当作最后一个语句，并且至少在这些情况下，禁止不是问题。禁止对于网络请求是有效的技术，因为它在运行时间处没有负担。

对于执行提交的请求并且如果紧接在提交执行但是提交结果和指示没有由客户端接收到之后发生停运，则重演返回提交的状态。以这种方式，用户或应用知道最后一个事务的结果。当利用静态时，事务队列被清除并且对于请求的捕获继续直到请求结束。当利用动态时，在成功提交之后重演被禁止或者第三组命令被维持以恢复那个状态。

在一个实施例中，第二服务器实例在第二服务器实例与客户端之间的第二会话中从客户端接收在第二会话中维持的、用于在从客户端到第一服务器实例的请求中发送以在第一会话中执行的命令的可能重演的信息。第二服务器实例根据由客户端维持的信息重演第二会话中的命令以重建在第一会话中在第一服务器实例与的客户端之间建立的状态，而不必重新做出在第一数据库会话中已经做出的对数据库的任何改变。如果命令已在第一会话中被完全地执行或部分地执行，则命令可以已使得第一服务器实例完成事务以对数据库做出改变。在一个实施例中，命令确实使得第一服务器实例完成事务以对数据库做出改变。

图5示出用于从客户端接收信息以重演可以或可以不是事务性的命令的示例计算机执行的方法。图4和5可以被分开或一起执行。在步骤500中，在第二服务器实例与客户端之间建立第二会话，用于在第一会话中在从客户端到第一服务器实例的请求中预先发送的命令的可能重演。在步骤中501A，在存在另一个停运情况下，第二服务器实例可以重建快速应用通知。在步骤501B中，请求的开始由客户端发信号并且由第二服务器实例检测。在步骤502中，第二服务器实例从客户端中接收被维持用于在第一会话中在从客户端到第一服务器实例的请求中发送的一个或多个命令的重演的信息。所述一个或多个命令包括零命令或如果被执行将提交事务以对数据库做出改变的至少一个命令。在步骤504中，第二服务器实例根据由客户端维持的信息重演并且确认用于第二会话中的一个或多个命令的重演，以重建在第一会话中在第一服务器实例与客户端之间建立的状态，而不必重新做出在第一数据库会话中已经做出的对数据库的任何改变。对于用于在第一会话中执行的先前发送的多个命令，步骤502和504可以被重复。在第二服务器实例对于用于在第一会话中执行的先前发送的多个命令重复步骤502和504之后，并且如果对于步骤504的每个迭代确认成功，则在步骤505A中，重演结束并且客户端返回到用于相同请求的捕获模式。在步骤505B中，请求的结束由客户端发信号并且由第二服务器实例检测。

在一个实施例中，为重演接收的信息包括不同组信息，一组与在第一数据库会话中没有被完成或提交的事务相关联并且另一组不与事务相关联。与在第一会话中完成或提交的事务相关联的信息可以随着事务完成而被清除。换句话说，与已完成事务相关联的信息可以不被包括在为重演接收的信息中。

在一个实施例中，第二服务器实例接收用于在第一会话中执行的事务和非事务语句的单独的各组信息。例如，第一组信息可以识别做出还没有在数据库中变为持久的临时改变的语句。当临时的改变变为持久的或被提交到数据库时，客户端可以清除或清零第一组信息。第二组信息可以识别诸如非事务语句之类的在第一会话中完成的事务之前和之后执行的语句。清除第一组信息可以保留第二组信息在客户端处完整，以使得在第二组信息中识别的非事务语句仍然可用于重演。重演第二组信息中的非事务语句可以使得第二会话中的第二服务器实例重建本来在第一会话中建立的非事务状态或如果在请求中由客户端发送的命令组已被执行到完成则将已经在第一会话中建立的非事务状态。

在一个实施例中，随着事务被提交而被清零的第一组信息也可以识别在事务期间执行的函数或语句，即使那些语句没有对数据库做出任何改变。这些语句可以设置在数据库中不持久、但是可以在事务已经完成之后保持在第一数据库会话中的状态。如果客户端正在使用静态，则此信息可以被存储在事务队列中并且随着事务完成从事务队列中安全地清零。另一方面，如果客户端正在使用动态，则当事务被清零时非事务信息可以丢失。为了避免依赖于丢失的非事务信息的风险，禁止重演，直到请求结束，以安全地消除逻辑损坏的任何可能性。在一个实施例中，第二服务器实例可以试图重演非事务命令，即使非事务命令被套在事务之内，根据需要修改命令以保证适当的从属性在工作以支持非事务命令的执行并且还保证第二服务器实例不重新执行已经在第一会话中执行的任何事务。在此实施例中，虽然命令在事务内执行，但是它们被放置在非事务队列中以便不被清除。

在重演期间，每个重演的命令被确认。输入的命令一定具有恰当的安全性、恰当的协议、和恰当的环境。在执行之后，返回到客户端的所有结果必须与它们在第一执行期间的完全相同。这包括行、和行阶、外绑定（out bind）、错误码和错误消息。应用或客户端潜在地对其作出决定的每个信息段必须与它们在原始执行期间的完全相同。如果被放置在从服务器到客户端的线路上的任何值与原始的有改变，则重演被拒绝并且客户端看见原始错误。相反地，如果客户端执行不向客户端返回结果的服务器侧代码，则客户端信赖此代码执行并且在不推论的情况下结果可以不同。在此实施例中，针对诸如在原始和重演处计算的CRC之类的校验和对返回的值加以检查。当硬件支持可用时，校验和的成本被转嫁给硬件。

在重演之前和之后，相关非事务环境对于重演成功必须是正确的。即，诸如小数点位置、语言、货币、sys_context等等之类的设置每个可以影响存储的结果并且必须与原始执行一样。检查出现在执行之前以保证要被重演的调用具有正确的环境状态，并且在执行之后，因为当前调用可以是客户端为其保持信息的最后一个调用，并且下一个调用必须在恰当的环境中执行。在此实施例中，对照环境哈希值对环境加以检查。如果有检查失败的话，则重演被拒绝并且返回原始错误。

在一个实施例中，命令由第二服务器实例在原始的系统改变数（“SCN”）或由第一服务器实例执行命令的逻辑时间重演，直到到达不能在原始SCN重演的命令。从那点向前，命令将被在当前SCN处重演。随着命令被重演，来自于重演的客户端可见的结果与在运行时间期间获得的客户端可见的结果相比较，如在重演上下文中指示的。

在一个实施例中，第二服务器实例从客户端接收描述如下命令的信息：即如果该命令被执行，则将设置在第一会话中完成的事务期间设置的非事务会话状态，并且第二服务器实例使用此信息在第二会话中重建非事务会话状态而不重复事务。在一个示例中，这些命令可以包括来自于事务的许多或所有命令和/或将锁定任何共享数据的操作。信息可以描述没有出现在第一会话中完成的事务中但是可由第二服务器实例使用以重建非事务会话状态的专用命令。

在一个实施例中，如果在请求中后来的命令可以使用非事务会话状态，并且如果非事务会话状态在不提交事务的情况下不能恢复，则第二服务器实例也从客户端接收后来的命令可以依赖于非事务会话状态的检查点。当第二服务器实例在重演期间到达检查点时，重演被禁止并且事务不被重复。在一个示例中，使用透明会话迁移记录状态，获取由事务改变的全部状态或Δ状态。此状态改变可以由在不重复任何事务的情况下实行状态改变的一个或多个命令表示。

可变函数和重演

当请求被重演时，可变对象的默认和期望的处理可以改变。可变函数是每次被调用时获得新值的函数。每当函数被调用时，新值可以改变。可变的示例是对SYSTIMESTAMP函数的调用。在停运之后被恢复的客户端应用可以确定如果请求被重演是否保持或忽略可变函数的结果。

可变函数值可以对于SYSDATE、SYSTIMESTAMP、CURRENT_TIMEZONE、SYS_GUID、和sequence.NEXTVAL被保持。对于诸如MIN、MAX、CURRENT_TIMESTAMP、LOCAL_TIMESTAMP等等之类的许多其它可变函数，可变值也可以被保持。如果原始值不被保持并且如果用于这些可变函数的不同的值被返回到客户端，则重演将被拒绝，因为客户端可以看到不同的结果。如果应用可以使用原始值，则应用可以使用用于拥有的序列的新的KEEP子句和用于其它用户的GRANT KEEP来配置可变函数的行为。在用于许多应用的重演时，序列值可以被保持以提供绑定变量一致性。

表1.1显示在重演期间由产品对可变函数的处理的示例。（实际实施方式取决于特定产品并且版本。）

表1.1:在重演期间由产品对可变对象的处理示例

可变函数	产品1	产品2	产品3
				SYSDATE,SYSTIMESTAMP	原始	原始	当前
序列NEXTVAL和CURRVAL	原始	原始	（不适用）
				SYS_GUID	原始	（不适用）	（不适用）

可变函数	产品1	产品2	产品3
				LOB访问	在失配上失败	（不适用）	（不适用）

为了允许重演以在重演时保持并使用原始函数结果：

·运行应用的数据库用户可以对其值将被保持的每个序列具有授予的KEEP DATE TIME和KEEP SYSGUID特权、以及KEEPSEQUENCE对象特权。例如：

·授予KEEP DATE TIME给用户2；

·授予KEEP SYSGUID给用户2；

·授予sales.seq1上的KEEP SEQUENCE给用户2；

注意GRANT ALL ON<object>不包括KEEP DATE TIME和KEEP SYSGUID特权以及KEEP SEQUENCE对象使用特权（即，不授予由它们提供的访问）。

不授予DBA特权给运行重演被使能的应用的数据库用户。仅仅授予此类用户所需的特权。

应用中的序列可以使用KEEP属性，其对于序列拥有者保持sequence.NEXTVAL的原始值，以使得关键字在重演期间匹配。序列值在用于许多应用的重演时可以被保持。下列示例设置用于序列的KEEP属性（在这种情况下，由用户拥有的一个执行语句；对于其它，使用GRANT KEEP SEQUENCE）：

·SQL>CREATE SEQUENCE my_seq KEEP;

·SQL>--Or,if the sequence already exists but without KEEP:

·SQL>ALTER SEQUENCE my_seq KEEP;

注意指定ALTER SEQUENCE...KEEP/NOKEEP应用于序列的拥有者。它不影响具有KEEP SEQUENCE对象特权的其它用户（不是拥有者）。如果NOKEEP被指定，则KEEP SEQUENCE对象特权不被授予这些用户（或如果它已被授权给他们，则它被从每个撤回）。

·为了在重演时保持函数结果（对于命名的函数），DBA授予KEEP特权给调用函数的用户。这些安全性限制保证它对重演有效以保存和恢复用于不被那个用户拥有的代码的函数结果。

下列额外考虑应用于对可变函数授予特权：

·如果用户具有对可变值授予的KEEP特权，则当SYS_GUID、SYSDATE和SYSTIMESTAMP函数被调用时，对象继承可变访问。

·如果对序列对象上的可变值，KEEP特权被撤回，则使用那个对象的SQL或PL/SQL块将不允许可变集合或应用用于那个序列。

·如果授予的特权在运行时间和故障转移之间被撤回，则被收集的可变值不应用于重演。

·如果新的特权在运行时间和故障转移之间被授予，则可变值不被捕获并且这些值不应用于重演。

定义

“可恢复的错误”是由于外部系统故障而出现的一类错误，独立于正在执行的应用会话逻辑。可恢复的错误接着前台、网络、节点、存储和数据库的计划和非计划停运出现。应用接收错误代码，可以让应用不知道提交的最后一个操作的状态。重演重建数据库会话和重新提交待定的工作以用于此类可恢复的错误。重演驱动器由于无法恢复的错误接着调用失败没有重新提交工作。不会自动地重演的无法恢复的错误的示例是无效数据值的提交。这里描述的技术可以重建数据库会话并重新提交待定的工作以用于此类可恢复的错误。一些错误可以不是可恢复的，并且对于这些错误，工作不被重新提交。

请求是在数据库会话上从应用提交到服务器实例的工作的单元。请求可以包括或参考诸如SQL和PL/SQL之类的数据库命令，和在单个数据库连接上的单个网络请求的其它数据库调用。请求可以被对登出和登记从连接池到数据库连接的连接而做出的调用来划定。重演重建用于数据库会话的事务和非事务状态并且对于可恢复的错误重复所述请求。

“可重复的操作”是在可恢复的错误之后可以被重复的命令或命令组。例如，可以重复未提交的事务或非事务命令。重演可重复的操作组为数据库会话重建非事务状态并且可以为可恢复的错误重复未提交的数据库事务。当请求被重演时，执行看来像是应用和客户端，就像请求被稍微延迟一样。当数据库稍微慢地执行请求以致对客户端的响应被延迟时，效果可以与加载的系统相似。

在

中，通过更新事务表中事务的条目来提交事务。

生成与此更新对应的重做记录并且写出此重做记录。一旦此重做记录被写出到盘上的重做记录，事务被认为在数据库处提交。从客户端视角，当在重做被写入之后生成的

消息（称为提交结果）由客户端接收到时，事务被认为提交。但是，提交消息不是持久的。重演在它已被丢失时获得可用的提交结果以便重演事务至多一次。

“非事务会话状态”或“NTSS”是存在于事务外部或远离事务的会话的状态。NTSS可以经由说明性或进程机制创建。说明性机制的示例是用于MODULE、ACTION、OPTIMIZER_PLAN、NLS_DATE等等的属性设置。进程机制的示例是填充全局变量、LOB处理、和AQ处理的PL/SQL进程。表1列举可以为应用用户设置的示例状态。示例技术使用应用回调来设置初始状态，并且然后经由原始调用工作以再次按序建立状态。

表1.2：用于重建非事务状态的示例方法

“可变函数”是用于每当被执行时可以改变它们的结果的函数的术语。可变函数对于重演产生问题，因为所述结果在重演处可以改变。考虑用在关键字值中的sequence.nextval和sysdate。如果主关键字被建立具有从这些函数调用的值，并且用在后来的外来关键字或其它绑定中，则在重演时相同的函数结果必须被返回。应用连续性为授权的函数调用在重演时提供可变值替换以提供不透明的绑定-变量的一致性。如果调用使用包括sequence.nextval、SYSDATE,SYSTIMESTAMP、SYSGUID的可变函数的数据库函数，则从函数执行返回的原始值被保存并且在重演时被再运用。

会话状态一致性

如果所有会话状态改变（例如NLS设置、PL/SQL包状态）以部分初始化的形式出现，并且可以在故障转移处被封装在回调函数中，则会话具有“静”态。

如果会话状态改变通过初始化没有被完全地封装、在失败转移时不能被完全地捕获、并且否则被包括在请求期间执行的一个或多个命令中，则会话具有“动”态。

恢复会话状态的示例益处

示例益处可以从这里描述的各个实施例实现，但是对任何特定实施例并非保证特别有用。这里没有具体说出的其它益处也可以被实现。这里描述的技术可以允许会话不可利用性被对最终用户和/或应用影藏，不管会话不可利用性是计划的还是非计划的。对第一会话建立的状态可以被恢复或复原到第二会话，甚至在存在定制的用户环境、运行中的事务、和/或丢失结果的情况下。该技术也可以不考虑会话停运而允许服务器满足用于应用的目标响应时间。

第一服务器实例可以将最后一个事务的结果报告到客户端或应用，并且第二服务器实例可以恢复那个结果，继之以运行中的工作。服务器可以提供支持以在从服务器没有接收到对于执行命令的对应请求的响应的情况下处理停运。服务器可以支持当那个会话可以被重演时需要应用的定制的异常处理的较少使用的会话恢复。恢复会话可以是有用的，即使一些重演尝试不是成功的。确实对于当重演被禁止时的情况，应用仍然需要处理错误。但是在重演的情况下，大部分故障应当被掩盖。这导致对应用的错误处理逻辑的较少调用（即少于应用对用户出现错误，让用户不知道发生了什么，或强制用户再输入数据，或更糟的是管理员必须重新开始中层服务器以应付故障等等）。因此总的说来，重演应当给出更好的用户体验。

一旦用户请求已被提交，如果用户请求可以成功，则用户请求可以被允许成功。接着数据库会话的停运，如果会话可以被重演则用户不应该体验停运。在系统的一个部分中的停运不应该向终端用户或应用返回错误。如果事务失败并且是可重演的，则请求可以被在有限的时间中重演。如果重演成功，则成功的返回状态被返回到应用。在通信、系统、存储、或站点停运之后，停运不需要暴露于用户，即使这些停运在过去已被暴露。

用户可以能够限定工作的目标响应时间，而不考虑停运。用户不需要烦恼用于停运的较少的服务级。诸如银行、电信、股票事务、制造、运输、和零售之类的企业部门可以不容许降低的响应时间，不考虑底层的原因。降低的响应时间可以产生不可接受的竞争的不利。根据这里描述的各种技术，服务器可以对客户端掩盖服务器侧的停运，避免超出时间阈值的命令重演以避免不能预料的结果。

用于执行请求的示例服务器客户系统

许多数据库管理系统（“DBMS”）经由诸如Oracle调用接口（“OCI”）驱动器或Java数据库连接性（“JDBC”）驱动器之类的各个客户端驱动器接口向应用程序员提供基于事务的程序设计模型。经由驱动器，执行最高级的SQL和PL/SQL调用建立数据库会话的事务状态和非事务状态。客户端驱动器可以将SQL和PL/SQL调用发送到DBMS，并且在事务的结束处，改变被提交或回滚。图1示出示例服务器-客户端系统的不同组件和层。在示例中，客户端驱动器将SQL和PL/SQL调用发送到DBMS并且在事务的结束处，改变被提交或回滚。如图所示，对于数据库会话，非事务和事务状态被建立，并且随着对于对应事务的提交完成，事务状态被清零。

当使用连接池时，工作单元是请求。请求包括从连接池登出、SQL和PL/SQL调用和通常零或一个COMMIT操作。在应用将连接释放回到连接池时请求结束。重演在请求开始时被启动并且在请求结束时禁止。如果停运出现，则重演重复请求，除非如果在动态模式中重演已通过提交被禁止、或由用于一些请求的应用使用的明确禁止重演应用编程接口（API）。

在图1的示例中，可选地，如果条带和标记没有被完全设置，则连接管理器设置用于应用的条带和标记。应用发请求开始的信号，或者通过从连接池中登出连接或通过发送符合用于标记请求边界的应用编程接口的命令。在请求开始时，启动重演，并在数据库指导下捕获开始。客户端将SQL或PL/SQL发送到不包括事务的RDBMS。SQL引擎编译每个语句并且将请求发送到SQL引擎或PL/SQL引擎。执行语句在服务器处建立用于会话的非事务状态。服务器向客户端返回结果集合、输出绑定、DML返回结果、函数结果、和其它消息。当启动重演时，用于排队或清除重演的服务器背负指示加上用于确认和保证重演（如果需要）的重演上下文。一些结果将保持在客户端驱动器中并且由应用在它作出决策中使用。客户端将开始事务的SQL或包含一个或多个事务的PL/SQL发送到RDBMS。SQL引擎编译每个语句并且将请求发送到PL/SQL引擎（如果PL/SQL）并且发送到DML驱动器。这对于数据库会话建立事务状态和进一步非事务状态。包括任何错误消息的操作的结果被返回到客户端驱动器。再次，当启动重演时，服务器背负指示加上重演上下文。客户端将提交请求发送到RDBMS、或客户端已经设置涵盖此请求的自动提交或PL/SQL具有嵌入的COMMIT。SQL引擎编译语句并且将提交请求发送到事务层。事务层将变更记录刷入到盘。提交的成功在提交后被建立并且被返回到客户端。当启动重演时，服务器背负指示加上重演加上重演上下文。随着COMMIT结果，客户端也接收在提交结果上背负的将被使用的下一个逻辑事务标识符（LTXID）。

客户端驱动器将SQL或PL/SQL命令发送到服务器并且接收包含任何错误消息、背负的用于重演的指示和重演上下文的结果集合错误处理。此信息被保存在客户端驱动器处的存储器中。应用结果被转发到应用以用于处理。应用可以高速缓存结果和绑定值，并且在随后的查询和事务的将来处理中继续使用这些。重演指示继之以客户端驱动器。SQL或PL/SQL命令和重演上下文可以基于所述指示被保存。

在没有这里描述的技术的情况下，如果客户端输入工作并且将工作提交到服务器，则客户端期望潜在地具有输入的数据、返回的数据、和高速缓存的变量的目前状态。如果由于服务器侧组件的不可利用性或服务器与客户端之间的失败的连接而存在停运，则应用需要以操作的非事务会话状态将已经丢失。如果事务已被开始并提交并且没有被发出，则运行中的事务将被回滚并且将需要由客户端重新提出。如果事务已被开始并一个或多个提交已被发出，则被发送回到客户端的提交消息不是持久的。换句话说，客户端不知道请求是否被提交，并且当在非事务处理状态中时，命令在执行期间到达。

为了适应停运，应用可以被修改以包括用于重新连接、重建非事务会话状态、查询服务器以确定在故障时什么正在执行、并且然后确定工作是否被提交或需要被重复的自定义代码。但是，任何应用代码模块可以失败，并且基于应用逐模块开发自定义码以执行错误处理将是相当昂贵的。同样，在此情况中，用于客户端查询以确定事务已经提交与否也不是一般性的。自定义检查或许将不适应本地事务、分布式事务、并行事务、复制的事务、和扩展的体系结构或全局（XA）事务。此外，检查的操作可以在由客户端做出检查之后完成，并且客户端不能依赖于客户端侧检查的结果，因此此类解决方案使用起来不安全。

如果丢失事务被再次提交，则服务器-客户端系统可以保持原子性和一致性。如果非事务状态是不正确的或如果它已经被提交则事务不能被正当地重新提交。如果数据库已被恢复到较早的时间点、或者是不再包含决定数据的原本的部分复制的副本，则事务不能被自动地重新提交。

如果用于重演的数据库是不同的数据库或是相同的数据库但是数据库已经丢失提交的事务，则此实施例拒绝重演。此实施例自动地确定那些数据库是对于重演合法的和哪些不是。此实施例可以算入独立的数据库和加强加强的数据库。它允许从独立的数据库到插入到加强的数据库中的相同数据库的重演，和当把数据库从一个加强的数据库抽出并且插入到另一个时的重演。如果试图对不同的、潜在分歧的数据库重演，则实施例总是拒绝重演。

用于掩盖数据库停运的示例服务器-客户端系统

在一个实施例中，应用连续性架构限定应用与数据库之间的协议，以使得如果数据库会话变得不可用，则事务和非事务数据库会话状态被重建。当数据库会话变得不可用，被重新安置，或变得无响应时，重演驱动器与数据库合作试图重建影响的数据库会话。在应用或中层处的状态没有失败，因此数据库会话被重建到它们在故障之前的状态，可选地随着重演进行和在重演完成处确认客户端应用恢复的可见结果匹配之前停运结果。

在一个示例中，当请求等待答复的时间到了并且被重新提交或如果用户变得没有耐心并重新提交时，重演阻止较早的会话。原始提交被检测到并最近一个请求被提交，用于相同请求的任何其它运行中的被拒绝并回滚。

图3显示用于客户端驱动器重演（称为重演驱动器）和基于WebLogic服务器的重演的示例架构和组件放置。图示出例如已被配置为传送重演能力的组件的放置。示例服务器，Oracle12g RDBMS，管理数据库会话的连续性以使得数据库会话保持不间断，甚至在服务会话的服务器实例的停运期间。在运行时间期间，服务器将重演上下文和LTXID发送到客户端驱动器（例如，如图所示的JDBC重演驱动器或Oracle调用接口透明应用故障转移（OCI TAF）模块），并且客户端驱动器保存LTXID和重演上下文（在需要重演的情况下）。如果需要重演，则在数据库指导下，客户端驱动器重新提交每个命令。数据库使用LTXID以确定最后一个请求是否提交，并且，如果它没有，则阻止它这样做。数据库第一次使用重演上下文以在第二会话处确认安全性、数据库、协议和执行环境。在重演之后，数据库使用重演上下文以检查用户可见的结果与从原始执行中的那些一样，并且执行环境已被正确地重建。重演随着服务器利用重演上下文确认每个重演的保真度而进行。如果第一服务器变得不可用，则此处理允许重演驱动器和服务器合作恢复第二会话上的事务和非事务。重演可以在第三或第四会话上被重复继续直到重演成功。如果重演成功，处理返回到再次捕获请求。如果重演是不可能的，则原始错误连同已知的结果被提交与否被返回到应用或客户端。

样本架构组件

应用连续性的下列组件可以一起工作以执行捕获和重演：

FAN监视逻辑subscrib

重演驱动拦截执行错误并且，当这些错误是可恢复时，自动地从请求开始重演用户调用。当成功时，重演对应用看来像是作为延迟的数据库交互。

与数据库合作，重演驱动器维持在客户端与数据库之间的对话期间的调用历史。对于在运行时间处做出的每个调用，驱动器保持后续重演所需的上下文。

连续性指导器指导运行时间和重演，与重演驱动器合作。指导器知道什么是可重复的并且它应当如何重复，并且应用此知识如下：

·在运行时间期间，保存协议和确认信息（以及足够用于重演的可变函数），或者指导重演驱动器保持或者清除调用

·在重演期间，拒绝重演：

·在不同的数据库或者已经丢失事务和潜在偏离的数据库上执行

·违反协议

·没能再现应用或客户端看见并在原始执行期间潜在地作决定的相同的客户端可见的数据（行、外绑定、错误码、和消息）

重演上下文是在正常应用运行时间期间数据库返回到客户端驱动器的不透明信息。重演驱动器与驱动器被指示保持的每个SQL或PL/SQL调用一起保存上下文。重演上下文包含足够的知识以保护并确认每个调用的重演，并且当可变值已被保持时应用可变性。当调用不再对重演会话需要时，重演上下文随着调用本身被丢弃。

示例重演驱动器

JDBC重演驱动器和OCI事务应用故障转移（这里两者都称为重演驱动器）是用于在可恢复的数据库停运之后重演丢失的工作的应用连续性的示例组件。

按照由连续性指导器指示，重演驱动器维持在客户端与数据库会话期间的调用历史。每个重演驱动器维持调用的队列，并且对于在运行时间处的保持的每个调用保持后来的重演需要的重演上下文。当重演被明确地禁止时、并且在请求识别的结束处，通过在请求结束处（正常地，登记到驱动器池）释放积累的历史限制重演持续时间。重演驱动器记录在连续性指导器指导下，在每个请求的持续时期内的调用历史，对于完成的请求清除关闭的调用，以及对于被识别在请求期间没有改变非事务会话状态的应用清除SELECT调用和完成的事务。在另一个实施方式中，在请求期间保持的历史被标记以释放，并且释放出现在请求的结束或根据无用单元收集器的需要。

在由于计划或非计划的数据库服务的丢失引起的会话的任何停运之后，重演驱动器重建非事务和事务数据库会话状态。重演驱动器建立新的会话，以使得不存在剩余状态，发出允许应用重建用于那个会话的初始状态的可选的回调函数（如果回调函数被注册），并且然后重新执行在运行时间期间积累的保存的调用历史。调用的重演来自于驱动器队列并且可以被按序或以缓慢的方式重复，这取决于应用如何改变数据库状态。重演在连续性指导器组件的指导之下。每个重演的调用可以被检查以保证它刚好返回与应用在它的在原始执行处作出决定时看见并使用的相同的客户端可见的状态。每个重演的调用也可以被检查以确定调用是否经过在数据库处的重演前并且重演后检查以便重演被接受并最终完成。

在一个实施例中，通过为重演驱动器传递在每个数据库操作的原始执行期间在不透明的上下文区域中的原始的可变值（称为重演上下文），重演保护SQL和PL/SQL语句（包括事务内的）一致性。重演上下文与对应于数据库操作的方法调用一起由重演驱动器保存，并且其与在重演期间每个匹配的数据库操作一起被返回到数据库服务器。重演上下文用于恢复在服务器侧做出那些函数调用时瞬态SQL函数结果的原始值。利用此机制，恢复原始值，保证原始值用在重演的查询中并且相同的值被作为查询的结果返回。这在对重演驱动器最低成本的情况下发生。

至多一次事务执行由LTXID保护。仅仅在错误是可恢复时事务被重新提交并且用于事务的结果被确认为不由使用中的最后一个LTXID提交。已被在重演处替换的会话上的LTXID现在是用于请求的实行中的LTXID。如果新的会话失败，则使用中的最新LTXID是为了“至多一次”检查的那一个。所有其他的已被先前的重演尝试阻止。

利用重演上下文中的信息，如果在输出中存在任何失配，则连续性指导器拒绝重演。这包括在包括外绑定、DML返回、错误码和错误消息的线上被返回的所有数据。此拒绝保证应用潜在地对其作出决定的所有数据被重建–即，行按与原始执行相同的顺序被返回，输出–在外绑定中（例如DML返回和PL/SQL进程和函数结果、错误码和错误消息）并且行集合与原始执行一样，并且SQL在绑定外限定，并且执行环境与原始执行一样。任何分歧导致重演被中止，并且如果在事务中，则事务被回滚。失败转移的会话和会话状态（远离事务）被保持原来一样，允许应用采取它自己的恢复动作。在一个实施例中，当重演上下文不是可用时，确认的职责被移动到客户端侧。

重演驱动器可以在请求的整个持续时期内记录历史，如果在静态中操作，或如果已知状态在事务中没有改变或在动态模式中操作时在事务之后不被信赖，则对于完成的查询和关闭的事务清除关闭的方法调用。如果那些SELECT语句没有改变状态、如果重演已被禁止、并且在请求的结束处，则通过在SELECT调用已经完成之后清除关闭的游标来限制重演持续时间。

以下提供的示例特征与重演驱动器结合以支持具有对运行时间性能的可接受的成本的正确重演。

示例连续性指导器

在一个实施例中，连续性指导器使得数据库服务器指导特征的运行时间和重演部分。目标是数据库服务器以与客户端侧重演驱动器合作关于做什么。这具有可能的优点，即做出决策对于所有重演驱动器处于一个位置，决策处于可以访问信息（诸如非事务状态改变、嵌入的和最高级的提交、反转、管理的调用等等）的位置、和可对于所有重演驱动器扩展的位置。在一个实施例中，用于处理可重演的模式、对于什么重演驱动器在它们的队列中放置、并且什么时候清除的逻辑存在于数据库服务器。在其它实施例中，逻辑可以被分在数据库系统的若干组件之间或可以存在于数据库系统的完全不同的组件上。例如，当输入流不能再绕并且因此重演被禁止时，并且当应用执行明确的禁止重演API时，重演驱动器让连续性指导器知道请求在哪里开始和结束。

连续性指导器解决方案封装关于什么是可重复的、而不是什么不是可重复的知识。在一个实施例中，指示什么是可演的的信息是可重演项目的白名单而不是不可重演的项目的黑名单。此知识被连续性指导器在运行时间处应用以指导客户端驱动器保持或清除调用，并且在重演处拒绝对分歧数据库、违反协议、或不再现符合的状态的重演（以及其他）。连续性指导器在运行时间处与重演上下文联合工作以保存安全性证书、数据库签名、状态性信息、游标环境、执行系统更换数（SCN）、和用于客户端可见结果的校验和。这些数据用于确定重演是否将被允许、以及如果重演被允许则重演是否有效。在重演处，利用在用于往返行程的重演上下文中保持的信息，游标环境和执行SCN被为每个调用重建或确认。

连续性指导器层被放置在RDBMS的调用处理管理层中。这允许到重演驱动器的调用进出数据库的全貌。

清除信息的示例

为了节省存储器消耗，重演驱动器可以清除对重演不再需要的记录的调用。应用可以经由标准的JDBC和OCI调用适当地并及时关闭使用后的结果设置和语句。

当语句关闭并不存在绑定的有效事务，并且那个语句没有对数据库非事务会话状态做出改变并请求结束时，当那个连接被返回到池时，JDBC和OCI重演驱动器将清除存储的调用历史和与调用（包括准备的语句和可调用的语句）有关的所有重演特定对象（诸如内绑定、重演上下文）。

重演驱动器也将提供历史清除API，其允许应用清除已被标记以在清除要点之前在重演驱动器之内释放的存储的调用历史。在应用没有关闭或没有及时关闭结果设置和语句或利用相同连接保持延长的时间段而没有将它们返回到池的情况下，这有助于进一步节省存储器消耗。此API仅仅清除已标记为释放的存储的操作历史。它不包括通过重新执行任何JDBC方法、SQL、或PL/SQL变更连接的状态。它不清除没有标记为释放的历史。

示例重演上下文

在一个实施例中，在每个最高级调用的原始执行期间，通过将称为重演上下文的不透明的上下文区域传递到重演驱动器，在重演处保护数据库会话的安全性和一致性。重演上下文与排队的与最高级数据库操作对应的SQL或PL/SQL调用一起由重演驱动器保存。在重演期间重演上下文与每个匹配的数据库操作一起被返回到数据库服务器。

重演上下文携带确认重演的安全性、兼容性、有效性正确性、并优化重演的知识。重演上下文可以包含用于原函数执行的可变值、暴露于应用的用于数据的校验和、用于安全性和协议确认的协议校验和、用于事务结果集合的关键字、和优化器的执行计划。大部分时间，重演上下文仅仅包含数据库签名、SCN、校验和和以及协议校验和。重演上下文可以作为一个整体或作为从请求开始的最后一个的δ被提供到重演驱动器。

在一个实施例中，重演上下文的实例可以包含下列知识的一些组合以支持运行中的工作的重演/迁移。

·用于确定在原始调用执行的时候的数据库的相对时间点的数据库签名（DBID、DBINC、时间戳、加强的数据库SCN）。

·用于针对篡改重演和针对违反协议（缺陷或故意的）加以保护的拥有权、事务签名（LTXID）、和调用顺序。

·当在原始数据库处浏览时优化重演的SCN。

·在第一执行上被发送给客户端的可见结果的校验和。基于数据库的校验和从客户端驱动器中卸下校验和计算并且在重演失配时提供即时数据库侧拒绝。当这些可用时，校验和可以利用基于硬件的计算。检验和算法是在硬件和软件之间兼容的，并且跨端口和版本以支持数据库会话的故障转移和迁移。

·用于选择的ORACLE函数调用的输出以支持可见结果一致性（称为可变的支持）。

·有关版本的多元组，以提供LOB/BLOB/CLOB的检测和用于很少改变的媒体类型的安全文件改变，避免扫描和对大的对象数据的千兆字节创建校验和的处理。

·DBID-Rowid-Row版本多元组，以在事务重演中提供不透明的优化锁定。

·优化器执行计划，以在ORDER BY不是原始SQL语句的部分时防护用于SELECT重演的输出顺序。

在一个实施例中，重演上下文使用通用的格式以处理尾数、版本、和原始与故障转移目标之间的端口改变。

连续性指导器使用重演上下文以支持重演的安全性和正确性。当重演被启动时，重演上下文被作为不透明的对象与每个调用一起返回到客户端。在应用任何可变值和SCN之后，并且在将对于客户端可见结果的获得的校验和对比对于原始调用的校验和（包含在重演上下文中）之后，如果存在失配输出，则重演被拒绝。确认包括-行被按与对于应用已经看见的行集合的部分的第一提交相同的顺序返回；外绑定中的输出（例如DML返回和PL/SQL进程和函数结果和错误代码和消息）是相同的；并且行集合大小和任何错误代码与原始提交的一样。分歧导致重演被中止，并且如果在事务中，事务被回滚。

示例事务等幂性组件

连续性指导器使用事务等幂性以便防止重复的事务。在正常运行时间期间，LTXID被自动地保持在客户端和服务器二者处的会话中。在提交时，LTXID被作为提交事务的部分持续，并且更新的LTXID被返回到客户端。

在对于失败转移的每个会话的重演时，连续性指导器接收用于该会话的使用中的最后一个LTXID，并且如果该调用具有提交信息的能力，则调用FORCE_OUTCOME api以确定会话上的最后一个调用的输出。FORCE_OUTCOME调用可以包括阻止LTXID提交以使得输出已知并且不能由运行中的事务（即，仍然在另一个服务器上执行的事务）复制。阻止LTXID提交支持重演保真度，利用该LTXID的事务应当处于运行中。在试图基于驱动器或基于网络逻辑服务器的重演之前，内部调用FORCE_OUTCOME的GET_LTXID_OUTCOME被调用，以防止单个事务的多个执行。

作为优化，如果来自于消逝的会话的最后一个调用不能执行提交，则FORCE_OUTCOME或GET_LTXID_OUTCOME不被调用。例如，最后一个调用是没有设置自动提交模式的SELECT、或INSERT、UDATE或DELECT，或消逝的会话正在针对只读服务或数据库操作。

事务等幂性组件传送向应用自动地并透明地提供等幂性的集成功能。在一个实施例中，事务等幂性组件包括下列特征的一些组合。

·通过为所有事务类型针对数据库在COMMIT处保存LTXID的COMMIT输出的持久性。这包括用于利用自动提交执行的、来自于PL/SQL内部的、来自于服务器侧Java内部的、来自于远程和分布式事务以及来自于否则不能被利用一般手段识别的调出的事务的等幂性。

·利用LTXID以支持至多一次执行语义，以使得由LTXID保护的数据库事务不能复制，不管是否存在执行中的那个事务的多个副本。

·阻止运行中的工作的COMMIT以保证不管停运情况如何，例如由浏览器或中层对相同事务的另一个提交不能提交。

·识别在LTXID处提交的工作是否被作为最高级调用（客户端到服务器）的一部分被提交，或具有其它复杂度，诸如（a）被嵌入在服务器处诸如PL/SQL或Java之类的进程中，或（b）在可以已经具有已被丢失的其它结果或效果的调用中。嵌入的提交状态指示在提交完成的同时，但是其中提交执行的整个进程可以不已经运行到完成。提交以外的任何工作不能被保证已经完成直到那个进程本身返回到数据库引擎，并且客户端不能发现，除非那些结果到达客户端或已知并利用事务输出而持续。

·识别到COMMIT解析被定向到的数据库是先于原始提交、与其同步、还是在原始提交后，并且当在来自于客户端的事务的提交序列中存在间隙时拒绝。如果服务器或客户端在由LTXID序列确定的事务顺序中不同步，则它被认为是试图强迫等幂性的错误。

·当LTXID由从客户端到服务器的调用递增时触发的在客户端驱动器上的回调。这用于访问用于诸如网络逻辑和第三方之类的高层应用的LTXID以便维持当前LTXID准备用于阻止重复的提交。

·跨被加强到可插基础设施的全世界分散的数据库并跨数据库的域名空间唯一性。这包括RAC、数据保护、金门、和可插数据库。

用于掩盖数据库停运的示例方法

图1示出用于在重演驱动器级别处记录工作、指导驱动器、管理器重演上下文、和完成事务等幂性的示例服务器-客户端工作流程。流程示出查询和事务处理。重演可用，除非它已在开始请求和结束请求之间被明确地或隐性地禁止。

图2示出用于由连续性指导器、重演驱动器和用于完成事务的至多一次执行的等幂性协议驱动的数据库系统的故障转移的示例服务器-客户端工作流程。

为了从数据库服务器停运中恢复应用会话，用于会话的对话被从请求的开始至少部分地基于在停运时会话的对话的状态重演。例如，应用会话可以在事务外、在事务中被读取、利用提交或回滚完成事务。服务器-客户端系统能够将诸如NLS属性、事务状态、PL/SQL包全局变量、等等之类的非事务状态重建到它们在停运时的状态。如果事务处于运行中并且没有提交，则服务器-客户端系统也能够在恰当的环境中重新执行事务。如果可变函数值已被允许，则服务器能够恢复可变函数值。

为了最小化对应用的影响，重演驱动器试图将数据库会话放回到它将已经让原始执行延迟的地方。重演的方法是如果事务在停运时已被提交，则首先确定运行中的事务在数据库会话中的状态。然后，一旦运行中的对话的状态已知，就从一致状态中重新开始应用，其中诸如浏览器、应用、中层、数据库驱动器、和数据库会话之类的组件被对齐一致。

重演包括如果提交是可能的，则确定会话的最后一个提交的状态。对话的最后的一部分可以是诸如DML、COMMIT、或PL/SQL块之类的开始和潜在地执行的一个或多个提交的简单的最高级的调用。LTXID是这些步骤的关键。最后一个使用的LTXID被在Prepare_Replay调用中传递到服务器。在运行时间处服务器已经保持对于该LTXID执行的事务的纪录。重演的第一步是获得新的会话（新的以使得状态是干净的）并且使用LTXID和最后一个SQL或PL/SQL调用以确定停运处的对话状态。如果最后一个SQL或PL/SQL调用不是已被提交，则这些步骤返回未提交的状态。

一旦状态已知，如果回调已被注册，则下一步骤是允许应用恢复基本的终端用户状态，诸如跨来自于相同的终端用户的请求几乎恒定的NLS设置、安全性属性等等之类。当利用静态时使用此步骤，其中在开始阶段建立状态。当利用动态时它是可选的，但是利用诸如UCP标签之类的调出以设置状态确实提供更好的性能，因为不必在每个请求开始时重建状态。当回调被注册时，它可以在运行时间并且在重演执行、或在仅仅在重演处执行，这取决于它的实施方式。

后来的步骤重新执行创建了会话状态和事务状态的调用（如果存在事务）。这些步骤重演当前请求的调用，或为恢复最近的会话状态和事务状态所必需的调用的那些子集，例如当前事务的调用，而不是先前事务或请求的那些。每个调用的重演由被用于确认数据库体现、协议（aka重演处于正确顺序）、输出、用于恢复用于否则将导致在重演处失配的ORACLE函数的值、用于优化重演、并且用于确认环境的重演上下文支持。

当PL/SQL存在时用于重演的示例规则

在不支持等幂性的一个实施例中，当重演驱动器看见事务开始或最后一个调用是最高级处的PL/SQL时，历史的记录停止并且记录历史被清除。这是因为PL/SQL可以提交事务。

在当前模式中具有支持PL/SQL重演的一个实施例中，一旦PL/SQL已被看见并且并且不再使用SCN，因为在时间上倒退不是有效的，重演就切换到当前模式。

应用可以执行并且提交用于连接初始化的事务。只要事务在回调中被提交，这就对重演有效。

对于非事务状态，为执行但在执行后没有导致事务位（aka.非事务）被设置的调用保存历史。在看见PL/SQL之前，在重演SELECT语句的同时，重演驱动器使用一致的模式–重演“就像”原始SCN。这是最小化由于当前模式导致的拒绝率的优化。优化支持写到独立数据库的新的模块。

如果重演驱动器到达最高级的PL/SQL，则重演停止利用原始的SCN和所有后续调用、当前模式中运行的SELECT和PL/SQL。行为得好像提交被延迟一样。SELECT调用可以不被在运行时间处清除，即使在当前模式重演中关闭一次。重演重新执行并且然后再次关闭先前关闭的游标。在http请求的结束处并且在事务关闭处的清除未改变。在此只读解决方案中，在重演处，COMMIT可以对于排除做出的最后一个调用的所有调用禁止。

在由事务保护自动支持的等幂性的情况下，对于事务状态，记录可以继续到非事务阶段以外，经由事务直到COMMIT成功。一旦在事务中，SELECT、DML、和PL/SQL总是在当前模式中执行。如果事务没有提交，则不管Pl/SQL是否存在，重演驱动器可以在当前模式中将事务进行到底。DML和PL/SQL在当前模式处执行。在成功的COMMIT之后，如果利用动态，并且状态例如由PL/SQL在提交的事务中改变，则重演对于那个请求被禁止并且保持禁止直到下一个请求开始。在成功的COMMIT之后，当利用动态时，重演被禁止并且排除开启游标外的事务外部的所有历史被清除。相反地，如果利用静态，则应用已经陈述或它已被检测到在安装或改变状态之后它并没有改变状态并且此状态在提交之后不被信赖。在这种情况下,仅仅那个事务被清除，并且重演保持启动直到请求结束。

在重演期间，COMMIT可以对于排除做出的最后一个调用的所有调用禁止。这在重演期间避免提交边界改变。在最后一个调用之前,COMMIT被重新启动。最后一个调用没有返回到客户端，因此客户端没有基于它作出决定。它并未已经提交，因为它们已被LTXID处理确认。

在一个实施例中,历史记录在下一个开始请求标志器处重新开始。eBusiness Suite（当标记为能够丢失连接时）和Fusion ApplicationsUI操作在请求之间是无状态的但是继续保持物理连接的应用的示例。对于连接池,ORACLE池在分别登出和登记时隐性地标记请求的开始和结束。这告诉重演驱动器什么时候启动重演并开始记录，和什么时候禁止重演和停止记录。新发布的API的开始请求和结束请求允许其它第三方连接池在登记和登出时标记请求。独立的应用可以利用这些API标记请求在哪里开始和结束。

当重演出现时,整个请求被重演直到停运出现的地方；并且然后继续其余的请求。执行对用户、应用和客户端看来像是请求被稍微延迟。在数据库稍微慢地运行请求以致对客户端的响应被延迟时，效果可以与加载的系统相似。在具有在一致模式中支持PL/SQL重演的一个实施例中，对于没有导致事务位被设置的执行的调用，非事务状态被维持。当重演SELECT语句时，重演驱动器使用一致的模式–重演“好像”原始SCN。如果重演驱动器到达非事务的最高级的PL/SQL（即，没有在原始的执行处打开事务），则重演将会话SCN设置到原始SCN，并且在那个SCN处重演那个PL/SQL和它的子女。

对于事务状态，记录和重演可以经由事务阶段继续直到COMMIT。在事务中的所有调用，SELECT、DML、和PL/SQL被在当前SCN处重演。如果事务没有提交，则不管Pl/SQL是否存在，重演驱动器可以在当前模式中将事务进行到底。DML和PL/SQL在当前SCN处执行。在成功的COMMIT之后，如果重演确定利用动态，则当COMMIT成功时重演可以被禁止。一旦禁止，重演保持禁止直到请求结束。这不是有意义的问题，因为大部分的请求包含零或一个提交，并且COMMIT在存在时通常立即继之以结束请求并且登记到连接池。当存在状态改变时，一些解决方案可以检测在事务提交之后此状态改变不被信赖。如果状态改变被在提交的事务中检测并且被信赖，则第三组命令可以被维持以重建那个状态。如果确定利用静态，则解决方案重演过去的COMMIT。

硬件总览

根据一个实施例，由一个或多个专用的计算设备执行这里描述的技术。专用的计算设备可以是执行技术的硬线，或可以包括被编程以执行技术的诸如一个或多个专用集成电路（ASIC）或现场可编程门阵列（FPGA）之类的数字电子设备，或可以包括被编程以按照固件、存储器、其它存储器、或组合中的程序指令执行技术的一个或多个通用的硬件处理器。此类专用的计算设备也可以组合具有自定义程序设计以实现技术的自定义的硬线逻辑、ASIC、或FPGA。专用的计算设备可以是桌上型计算机系统、便携式计算机系统、手持设备、网络设备或合并硬线和/或程序逻辑以执行技术的任何其它设备。

例如，图6是示出了本发明的实施例可以被执行的计算机系统600的方框图。计算机系统600包括总线602或用于通信信息的其它通信机制，和用于处理信息的被耦接到总线602的硬件处理器604。硬件处理器604可以是例如通用微处理器。

计算机系统600也包括诸如随机存取存储器（RAM）或其它动态存储器之类的耦接到总线602用于存储要由处理器604执行的信息和指令的主存储器606。主存储器606也可以用于在执行由处理器604执行的指令期间存储临时变量或其它中间信息。此类指令当存储在处理器604可访问的非瞬时存储介质时，将计算机系统600渲染成为被定制以执行指令中指定的操作的专用机器。

计算机系统600还包括耦接到总线602的用于存储用于处理器604的静态信息和指令的只读存储器（ROM）608或其它静态存储器设备。诸如磁盘、光盘、或固态驱动器之类的存储设备610被提供并且耦接到总线602以用于存储消息和指令。

计算机系统600可以经由总线602被连接到诸如阴极射线管（CRT）之类的用于向计算机用户显示信息的显示器612。包括字母数字和其它键的输入设备614被耦接到总线602以向处理器604通信信息和命令选择。用户输入设备的另一个类型是用于向处理器604通信方向信息和命令选择并用于控制光标在显示器上移动的光标控制616，诸如鼠标、跟踪球、或光标方向键。此输入设备通常具有分成两轴的两个自由度，第一轴（例如，x）和第二轴（例如，y），其允许设备指定平面中的位置。

计算机系统600可以利用与计算机系统结合使得或编程计算机系统600为专用机器的定制的硬线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑执行这里描述的技术。根据一个实施例，由计算机系统600响应于执行包含在主存储器606中的一个或多个指令的一个或多个序列的处理器604执行这里的技术。此类指令可以从诸如存储设备610之类的另一个存储介质被读入到主存储器606。包含在主存储器606中的指令序列的执行使得处理器604执行这里描述的处理步骤。在可替换实施例中，硬线电路可以被软件指令代替使用或与软件指令结合。

这里使用的术语“存储介质”是指存储使得机器以特定方式操作的数据和/或指令的任何非瞬时的介质。此类存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如，光盘、磁盘、或诸如存储设备510之类的固态驱动器。易失性介质包括动态存储器，诸如主存储器506。存储介质的常见形式包括例如，软盘、软磁盘、硬盘、固态驱动、磁带、或任何其它磁数据存储介质、CD-ROM、任何其它光数据存储器介质、具有孔穴类型的任何物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其它存储器芯片或盒。

存储介质与传输介质不同但是可以被结合传输介质使用。传输介质参与在存储介质之间转移信息。例如，传输介质包括同轴电缆、铜线和光纤，包括包含总线602的线路。传输介质也可以采取声波或光波的形式，诸如那些在放射波和红外线数据通信期间生成的。

介质的各种形式可以被包含在向用于执行的处理器604传送一个或多个指令的一个或多个序列中。例如，指令可以最初被携带在磁盘或远程计算机的固态驱动上。远程计算机可以加载指令到它的动态存储器中并将指令通过电话线利用调制解调器发送。计算机系统600本地的调制解调器可以在电话线上接收数据并且使用红外线发送器将数据转换到红外线信号。红外检测器可以接收在红外线信号中携带的数据并且适当的电路可以在总线602上放置数据。总线602将数据携带到主存储器606，处理器604从中检索并执行指令。由主存储器606接收到的指令可以在由处理器604执行之前和之后可选地被存储在存储设备610。

计算机系统600也包括耦接到总线602的通信接口618。通信接口618提供耦接到被连接到局域网络622的网络链路620的双向数据通信。例如，通信接口618可以是综合服务数字网（ISDN）卡、电缆调制解调器、卫星调制解调器、或提供数据通信连接到对应类型的电话线的调制解调器。如另一个示例，通信接口618可以是提供数据通信连接到兼容的LAN的局域网（LAN）卡。也可以实现无线链路。在任何此类实施方式中，通信接口618发送并接收传送表示各种类型的信息的数字数据流的电、电磁或光信号。

网络链路620通常经由一个或多个网络向其它数据设备提供数据通信。例如，网络链路620可以经由本地网络622向主机624或由互联网服务供应商（ISP）626操作的数据装置提供连接。ISP626随后经由现在普通被称为“互联网”628的全球范围的数据包数据通信网络提供数据通信业务。局域网络622和互联网628两者都使用传送数字数据流的电、电磁或光信号。往返于计算机系统600传送数字数据的经由各网络的信号和网络链路620上并经由通信接口618的信号是传输介质的示例形式。

计算机系统600可以经由网络、网络链路620和通信接口618发送消息并接收包括程序代码的数据。在互联网示例中，服务器630可以经由互联网628、ISP626、局域网络622和通信接口618发送请求的用于应用程序的代码。

接收到的代码可以被处理器604按照接收的执行，和/或存储在存储设备610或其它非易失性存储器中用于以后执行。

示例实施例

示例实施例X1-X34包括：

X1.一种方法，包括：

在第一服务器实例与客户端之间的第一会话中，由第一服务器实例向客户端发送信息，所述信息是为了在到第一服务器实例的请求中发送的、用于在第一会话中执行的一组命令中的一个或多个命令在第二服务器实例与客户端之间的第二会话中的可能重演而维持的；

其中所述一个或多个命令如果在第二会话中根据在客户端处维持的信息被重演，则将重建在第一会话中在第一服务器实例与客户端之间建立的状态，而不重新做出在第一会话中已经做出的对数据库的任何改变；

其中在到第一服务器实例的请求中发送的、用于在第一会话中执行的该组命令中的至少一个命令如果被执行，则将已经使得第一服务器实例在第一会话中完成对数据库做出改变的事务；

其中该方法由操作第一服务器实例的一个或多个计算设备执行。

X2.如实施例X1所述的方法，其中所述信息包括描述一个或多个事务的第一组信息和不与所述一个或多个事务相关联的第二组信息，该方法还包括：

第一服务器实例检测所述一个或多个事务被提交并且检测在所述一个或多个提交的事务期间改变的任何状态不由该请求中后来的的命令使用，除非所述状态由一个或多个提交的事务提交，并且作为响应，在第一会话中向客户端发送清除描述一个或多个提交的事务的第一组信息的指示。

X3.如实施例X1所述的方法，其中向客户端发送信息包括：在包括在第一会话中执行该组命令的一个或多个命令的一个或多个结果的消息上背负所述信息。

X4.如实施例X1所述的方法，其中向客户端发送信息包括：

发送用于存储描述第一队列中的一个或多个打开的事务的第一组信息的第一指示；和

发送用于存储不与第二队列中的一个或多个打开的或提交的事务相关联的第二组信息的第二指示。

X5.如实施例X4所述的方法，其中第一组信息识别做出还未被在数据库中使得永久的临时变化的至少一个语句。

X6.如实施例X4所述的方法，其中第二组信息识别在第一会话中的一个或多个打开的或提交的事务之前、之后、或期间执行的至少一个语句，其中所述至少一个语句没有对数据库做出临时改变。

X7.如实施例X1所述的方法，其中所述信息包括描述一个或多个事务的第一组信息和不与所述一个或多个事务相关联的第二组信息，该方法还包括：

第一服务器实例检测所述一个或多个事务被提交并且检测后来的命令能够使用在所述一个或多个提交的事务期间改变的但是不由所述一个或多个提交的事务持续的状态，并且作为响应，在第一会话中向客户端发送:

描述在不重复一个或多个提交的事务的情况下改变状态的一个或多个命令的第三组信息，以及

清除描述所述一个或多个提交的事务的第一组信息的指示。

X8.一个或多个存储指令的非瞬时计算机可读介质，所述指令在被执行时使得：

其中在到第一服务器实例的请求中发送的、用于在第一会话中执行的该组命令中的至少一个命令如果被执行，则将已经使得第一服务器实例在第一会话中完成对数据库做出改变的事务。

X9.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中所述信息包括描述一个或多个事务的第一组信息和不与所述一个或多个事务相关联的第二组信息，该方法还包括：

X10.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中向客户端发送信息包括：在包括在第一会话中执行该组命令的一个或多个命令的一个或多个结果的消息上背负所述信息。

X11.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中向客户端发送信息包括：

X12.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中第一组信息识别做出还未被在数据库中使得永久的临时变化的至少一个语句。

X13.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中第二组信息识别在第一会话中的一个或多个打开的或提交的事务之前、之后、或期间执行的至少一个语句，其中所述至少一个语句没有对数据库做出临时改变。

X14.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中所述信息包括描述一个或多个事务的第一组信息和不与所述一个或多个事务相关联的第二组信息，其中所述指令在被执行时进一步使得：

清除描述所述一个或多个提交的事务的第一组信息的指示。

X15.一种方法，包括：

在第二服务器实例与客户端之间的第二会话中，第二服务器实例从客户端接收信息，所述信息是为了在从客户端到第一服务器实例的请求中发送的、用于在第一会话中执行的一组命令中的一个或多个命令在第二会话中的可能重演而维持的；

第二服务器实例根据由客户端处维持的信息重演所述一个或多个命令，以重建在第一会话中在第一服务器实例与客户端之间建立的状态，而不重新做出在第一会话中已经做出的对数据库的任何改变；

其中该方法由操作第二服务器实例的一个或多个计算设备执行。

X16.如实施例X15所述的方法，其中所述信息包括描述第一会话中的一个或多个打开的事务的第一组信息和不与一个或多个打开的或者提交的事务相关联的第二组信息，其中描述在第一会话中提交的一个或多个其它事务的信息被从第一组信息清除并且不由该请求中后来的命令使用，除非该信息通过提交所述一个或多个其它事务而持续。

X17.如实施例X15所述的方法，其中所述信息包括描述一个或多个打开的事务的第一组信息和不与打开的或提交的事务相关联的第二组信息。

X18.如实施例X15所述的方法，其中该组命令引起在第一会话中在数据库中成为持久的一个或多个改变，并且其中所述信息识别使得在第一会话中在数据库中持久的一个或多个改变之前、期间、或之后执行的至少一个语句，其中所述至少一个语句没有对数据库做出改变。

X19.如实施例X15所述的方法，其中所述信息包括描述一个或多个打开的事务的第一组信息、不与打开的或提交的事务相关联的第二组信息、和描述改变在提交的一个或多个事务期间改变的状态的一个或多个命令的第三组信息。

X20.一个或多个存储指令的非瞬时计算机可读介质，所述指令在被执行时使得：

X21.如实施例X20所述的一个或多个非瞬时计算机可读介质，其中所述信息包括描述第一会话中的一个或多个打开的事务的第一组信息和不与一个或多个打开的或者提交的事务相关联的第二组信息，其中描述在第一会话中提交的一个或多个其它事务的信息被从第一组信息清除并且不由该请求中后来的命令使用，除非该信息通过提交所述一个或多个其它事务而持续。

X22.如实施例X20所述的一个或多个非瞬时计算机可读介质，其中所述信息包括描述一个或多个打开的事务的第一组信息和不与打开的或提交的事务相关联的第二组信息。

X23.如实施例X20所述的一个或多个非瞬时计算机可读介质，其中该组命令引起在第一会话中在数据库中成为持久的一个或多个改变，并且其中所述信息识别使得在第一会话中在数据库中持久的一个或多个改变之前、期间、或之后执行的至少一个语句，其中所述至少一个语句没有对数据库做出改变。

X24.如实施例X20所述的一个或多个非瞬时计算机可读介质，其中所述信息包括描述一个或多个打开的事务的第一组信息、不与打开的或提交的事务相关联的第二组信息、和描述改变在提交的一个或多个事务期间改变的状态的一个或多个命令的第三组信息。

X25.如实施例X1所述的方法，其中该组命令中的至少一个命令在被在第一会话中执行时使用可变函数，所述可变函数在不同执行处提供不同的值，该方法还包括：

指导客户端保存来自于可变函数的不同执行的不同的值以使得不同的值可以在至少一个命令的重演期间被替代。

X26.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中该组命令中的至少一个命令在被在第一会话中执行时使用可变函数，所述可变函数在不同执行处提供不同的值，该方法还包括：

X27.如实施例X15所述的方法，其中该组命令中的至少一个命令在被在第一会话中执行时使用可变函数，所述可变函数在不同执行处提供不同的值，该方法还包括：

在重演所述一个或多个命令的同时，第二服务器实例对匹配的可变函数代入不同的值。

X28.如实施例X20所述的一个或多个非瞬时计算机可读介质，其中该组命令中的至少一个命令在被在第一会话中执行时使用可变函数，所述可变函数在不同执行处提供不同的值，该方法还包括：

X29.如实施例X1所述的方法，其中所述信息还包括在第一会话中可用于客户端的一个或多个命令的结果。

X30.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中所述信息还包括在第一会话中可用于客户端的一个或多个命令的结果。

X31.如实施例X15所述的方法，其中所述信息还包括在第一会话中可用于客户端的一个或多个命令的第一结果，该方法还包括第二服务器实例确认在第二会话中一个或多个命令的第二结果匹配在第一会话中可用于客户端的第一结果。

X32.如实施例X20所述的一个或多个非瞬时计算机可读介质，其中所述信息还包括在第一会话中可用于客户端的一个或多个命令的第一结果，该方法还包括第二服务器实例确认在第二会话中一个或多个命令的第二结果匹配在第一会话中可用于客户端的第一结果。

X33.如实施例X1所述的方法，还包括客户端通过登出连接池或通过利用启动客户端与第一服务器实例之间的重演的应用编程接口来标记请求的开始，以及客户端通过将连接登记回连接池或通过利用禁止重演的应用编程接口来标记请求的结束。

X34.如实施例X8所述的一个或多个非瞬时计算机可读介质，其中所述指令在被执行时，还使得客户端通过登出连接池或通过利用启动客户端与第一服务器实例之间的重演的应用编程接口来标记请求的开始，以及客户端通过将连接登记回连接池或通过利用禁止重演的应用编程接口来标记请求的结束。

在上述说明书中，已经参考在实施方式之间可以不同的许多细节描述了本发明的实施例。因此，说明书和附图应当被认为是说明性的，而不是限制的意义上的。本发明范围的唯一并专用的指示、和由申请人指定的作为本发明范围的内容是由本申请发出、以此类权利要求发出的特定形式的权利要求书的文字和等效范围，包括任何随后修正。

Claims

1.一种方法，包括：

其中该方法由一个或多个计算设备执行。

2.如权利要求1所述的方法，其中所述信息包括描述一个或多个事务的第一组信息和不与所述一个或多个事务相关联的第二组信息，该方法还包括：

3.如权利要求1或2中任何一个所述的方法，其中向客户端发送信息包括：在包括在第一会话中执行该组命令的一个或多个命令的一个或多个结果的消息上背负所述信息。

4.如权利要求1或3中任何一个所述的方法，其中向客户端发送信息包括：

5.如权利要求4所述的方法，其中第二组信息识别在第一会话中的一个或多个打开的或提交的事务之前、之后、或期间执行的至少一个语句，其中所述至少一个语句没有对数据库做出临时改变。

6.如权利要求1或3中任何一个所述的方法，其中所述信息包括描述一个或多个事务的第一组信息和不与所述一个或多个事务相关联的第二组信息，该方法还包括：

清除描述所述一个或多个提交的事务的第一组信息的指示。

7.如权利要求1-6中任何一个所述的方法，其中该组命令中的至少一个命令当在第一会话中被执行时使用在不同执行处提供不同值的可变函数，该方法还包括：

指导客户端保存来自于可变函数的不同执行的不同值以使得不同值能够在至少一个命令的重演期间被替代。

8.如权利要求1-7中任何一个所述的方法，其中所述信息还包括在第一会话中对客户端可用的一个或多个命令的结果。

9.如权利要求1-8中任何一个所述的方法，还包括：客户端通过检查连接池或通过利用启动客户端与第一服务器实例之间的重演的应用编程接口来标记请求的开始，以及客户端通过检查回到连接池的连接或通过利用禁止重演的应用编程接口来标记请求的结束。

10.如权利要求1-9中任何一个所述的方法，还包括：

在第二会话中由第二服务器实例从客户端接收为了可能的重演而维持的信息；

第二服务器实例根据在客户端处维持的信息重演一个或多个命令以重建在第一会话中在第一服务器实例与客户端之间建立的状态，而不重新做出在第一会话中已经做出的对数据库的任何改变。

11.如权利要求10所述的方法，其中接收到的信息包括描述一个或多个打开的事务的第一组信息、不与打开的或提交的事务相关联的第二组信息、和描述改变在提交的一个或多个事务期间改变的状态的一个或多个命令的第三组信息。

12.如权利要求10或11中任何一个所述的方法，其中该组命令中的至少一个命令当在第一会话中被执行时使用在不同执行处提供不同的值的可变函数，该方法还包括：

13.如权利要求10-12中任何一个所述的方法，其中所述信息还包括在第一会话中可用于客户端的一个或多个命令的第一结果，该方法还包括：由第二服务器实例确认在第二会话中所述一个或多个命令的第二结果匹配在第一会话中可用于客户端的第一结果。

14.一种或多种存储指令的计算机可读介质，所述指令在被执行时，使得执行在权利要求1-13的任何一个中记载的方法。

15.一种第一服务器实例，包括：

用于在第一服务器实例与客户端之间的第一会话中，向客户端发送信息的装置，所述信息是为了在到第一服务器实例的请求中发送的、用于在第一会话中执行的一组命令中的一个或多个命令在第二服务器与客户端之间的第二会话中的可能重演而维持的；