CN103365946B - 数据库性能分析 - Google Patents

Abstract

本发明各实施方式总体上涉及数据库性能分析。具体地，提供了一种计算机实现的方法、计算机程序产品和系统。该方法用于计算动作的持续时间，其中动作包括至少一个数据库操作，其中动作是为了处理请求执行的多个动作之一，其中处理请求包括执行多个应用，每个应用具有对应的应用数据库，其中执行应用中的一个应用包括执行对应应用数据库上的动作并且存储针对该动作的持续时间信息。该方法包括确定动作的主订单标识符。同样，该方法进一步包括查询所存储的持续时间信息。查询包括指定一个或多个关系的属性的真子集，关系包括至少一个表，每个关系包括多个行。属性描述主订单标识符。属性进一步描述持续时间信息中包括动作的开始时间的子集。查询进一步包括指定必须由所述关系的至少一行满足的条件，其中至少一个条件包括多个关系的属性。查询进一步包括根据条件获取关系的至少一行中的所指定的属性。查询进一步包括基于动作的开始时间计算该动作的持续时间。

Description

数据库性能分析

技术领域

本申请涉及数据库性能分析，具体地涉及动作的性能分析，其中所述动作为需要与多个数据库和数据库应用交互的请求的一部分。

背景技术

关系可以是二维表。关系还可以是视图，例如物化视图。关系包括行和列。关系的列被称作属性。

视图可以被理解为由计算(例如，一个或多个所存储关系(例如，表)上的查询)限定的关系。物化视图可以例如经由查询周期性地从数据库构建，并且存储在数据库中。

数据库可以被理解为可能由数据库管理系统(DBMS)管理的数据集合。

模式或数据库模式可以指明数据库中数据的逻辑结构。模式可以指明一个或多个关系。模式还可以包括以下各项中的一个或多个：断言、触发、系统限定的数据类型或值的集合、以及用户限定的数据类型。

数据库可以包括一个或多个模式，以及面向对象的功能。

数据库操作可以包括关系型数据库操作或者面向对象数据库操作。数据库操作可以被理解为可能由用户使用数据操纵语言发布的、影响数据库内容或模式的命令；同样或备选地，数据库操作还可以从数据库提取数据。数据库操作可以由DBMS处理。数据库操作的示例包括针对数据库的查询、在关系中插入行、在关系中删除或更新行等。

动作可以包括一个或多个数据库操作。在某些情况下，动作不仅可以是数据库操作，还可以是执行重要应用处理(例如，同步)的复杂功能。

应用数据库可以与多个应用相关联。应用数据库还可以与单个应用相关联。

处理请求可以包括执行多个应用，其中每个应用执行不同的功能集并且不同于任意其他应用。每个应用可以具有对应的数据库，其不同于与任意其他应用相关联的任意数据库。计算处理请求的持续时间可以包括确定在请求处理期间执行每个应用的时间长度，以及确定由每个执行应用执行的每个动作的持续时间。

主订单标识符可以与用于处理订单的所有请求相关联。主订单标识符可以是应用数据库的键，例如，唯一键或主键。在具体示例中，主订单标识符可以被实现为西贝尔(Siebel)订单ID。主订单标识符可以用于跨多个数据库追踪订单。

请求由应用接收。处理请求可能需要执行一个或多个动作。请求的示例为创建订单、创建账户、提交订单、变更订单和取消订单。每种类型的请求(例如，创建订单可以被认为是一类请求)可能需要不同的动作集来完成。某些请求可能在多个订单之间是相同的，其他请求可能针对不同订单而不同。

处理订单可以包括履行(或处理)多个请求，其中履行用于处理订单的所有请求可以与相同主订单标识符相关联。

特定集合的真子集是严格包含在该特定集合中的子集。因此，真子集必须排除该特定集合中的至少一个成员。例如，自然数集合是有理数集合的真子集。

条件可以评估为真或假，并且可以包括比较运算符和逻辑运算符。条件可以包括诸如模式匹配运算符之类的其他运算符。

键可以被实现为唯一键或主键。还可能是其他实现。唯一键唯一地标识关系中的每行，并且包括单个列或列的集合。主键是唯一键的特殊情况，使得表可以具有至多一个主键并且该主键不可以为空。

时间可以通过标准格式提供，例如，作为时间戳。例如，时间可以表示为自Unix新纪元以来的秒数。

发明内容

本说明书中描述的主题可以被实现为一种方法或系统，或者使用一个或多个计算机程序产品。本说明书中描述的主题可以通过数据信号实现或者在机器可读介质上实现，其中该介质通过一个或多个信息载体体现，诸如CD-ROM、DVD-ROM、半导体存储器或硬盘。这种计算机程序产品可以适当数据处理装置执行本说明书中描述的一个或多个操作。

另外，本说明书中描述的主题还可以被实现为包括处理器和耦合至该处理器的存储器的系统。具体地，该系统可以包括客户端计算机，可能实现为通用计算机。该存储器可以包括一个或多个程序使得处理器执行本说明书中描述的一个或多个方法。本说明书中描述的其他主题可以使用各种机器实现。

在下文示例性附图和描述中阐述了一个或多个实现的细节。其他特征通过说明、附图和权利要求书变得容易理解。

附图说明

图1描绘了示出用于计算处理订单持续时间的示例性方法的流程图。

图2描绘了请求域以及订单管理域中的示例性请求。

图3示出了用于访问性能测试工具的控制面板。

图4示出了用于与性能测试工具一起使用的输入表单。

图5示出了用于与性能测试工具一起使用的输入表单的另一示例。

图6示出了用于与性能测试工具一起使用的控制面板的另一示例。

图7示出了用于与性能测试工具一起使用的输入表单的另一示例。

图8示出了用于与性能测试工具一起使用的输入表单的又一示例。

图9示出了用于与性能测试工具一起使用的控制面板的又一示例。

图10示出了用于与性能测试工具一起使用的控制面板的又一示例。

图11示出了包括输出行、时间和应用信息的控制面板的示例。

图12示出了业务流程执行语言输出表单的示例。

图13示出了描绘多次调用动作的持续时间的分组处理表单。

图14示出了计算针对业务流程执行语言应用的处理请求的持续时间的结果。

图15描绘了示出订单和服务管理应用动作并且对应于动作持续时间的表单。

图16示出了订单和服务管理应用执行持续时间。

图17描绘了对应于账单和收入管理应用的应用数据库的状态。

图18描绘了对应于客户关系管理应用的应用数据库的状态。

图19描绘了查询与客户关系管理应用相关联的应用数据库的结果。

图20描绘了针对客户关系管理应用的应用执行持续时间。

图21描绘了客户关系管理应用的其他动作和应用持续时间数据。

图22突出显示了可以检查以确定性能瓶颈的结果信息的多个方面。

图23标识了针对性能改进的特定动作。

图24示出了可以在客户端计算机上使用的示例性网络信息。

图25示出了可以供客户端计算机使用的数据源和登录信息。

图26示出了可以供客户端计算机使用的数据库环境信息。

图27示出了可以用于实现所公开主题的通用计算机。

具体实施方式

在下文中，将参考附图给出示例的详细描述。应当理解，可以对所述示例进行各种修改。具体地，一个示例的元素可以被包含在其他示例中并且在其他示例中使用以形成新的示例。此外，以下描述包括多个特定查询。这些查询是示例。还可以展望用于达到类似结果的备选方法和措施。

因此，在以下描述和附图中，逗号(，)被用作小数点分隔符(还被称作小数点)，即，用于分隔数字的个位和十分位。例如，“25,34”指的是二十五点三四。

图1描绘了可以实现以便计算订单的持续时间(即，处理订单的持续时间)的步骤。另外，图1示出了在执行特定步骤时可以访问的数据库。具体地，在处理过程中，请求可以包括执行综合应用、客户关系管理应用(CRM)(例如，Siebel CRM)、订单和服务管理(OSM)应用、以及账单和收入管理(BRM)应用。综合应用还可以被称为AIA应用或者业务流程执行语言(BPEL)应用。

综合应用可以具有对应的综合数据库101。同样，CRM应用可以具有对应的CRM数据库103。此外，BRM应用可以具有对应的BRM数据库105，以及OSM应用可以具有对应的OSM数据库107。

图1中描绘的步骤可以由性能测试工具(PTT)执行，该性能测试工具可以被实现为客户端计算机上的软件应用。性能测试工具可以使用微软办公软件(Microsoft Office)实现，可能包括甲骨文(Oracle)客户端和微软电子表格(Microsoft Excel)。根据特定示例，PTT可以通过宏语言(VBA)编程。虽然下文某些示例涉及PTT，但是还可能是用于实现所述主题的各种其他机制。

为了开始计算处理订单的持续时间，PTT可以计算动作的持续时间。为了计算动作的持续时间，PTT可以确定该动作的主订单标识符。主订单标识符可以被实现为CRM订单标识符，具体地，Siebel订单标识符。为了处理订单而执行的所有动作可以与相同的主订单标识符相关联。

在步骤S101，PTT连接映射表和/或应用数据库并且使用主订单标识符来获得次订单标识符。该主订单标识符可以被称为追踪键，这是由于其可以用于跨多个应用追踪特定订单。因此，该主订单标识符可以在与多个应用中的每个应用相关联的数据库中出现。

次订单标识符可以被称为订单标识键、标识键或产品标识符。例如，次订单标识符可以是针对AIA应用的订单标识键、针对OSM应用的订单标识键或者针对BRM应用的订单标识键。次订单标识符的特定示例为结合图15描述的序列标识符(ID)。序列ID与OSM数据库107中的主订单相关联。序列ID有用的一个原因为，与主订单标识符相比，序列ID由OSM应用识别。因此，由PTT返回的特定序列ID可以用于通过OSM应用获取关于动作(例如，任务)的进一步信息。在某些情况下，不太可能使用主订单标识符从OSM应用获取关于动作的信息。

多个次订单标识符可以与主订单标识符相关联。在本申请的上下文中，主订单标识符可以用于查询与动作或订单相关联的性能信息。次订单标识符可以用于与特地应用交互以便执行性能分析或更多地了解动作。

综合数据库101(可能实现为AIA数据库)可以包括映射表(还被称作交叉参考表)。四个应用(即，CRM、AIA、OSM和BRM)连同其对应的应用数据库可以各自执行动作以便处理订单。在特定示例中，CRM、AIA、OSM和BRM被实现为快速提供设计订单递送(RODOD)软件套件的一部分。每个应用包括对应的应用数据库。每个应用可以包括表现不同但用于相似目的的值。

例如，CRM数据库103(可能实现为Siebel数据库)中的客户标识符可以被表现为一位数字然后连字符再八位数字。与之相比，BRM数据库105中的客户标识符可以被表现为一位数字然后连字符再三个字母再两位数字。因此，每个应用数据库可以通过不同的数据类型(可能具有不同的存储要求)来表现值(例如，客户标识符)。综合数据库101的映射表可以交叉参考针对不同应用数据库的值，使得CRM数据库103的客户标识符可以用于找到BRM数据库105的对应客户标识符。可以针对其他值(例如，订单标识符)和其他应用呈现类似的交叉参考信息。当信息在一个应用中更新(例如，客户在CRM数据库103中更新)时可以使用映射表，并且该变更必须向其他RODOD应用(例如，BRM应用及对应的BRM应用数据库105)传播。在某些情况下，可以查询交叉参考主订单标识符到次订单标识符的多个映射表(例如，在OSM数据库107以及在综合数据库101中)。

主订单标识符可以被实现为CRM订单标识符。具体地，主订单标识符可以是与请求相关联的唯一值。主订单标识符可以是应用数据库(例如，CRM数据库103)的键。更具体地，主订单标识符可以是CRM数据库103的主键。

在本申请的上下文中，数据库的键或数据库的主键可以被理解为数据库中的表的键或者数据库中的表的主键。

在请求或者更具体地被执行用于处理订单的请求(例如，创建订单)从CRM应用向AIA应用或OSM应用提交之后，AIA应用生成与原始主订单标识符相关联的针对每个AIA动作(例如，进程或子进程)的实例标识符。OSM数据库107包括与主订单标识符相关联的针对每个编制功能的任务标识符。任务标识符还可以被称为任务ID。另外，实例标识符可以被称为实例ID。

根据一个示例，AIA数据库中至少一个表的主键是实例标识符，并且OSM数据库107中至少一个表的主键是任务标识符。实例标识符和任务标识符两者均被链接至原始主订单标识符(例如，CRM订单ID)。继续该示例，CRM订单标识符可以存储在CRM数据库103的“S_ORDER”表的“ORDER_NUM”列中。另外，CRM订单标识符可以存储在OSM数据库107的“OM_ORDER_INSTANCE”表的“NODE_VALUE_TEXT”列中。

在步骤S103，可以查询存储的持续时间信息(例如，先前存储在上文提到的应用数据库之一中的持续时间信息)以便获取动作开始和结束时间。针对应用存储的持续时间信息可以被存储在对应于该应用的应用数据库中和/或存储在综合数据库101中。例如，与CRM应用相关联的动作的持续时间信息可以被存储在CRM数据库103中和综合数据库101中。

每个应用数据库针对相同订单可以具有不同的存储的持续时间信息。例如，CRM数据库103中存储的持续时间信息可以反映在建立其他数据库中没有反映的主订单标识符之前执行的动作。类似地，综合数据库101中存储的持续时间信息可以反映其他数据库中没有反映的消息查询次数。

动作可以包括多个数据库操作，诸如一个或多个更新、插入或删除操作。每个应用可以涉及使用不同术语的动作。例如，在综合应用的上下文中，动作可以是包括一个或多个子进程的进程。在OSM应用的上下文中，动作可以是任务。通常，动作涉及应用数据库上执行的一个或多个数据库操作，并且在动作执行期间和/或之后针对该动作的持续时间信息被存储在该应用数据库中(即，存储的持续时间信息)。

动作开始和结束时间可以通过指定多个关系的属性的真子集经由查询获取，其中关系包括至少一个表并且每个关系包括多个行。在某些情况下(例如，针对OSM数据库107)，关系可以包括至少一个视图。由属性描述的关系中的一列包括主订单标识符或次订单标识符。还有可能是一个属性通过主订单标识符描述列，并且另一属性通过次订单标识符描述列。属性通过持续时间信息描述列。具体地，属性可以通过持续时间信息描述多个列，包括具有动作开始时间的列和具有动作结束时间的列。

查询可以获取一个动作以及对应的开始和结束时间以便计算该动作的持续时间。可以执行多个查询以便计算请求或订单的持续时间。备选地，查询可以获取多个动作。

查询中指定属性的真子集可以显著小于多个关系中属性的总数。具体地，属性的真子集可以小于多个关系属性的15％，或者小于多个关系属性的10％或小于多个关系属性的5％。

处理请求的示例如下：创建订单、变更订单、修改订单、创建后续订单或取消订单。每个请求可以要求不同项目的实例化。在某些情况下，项目可以是产品。例如，为了创建订单，移动服务订单可以被实例化为多媒体消息服务(MMS)、短消息服务(SMS)和语音项目。备选地，针对简单电话的订单可以要求较少低复杂项目的实例化。

查询中指定的多个关系可以显著地小于应用数据库中的关系。例如，CRM数据库103可以包括超过70个关系(包括50多个表和20多个视图)，而CRM数据库103的查询可能仅包括四个关系。

查询可以通过结构化查询语言(SQL)实现。如果查询通过SQL实现，则多个关系属性的真子集可以被指定为选择语句中的选择列表(还被称作选择表达式)。查询还可以指定必须被关系中的至少一行满足的条件。每行可以包括主订单标识符以及针对动作存储的持续时间信息。至少一个条件可以描述(或指定)多个关系的属性。在SQL选择语句的上下文中，条件可以作为WHERE子句的一部分。

步骤S105可以包括基于所获取动作的开始时间和结束时间来计算该动作的持续时间(即，所获取的指定包括该动作存储的持续时间信息的动作信息的行)。持续时间可以通过执行算术数据库功能来计算。算术数据库功能可以包括减法、加法、舍入和/或时间转换。例如，在OSM数据库107的上下文中，动作的开始时间可以从该动作的结束时间中减去并乘以恒量以便计算该动作的持续时间。下文指定的查询在图15的上下文中提供了特定示例。

在步骤S107，可以计算应用执行的持续时间。应用执行的持续时间的计算可以基于在该应用执行期间执行的多个动作的持续时间。每个动作的持续时间可以按照上文所述进行计算。在一个示例中，基于所获取动作开始时间和结束时间计算的动作持续时间中的至少两个可以用于计算应用执行的持续时间。

因此，应用执行的持续时间可以通过确定在应用执行期间执行的具有主订单标识符的动作，继而标识具有主订单标识符的最早动作(或第一动作)以及具有主订单标识符的最晚动作(或最后动作或最终动作)。该最早动作可以被限定为具有最早开始时间的动作，并且最晚动作可以被限定为具有最晚动作结束时间的动作。

因此，根据一个示例，计算应用执行的持续时间可以通过将该应用执行期间执行的第一动作的时间戳从该应用执行期间执行的最后动作的时间戳减去来进行。根据另一示例，应用执行的持续时间通过将应用执行期间执行的每个动作的持续时间合计(即，加在一起)来计算，其中每个动作具有相同的主订单标识符。

在步骤S109，处理订单的持续时间可以基于应用执行持续时间来计算。具体地，处理订单的持续时间可以通过将跨所有应用具有相同主订单标识符的所有动作持续时间(即，动作执行持续时间)合计来计算。另外，计算处理订单的持续时间可以进一步包括针对所有次订单标识符计算具有次订单标识符的动作持续时间。动作持续时间可以通过查询综合数据库101或查询每个应用数据库进行访问。

处理订单的持续时间可以基于计算的动作持续时间和/或计算的应用执行持续时间进行计算。具体地，处理订单的持续时间可以通过将与主订单标识符相关联的动作和与次订单标识符相关联的动作的持续时间相加来计算。另外或备选地，处理请求的持续时间可以通过将执行用于处理该请求的应用的持续时间相加来计算。

图1上下文中描述的性能分析方法能够评估跨CRM、BRM、AIA和OSM应用的RODOD动作(例如，进程和包括进程的任务)的持续时间。PTT还提供了用于探测由单个应用(例如，CRM应用(如Siebel)、OSM应用、AIA应用或BRM应用)执行的动作的延迟的能力。

具体地，PTT可操作用于提供性能分析以便测量端到端(E2E)订单持续时间。订单的处理包括通过实例化RODOD应用上的多个动作(例如，子进程)执行的复杂功能的执行。订单可以与客户或账户相关联；订单可以包括一个或多个产品。为了计算订单处理时序，动作执行时间可以使用PTT进行分析并且对应于多个因素。例如，对动作执行时间有贡献的因素可以包括应用处理时间、数据库处理时间、查询/线程延迟等。

优势在于，PTT使得易于检测在执行多个应用中涉及的处理请求中的性能瓶颈，其中每个应用具有对应的应用数据库(例如，RODOD)。具体地，作为差性能的动作(例如，具有长持续时间，或者大于3秒或大于5秒的持续时间的动作)可以被标识并传给用户以便开发优化动作、微调设计架构并满足产品环境的期望。此外，PTT促进了端到端订单处理持续时间的计算。

所公开的主题可以扩展至大量订单，并且提供每个请求以及针对整个订单的动作持续时间(例如，进程和子进程)。具体地，可以计算为了执行(或处理)订单而处理的请求的持续时间。所公开主题还提供了特定应用动作的平均持续时间，包括针对CRM应用的帐户创建、订单创建和订单履行。还可以计算平均订单持续时间(即，处理订单所需的平均时间量)。

鉴于按上文所述计算的这些值，性能瓶颈可以通过分析性能分析期间获取的时间和持续时间来有效检测。时间和持续时间可以鉴于期望进行评估。因此，可以进行针对是否执行性能改进的确定。具体地，应用或动作可以基于平均应用和/或动作持续时间被标识用于性能改进。另外，还可以咨询个别动作持续时间。

根据特定示例，动作持续时间(例如，进程、子进程和任务)以及总订单持续时间可以通过电子表格或者某些类似的格式提供，以便可以将值分类。

图2描绘了性能分析的域。每个域可以涉及一类请求。例如，订单管理域中的请求可以包括创建订单、变更订单、修改订单、创建后继订单和取消订单。大宗订单管理域可以从订单管理域聚合请求。客户管理域可以包括帐户创建请求、帐户删除请求和其他帐户相关请求。还可能是其他域。

图2的特定示例包括可应用于电信业的域，具体地电信业的业务流程和产品。然而，类似技术还可以用于其他产业。例如，工具扩展可以被添加至PTT以便配置特定产业业务流程以及可以集成RODOD的新的应用。所公开主题可以用于评估多个应用的性能，其中每个应用连接至对应的应用数据库。根据示例，多个应用组合行动以便处理订单。更具体地，应用被组合在RODOD中。

RODOD是Oracle应用与内置流程集成包(PIPS)集合的组合。PODOD用于提供端到端订单递送解决方案。通过RODOD，服务提供者可以有效地管理针对新产品上市的前台和后台操作，以及跨订单生命周期可见地捕获并有效地管理针对端到端的订单供应任务。RODOD应用可以被连接，如“Rapid Office Design and Order Delivery”的图1和图2所示，Oracle白皮书2010年5月，2012年2月6日从http://www.oracle.com/us/industries/ communications/rapid-offer-design-order-wp-077276.pdf获取。

RODOD包括Siebel CRM、OSM、通信产品中心、AIA和BRM。互补产品包括服务履行工具，诸如统一库存管理(UIM)和自动服务激活程序(ASAP)。

处理订单可以要求执行多个应用并且与多个应用数据库交互。每个应用数据库可以具有至少一个数据类型和一个键(例如，主键)，其不同于任意其他应用数据库的数据类型和键。具体地，每个应用数据库可以包括具有属性(例如，订单标识)的表，所述属性使用与其他应用数据库中具有相同名称的属性不同的数据类型呈现。例如，通过第一应用数据库中多个字符呈现的标识符可以使用第二应用数据库中两倍于第一应用数据库中字符的字符呈现。

每个应用数据库还可以具有不同于任意其他应用数据库模式的模式。具体地，没用应用使用与另一应用相同的应用数据库。换言之，每个应用数据库具有唯一的模式。每个模式可以限定数据类型(例如，标准数据类型和/或用户限定数据类型)、表、视图、属性、存储过程、断言和触发。

执行用于处理请求(例如，创建订单或变更订单)的多个应用可以包括通信中心(例如，通信产品中心)，其跨订单捕获、账单和订单管理功能同步产品上市、价格计划等。应用可以进一步包括CRM应用，该CRM应用提供销售目录定义、多信道订单捕获和客户支持。应用可以进一步包括提供故障标签支持的服务应用。另外，应用可以包括订单和服务管理(OSM)应用，其在订单捕获和编制期间执行订单包装、分解和临时存储队列(TSQ)，以及订单变更、副产品(fallout)和状态的中央管理器。另外，应用可以包括账单和收入管理(BRM)应用，其提供账户、上市、采购、评级和账单管理。同样，执行用于处理请求的多个应用可以包括综合应用，其提供其他应用之间按产品分类并且可扩展的整合。

RODOD可以通过登录每个应用用户接口并且搜索订单来使得用户能够监测跨应用(Siebel CRM、AIA、OSM和BRM)的订单。从Siebel CRM应用创建、配置和提交的每个订单可以通过AIA、OSM系统来处理，该OSM系统管理在执行用于RODOD中生命周期的订单履行中涉及的整个范围的子序列活动。因此，针对每个应用，动作集合(例如，进程和子进程)被执行用于处理请求。可以处理多个请求以便处理订单，即，通过生命周期的订单履行带来订单。

某些持续时间信息只可以从一个应用数据库获取。例如，在主订单标识符创建之前存储的持续时间信息只可以从CRM数据库103获取。该持续时间信息可以包括客户创建和/或订单创建的持续时间。订单完成的时间还可以从CRM数据库103获取，尽管该持续时间信息也可以从其他数据库获得。

图3描绘了为了处理请求执行的四个应用。根据图3的示例，四个应用位RODOD的应用，即，CRM、OSM、AIA和BRM。

另外，图3描绘了PTT的控制面板，该PTT可以用于计算处理请求的持续时间。控制面板可以通过电子表格显示。控制面板可以允许用户插入针对每个应用数据库(即，综合数据库101、CRM数据库103、BRM数据库105和OSM数据库107)的数据库源名称(DSM)、用户名称和密码。

重置表单按钮1005结合图10进行论述。

图4描绘了针对PTT的输入表单。

输入表单可以包括主订单标识符列表401。主订单标识符可以被实现为CRM订单标识符(还被称作Siebel订单标识符)。

图5还描绘了PTT的输入表单。重置订单按钮801和重置客户按钮803结合图8进行论述。

在此示例中，输入表单包括多个账户标识符(还被称作客户标识符)。账户标识符可以用于获取主订单标识符，还被称作订单标识符或订单号。

图6还描绘了PTT的控制面板。

通过选择转换表单601(标为Siebel c2o，其中c2o指的是客户标识符到订单标识符)，图5中的账户(或客户)标识符可以用于获取主订单标识符。获取经由CRM数据库103的查询自动执行。

图7还描绘了PTT的输入表单。标识符列表701已经通过图5中描绘的账户标识符获取。响应于访问转换表单601，执行所述获取。

图8描绘了PTT输入表单的另一示例。该输入表单包括重置订单按钮801和重置客户端按钮803。该重置订单按钮801可以用于从订单列805清除主订单标识符。重置客户端按钮803可以用于从账户标识符列807清除账户标识符。

图9描绘了PTT的控制面板。在已经确定(即，直接获取或导出)主订单标识符之后，可以查询应用数据库中存储的持续时间信息。该查询可以通过按压执行按钮行901中的执行按钮触发。状态指示903指示账户标识符列表已经用于成功地获取主订单标识符列表。

图10描绘了PTT的控制面板。通过点击综合分析执行按钮1001，可以开始综合数据库101中处理请求的性能分析。“完成”可以出现在控制面板的一个或多个列中。这可以指示已经执行了分析。控制面板可以被重置，并且“完成”通过点击重置表单按钮1005清除。

分析可以关注于多应用解决方案(例如，RODOD)中的每个应用。在RODOD的示例中，应用包括AIA(BPEL)、OSM、BRM和CRM(例如，Siebel)。针对每个应用，执行性能分析的一个或多个方面。针对综合应用(例如，AIA)，分析动作(被称为进程)、分析分组进程以及计算订单持续时间。

针对CRM应用，确定与性能分析有关的细节，账户标识符被转换成主订单标识符，并且确定订单和账户持续时间信息。针对OSM应用，确定OSM动作持续时间，并且确定针对OSM应用的总订单执行。针对BRM应用，确定与性能分析有关的细节信息。所有这些性能分析的方面将在下文更加详细地进行论述。针对具有主订单标识符的订单的端到端持续时间(即，针对所用应用)可以通过将具有主订单标识符的动作持续时间与具有从主订单标识符导出的次订单标识符的动作持续时间相加来确定。针对特定应用(例如，OSM)的订单持续时间可以通过将具有对应于该订单的主订单标识符或次订单标识符的动作持续时间相加来确定，该订单通过特定应用执行。

图11至图16的描述包括存储持续时间信息的示例性查询。应当理解，查询以示例以及期望的用于查询存储持续时间信息的其他方式给出。PTT可以包括至少22个不同的查询。具体地，至少3个查询针对综合数据库101，至少2个查询针对OSM数据库107，至少2个查询针对BRM数据库105以及至少14个查询针对CRM数据库103。同样，PTT可以包括至少一个日期/时间查询。

图11示出了来自查询集成数据库101的结果摘要。所述结果摘要可以使用以下查询获得：

在上述查询中，必须由关系的每行满足的条件(即，WHERE子句)包括“TITLE LIKE′Sales Order 1-1271033％′”。然而，这仅是出于例示的目的。当计算多个订单的持续时间时，输入表单上的每个主订单标识符可以用于代替恒量值“1—1271033"以便获得针对每个订单输入的持续时间信息。这可以例如通过指定变量而不是上文恒量值来完成。

下文所述多个查询(例如，结合图13)还包括针对主订单标识符的恒量值。应当理解，类似的考虑也应用于这些查询。具体地，恒量值可以由变量或其他占位符代替，使得可以计算针对各主订单标识符的动作持续时间或订单持续时间。

输出行字段1101示出了值5500。每行可以对应于动作。订单平均时间字段1103示出了值25,8217。该值指示刚超过25秒的平均订单持续时间。CRM平均持续时间字段1105示出了值15,75706。该值指示CRM应用执行用于处理每个订单的平均持续时间。OSM平均持续时间行1107具有第一字段中的值0,24374。该OSM平均持续时间行1107指示执行OSM应用以便处理订单的平均持续时间。VRM应用平均持续时间行1109具有值9,8209。该值指示执行BRM应用以处理每个订单的平均持续时间。因此，根据图11所述示例，在处理每个订单的过程中，执行CRM应用平均15,75706秒(刚超过15秒)。类似地，在处理每个订单期间，执行OSM应用平均O,24374秒。同样，在处理每个订单期间，执行BRM应用平均9,8209秒。

图12示出了综合应用动作表单。所述结果可以使用上文参考图11所述的查询获得。

根据所述特定示例，综合应用为BPEL(还被称作AIA)，并且动作被称为BPEL进程。突出显示部分1201示出了20个具有主订单标识符1—10334641的行。每行在进程名称列1203中均具有动作名称。

综合数据库1O1中至少一个表的主键可以在实例键列1205中找到。应用标识符可以在参考系统列1207中找到。动作状态可以在状态描述列1209中找到。动作开始时间可以在开始进程列1211中找到。动作结束时间可以在结束进程列1213中找到。动作持续时间可以在进程消耗时间列1215中找到。

图13示出了描绘分组动作的持续时间的表单。所述持续时间可以使用以下查询获得：

在某些情况下，多次调用的动作可以被分组在一起。因此，图12中所列某些个别动作可以本分组在一起，如图13所示。在图13的示例中，动作被称为进程并且综合应用被称为BPEL或AIA。突出显示部分1301示出了12个具有相同主订单标识符(即，1—10334641)的行。多次调用的动作名称可以在分组进程名称列1303中找到。进程列1305的数目示出了分组动作中每个动作被调用的次数。多次调用的动作可以被聚合并且仅调用一次的动作还可以被列出。

分组进程消耗时间列1307示出了针对不止一次调用的动作的分组持续时间，以及针对仅调用一次的动作的单独持续时间。每个分组持续时间可以通过将进程名称列1203中具有相同名称的所有动作的持续时间相加来计算。换言之，分组持续时间可以通过将动作的所有调用的持续时间相加来计算。

分析调用不止一次的动作的持续时间可以使得能够确定动作是否被调用太多次。另外，上述查询结果可以使得更易于确定单个动作(例如，进程)花费太长时间，例如，通过将订单持续时间上的所用调用放入透视图。

图14示出了通过多个方式计算的订单持续时间。所述持续时间可以使用以下查询获得

订单可以通过执行具有相同主订单标识符的所有动作来处理。例如，如图12所示，具有与主订单标识符1-10334641相关联的22个动作。销售订单列1401包含主订单标识符。

订单的持续时间(即，处理订单的持续时间)可以通过以下至少两种方式计算(例如，经由查询(诸如上文示例))：第一，消耗的持续时间可以通过从具有给定主订单标识符的最后动作的结束时间减去第一动作的开始时间来计算。第二，相加的持续时间可以通过将具有对应于该订单的主订单标识符的所有动作持续时间相加来计算。相加的持续时间可以提供处理该订单所花费时间的过高评估，消耗的持续时间可以提供过低评估。根据每个计算方法计算的持续时间可能产生不同，这是因为不是所有动作都具有相关联的存储持续时间信息。具体地，执行的某些动作不具有可以相加的存储持续时间信息。这种动作的持续时间通过计算消耗的持续时间进行说明。

e2e消耗时间列1403(e2e被称作端到端)包括消耗的订单持续时间。消耗的订单持续时间可以通过从具有相同主订单标识符的最后动作的最后时间戳减去具有主订单标识符(例如，1—10334641)的最早动作的最早时间戳来计算。例如，针对主订单标识符1—10334641的e2e消耗时间可以通过从突出显示部分1201中的结束进程列1213的最后条目(即，05/02/2011 15：18：15,797)减去开始进程列1211中第一字段(即，05/02/2011 15：17：16，983)来计算。结果是58，814，如e2e消耗时间列1403的第一条目中所示。

相加的持续时间可以通过将具有主订单标识符的所有动作持续时间相加来计算。例如，在图14中，e2e消耗时间进程总和列l405中示出了相加的持续时间。在特定示例中，针对具有主订单标识符1—10334641订单的相加持续时间可以通过将突出显示部分1201中进程消耗时间列1215中的所有值加在一起来计算。因此，总数为24,349，如e2e消耗时间进程总和列1405的第一条目中所示。

图15示出了OSM数据库107中存储持续时间信息查询的结果。具有主订单标识符“1-461383”的行可以使用以下查询获取：

主订单标识符可以在销售订单列1501中找到。如上文所述，上文查询中的"SEQUENCE_ID″(″OHIST.ORDER_SEQ_ID")是次订单标识符的示例。序列ID可以被直接输入OSM应用。

存储持续时间信息查询(诸如上文查询)中指定的条件可以包括关系可以结合的条件和/或一个或多个过滤器。过滤器可以指定主订单标识符(例如，通过变量的形式可以保持输入表单中每个主订单标识符的值)、数据类型或对象特性。

任务id列l503示出了OSM任务标识符列表。任务可以被理解为指的是OSM数据库l07的上下文中的动作。任务标识符(诸如任务标识符列1503中所示任务标识符之一)为OSM数据库107中至少一个表的主键。开始任务列1505示出了动作开始时间列表。结束任务列1507示出了动作结束时间列表。任务消耗时间列1509示出了动作持续时间列表。

突出显示部分1511示出了与主订单标识符1—10334641相关联的存储持续时间信息。突出显示部分1511中的存储持续时间信息经由一个或多个查询从OSM数据库107获取。

图16示出了通过查询OSM数据库107获得的订单持续时间。订单持续时间可以通过以下查询获得：

消耗的持续时间在e2e消耗时间列1601中示出。主订单标识符以及与相同主订单标识符相关联的所有动作的状态也进行了描绘。e2e消耗时间列1601中的消耗持续时间通过从具有主订单标识符的最后动作的最后时间戳减去具有主订单标识符的最早动作的最早时间戳来计算，如参考图14所述。

图17示出了BRM数据库105的查询结果。活动账单账户(标为具有值“33748’’的“BA'’)的数目可以使用以下查询获得：

具有活动产品的活动账单账户(标为具有值“24352”的″BA_WITH_ACTIVE_PRODUCTS″)的数目可以通过以下查询获得：

当订单提交到CRM应用时，可以有助于确定对应的订单简档是否已经在BRM数据库105中创建，使得可以确定与订单相关联的产品是否已经到达BRM数据库105。因此，针对图17描述的查询可以用于计算BRM数据库105中账单简档的数目以及具有活动产品的账单简档的数目。

所述结果指示了BRM数据库105中账单简档的数目以及与项目(例如，产品)相关联的账单简档的数目。账单简档可以被理解为标识BRM数据库105中客户的实体。该上文给定查询可以在订单提交之前以及在提交订单已经处理之后使用。所述查询可以在提交大量订单(例如，超过1000)的情况下尤其有用。通过从订单处理之后执行查询获得的值减去订单处理之前执行查询获得的值，可以确定提交自CRM应用已经到达BRM应用的订单的数目。这可以在帮助定位误差(例如，无法完全处理的订单或者需要执行的其他动作)方面具有优势。

在到达BRM数据库105之前，订单通过CRM应用和对应的CRM数据库103、AIA应用和对应的综合数据库101以及OSM应用和对应的OSM数据库107进行处理。因此，运行上述查询以获得与图17描述内容对应的所述结果可以提供应用和数据库运作程度的指示，即，了解多个计算机、应用和数据库的状态。

图18示出了CRM数据库103的查询结果。该结果可以使用以下查询获得。

具体地，客户的数目(″CUSTOMERS"下具有值“40001”)可以获得如下：

联系人的数目(″CONTACTS"下具有值“41049”)可以获得如下：

订单的数目(″ORDERS"下具有值“41424”)可以获得如下：

未决订单的数目(″Pending"下具有值“16500”)可以获得如下：

未结订单的数目(″Open"下具有值“1508’’)可以获得如下：

完成订单的数目(″Complete"下具有值“41049”)可以获得如下：

未决取消订单的数目(″Pending Cancel″下具有值“8”)可以获得如下：

取消订单的数目(″Cancelled"下具有值“28”)可以获得如下：

上文所示针对图l8的8个查询可以用于监测CRM数据库103。具体地，示出关于客户和联系人的信息，即，客户账户的数目和联系人的数目。另外，还具体地示出关于订单的信息，即，订单的数目和订单状态(例如，未决、未结、完成、未决取消和取消)，以及示出了订单的总数还示出了每个订单状态中订单的总数。

图19描绘了查询CRM数据库103的结果。图19中描绘的结果可以使用以下查询获得：

因此，参考上述查询，siebel.s_order.order_Bum(sALES_ORDER)是CRM数据库103的主键。另外，siebel.s_order.order_num(sALES_ORDER)列中的值是主订单标识符。同样，OM_HIST$ORDER_HEADER.Task_ID(OHIST.TASK_ID)是OSM数据库的主键。

上述查询用于订单中项目的层级结构，订单中的项目包括父线(parent line)项目和子线(child line)项目。上述“WHERE'’子句的示例性条件(即，可以在存储持续时间信息查询中使用的条件)将ORDER_COMPLETED_DATE("ord_line.COMPLETED")指定为在完成订单的根项目时的日期。

上述查询示出从由“--”注释掉的“SUM”开始的线。在上述示例性查询的上下文中，Microsoft Excel用于从上述选择列表的属性添加″ACCOUNT_CREATED_TIME″，″ORDER_CREATED_TIME″和″ORDER_COMPLETED_TIME″来计算消耗的持续时间。备选地，注释可以被移除并且消耗的持续时间可以经由查询表达式计算。

账户名称列示出了可以用于唯一地标识订单或者获得订单标识符的账户标识符。销售订单列1903示出了可以用于唯一地标识订单的主订单标识符。订单状态列1905示出了为了处理对应订单执行的动作的状态。图19中描绘的其他列示出了处理每个订单中的显著日期(即，指示事件发生时的时间戳)。

图20示出了订单持续时间信息。

订单持续时间信息可以使用参考图19描述的查询来计算。具体地，账户创建时间列2001示出了订单创建日期与账户创建日期之间的差。订单创建时间列2003示出了订单提交日期与订单创建日期的差(即，订单创建时间列2003示出了从订单提交日期减去订单创建日期)。订单完成时间列2005示出了订单完成日期与订单提交日期之间的差。订单创建日期、订单提交日期和账户创建日期指的是CRM数据库103中表的属性。e2e消耗时间列2007的字段是账户创建时间列2001、订单创建时间列2003和订单完成时间列2005的对应字段(即，相同行中的字段)中值的合计。

e2e消耗时间列2007中所示从CRM数据库103获取的消耗时间大于从综合数据库101或OSM数据库107获取的消耗时间，这是因为从CRM数据库103获取的消耗时间包括在建立主订单标识符(例如，初始账户和订单配置)之前记入的存储持续时间信息，而综合数据库101和OSM数据库107中的存储持续时间信息仅包括主订单标识符建立之后存储的订单持续时间信息。

图21还描绘了PTT的控制面板。

在订单状态列2101中，包括可以用于确定是否执行性能改进的信息。性能改进的示例为在持续时间方面减少，例如，订单持续时间、请求处理持续时间、动作持续时间或应用执行持续时间。订单状态列2101中的值包括平均账户创建时间、平均订单创建时间、平均订单完成时间和e2e(端到端)订单消耗时间。e2e订单消耗时间反映了账户创建持续时间、订单创建持续时间和订单完成持续时间的合计。在图21所示特定示例中，平均账户创建持续时间是61,844，平均订单创建持续时间是13,812，以及平均订单完成持续时间是30,448。将这些持续时间加在一起产生平均端到端持续时间106,104。

当上述平均持续时间与期望值不匹配时，可以分析与每个应用相关联的持续时间。

图22示出了PTT控制面板的又一描绘。

假设参考图21论述的平均持续时间与期望值不匹配，可能需要分析订单和应用持续时间。

在图22中，显示了两个e2e(端到端)持续时间，“38,732572”的综合(或BPEL)e2e持续时间(即，该上下文中耗费的持续时间)被示出并且突出显示。另外，示出了“27,652”的OSM e2e持续时间。针对综合应用(BPEL)的“订单平均时间”为“34,8217”，其小于综合e2e持续时间，这是由于综合e2e持续时间用于查询和消息处理。

另外，在处理订单时示出了综合应用(BPEL)与其他应用交互的持续时间。具体地，根据所述示例，在处理订单时综合应用与CRM应用交互的平均持续时间为“15,75706”，与OSM应用交互的平均持续时间为“9,24374”，以及与BRM应用交互的平均持续时间为“9,8209”。

图23描绘了经由综合数据库101的查询生成的结果表单。具有主订单标识符1-10381711并且由综合应用执行(当与BRM应用交互时)的标识动作2301示出了消耗的持续时间5,448。因此，通过标识针对总订单持续时间的显著部分(例如，大于3秒或大于5秒)的单个动作，可以关注有用并带来最佳结果的性能改进效果。具体地，在数百订单和数千动作中，可以标识能够改进的单个动作或少量动作以便在整体性能上具有显著影响。

PTT提供了与组合或异构应用(例如，RODOD)中处理的请求和订单有关的性能信息。各应用的响应时间甚至个别动作(例如，进程、子进程和任务)的细节可以被简单地聚集在一起。即使在成千上万个单独动作中，也可以简单地检测性能问题或瓶颈的原因。因此，使用PTT可以接近期望。

图24示出了TNSNAMES配置文件。

TNSNAMES配置文件可以供PTT使用来确定如何连接数据库源。PTT可以使用Microsoft Excel和宏语言(VBA)实现。Visual Basic代码中的SQL查询可以使用Oracle数据库连接(ODBC)和Oracle Client Home访问Oracle数据库。在特定示例中，图24描绘的TNSNAMES文件可以存储在以下目录：

C：\oracle\product\10.2.0\client_1\network\ADMIN\tnsnam es.ora

图25示出了OSM数据库107的连接信息如何能够录入Oracle客户端对话框的示例。

图26示出了描绘Oracle_Home环境变量的示例性值的对话框。

图27示出了用于实现所述主题的示例性系统，其包括形式为传统计算环境2720(例如，个人计算机)的通用计算装置。传统计算环境包括处理单元2722、系统存储器2724和系统总线2726。系统总线耦合包括系统存储器2724的各种系统组件至处理单元2722。处理单元2722可通过访问系统存储器2724来执行算术、逻辑和/或控制运算。系统存储器2724可存储信息和/或指令以供与处理单元2722联合使用。系统存储器2724可包括易失性和非易失性存储器，诸如随机访问存储器(RAM)2728和只读存储器(ROM)2730。基本输入/输出系统(BIOS)可以存储在ROM2730中，BIOS包含有助于在个人计算机2720内的元件之间传输信息的基本例程，诸如在启动期间。系统总线2726可以是多个类型的系统总线中的任意系统总线，其包括存储器总线或存储器控制器、外围总线以及使用任意多种总线架构的局部总线。

个人计算机2720还可以包括用于从硬盘(未示出)读取和向硬盘写入的硬盘驱动器2732，以及用于从可移动盘2736读取和向可移动盘2736写入的外部盘驱动器2734。可移动盘可以是用于磁盘驱动器的磁盘或者是用于光盘驱动器的诸如CD ROM之类的光盘。硬盘驱动器2732和外部盘驱动器2734分别由硬盘驱动器接口2738和外部盘驱动器接口2740连接至系统总线2726。驱动器及其相关联的计算机可读介质为个人计算机2720提供针对计算机可读指令、数据结构、程序模块和其他数据的非易失性存储。数据结构可以包括用于实现如上所述的用于计算动作持续时间的方法的相关数据。相关数据可以被组织在数据库中，例如关系型数据库或面向对象的数据库。

尽管在此描述的示例性环境使用硬盘(未示出)和外部盘2736，本领域技术人员应当知晓的是也可在示例性操作环境中使用可以存储计算机可访问的数据的其他类型的计算机可读介质，诸如磁带盒、闪存卡、数字视频盘、随机访问存储器、只读存储器等等。

一些程序模块可存储在硬盘、外部盘2736、ROM2730或RAM2728上，包括操作系统(未示出)、一个或多个应用程序2744、其他程序模块(未示出)以及程序数据2746。应用程序可包括如图1至图27中所示的功能的至少一部分。

如下所述，用户可通过诸如键盘2748和鼠标2750的输入设备向个人计算机2720中输入命令和信息。其他输入设备(未示出)可以包括麦克风(或其他传感器)、操纵杆、游戏台、扫描仪等等。这些或其他输入设备可以通过耦合至系统总线2726的串行端口接口2752连接至处理单元2722，或者可以由其他接口(诸如并行端口接口2754、游戏端口或通用串行总线(USB))所收集。此外，可以使用打印机2756打印信息。打印机2756和其他并行输入/输出设备可以通过并行端口接口2754连接至处理单元2722。监视器2758或其他类型的显示设备也通过诸如视频输入/输出2760的接口连接至系统总线2726。除了监视器之外，计算环境2720可以包括其他外围输出设备(未示出)，诸如扬声器或其他听觉输出。

计算环境2720可以与诸如计算机、电话(有线或无线)、个人数字助理、电视之类的其他电子设备通信。为了进行通信，计算机环境2720可以在使用到一个或多个电子设备的连接的网络环境中操作。图27描绘了与远程计算机2762联网的计算机环境。远程计算机2762可以是诸如服务器、路由器、网络PC、对等设备或其他常用网络节点的其他计算环境，并且可包括以上关于计算环境2720所描述的多个或所有元件。图27中所描绘的逻辑连接包括局域网(LAN)2764和广域网(WAN)2766。此类网络环境在办公室、企业范围计算机网络、企业内联网以及因特网中是常见的，并且特别地可以被加密。

当在LAN网络环境中使用时，计算环境2720可以通过网络I/O2768被连接至LAN2764。当在WAN网络环境中使用时，计算环境2720可以包括调制解调器2770或用于在WAN2766上建立通信的其他装置。调制解调器2770可以在计算环境2720的内部或外部，其通过串行端口接口2752连接至系统总线2726。在网络环境中，所述的与计算环境2720相关的程序模块或其部分可以存储在位于远程计算机2762上或可由远程计算机2762上访问的远程存储器存储设备中。此外，与(上述)性能测试工具相关的其他数据可以位于远程计算机2762上或可由远程计算机2762访问。可以知晓的是所示的网络连接是示例性的并且可以使用用于建立在电子装置之间的通信链接的其他装置。

上述计算系统仅为可以用于实现用于计算动作持续时间的方法的计算系统的类型的一个示例。

所述主题可以产生多个效果和优势。具体地，根据所述主题的查询可以用于快速准确地确定性能瓶颈，并且改进数据库和应用响应时间。因此，应用和数据库性能可以通过标识不必要动作(即，移除不使用或不需要的功能)，重新设计工作流(例如，执行不同动作集以便完成特定目标)，或者变更分解规则(此类规则可以影响动作(例如，OSM任务))来进行改进。同样，鉴于显著性能数据的标识，可以重新设计综合应用中的动作(例如，进程或子进程)。

因此，所述主题具有有效标识所有RODOD应用中持续时间数据的位置的技术效果。此外，所述主题具有确定待从综合数据库101、CRM数据库103、BRM数据库105和OSM数据库107提取的正确属性以便确定RODOD中的性能如何改进的技术效果。因此，可以标识正被分析的特定订单的每个应用中的特定动作(例如，子进程或任务)。此外，所述主题支持单个订单或大量订单(例如，上千个)的性能分析。

根据一方面，提供了用于计算动作持续时间的计算机实现方法。该动作包括至少一个数据库操作，并且该动作是为了处理请求执行的多个动作之一。处理请求可以包括执行多个应用，每个应用具有对应的应用数据库。执行应用中的一个应用包括执行对应应用数据库上的动作并且存储针对该动作的持续时间信息。

该方法可以包括确定动作的主订单标识符。另外，该方法可以包括通过该主订单标识符导出至少一个次订单标识符。多个次订单标识符可以与该主订单标识符相关联。此外，该方法可以包括查询存储的持续时间信息。查询可以包括指定一个或多个关系的属性的真子集，关系至少一个表，每个关系包括多个行。可以具有多个关系。属性可以描述主订单标识符。属性可以进一步描述次订单标识符。同样，属性可以描述持续时间信息中包括动作开始时间的子集。持续时间信息的子集可以进一步包括动作结束时间。持续时间信息的子集可以为真子集。

查询可以进一步包括指定必须由关系的至少一行满足的条件，其中至少一个条件包括多个关系的属性。查询可以进一步包括根据条件获取关系的至少一行中的指定属性。此外，查询可以包括基于获取的动作的开始时间和获取的动作的结束时间来计算动作的持续时间。

在某些情况下，确定主订单标识符包括接收主订单标识符。备选地，确定主订单标识符包括接收账户标识符并且通过账户标识符确定主订单标识符。

此外，可以应用以下至少一个：

-主订单标识符是至少一个应用数据库的键，

-次订单标识符是至少一个应用数据库的键，以及

-主订单标识符是仅一个应用数据库的键。

在此上下文中，键可以是唯一键或主键。

另外，查询可以包括基于在执行应用期间执行的多个动作的持续时间来计算应用执行的持续时间。该方法可以进一步包括基于动作持续时间和/或应用执行持续时间来计算处理请求的持续时间。

此外，针对每个动作的持续时间信息可以存储在对应的应用数据库和/或综合数据库中。

同样，导出次订单标识符可以包括使用主订单标识符查询映射表。

另外，方法可以进一步包括通过确定具有主订单标识符的所有动作来计算订单的持续时间。

在某些情况下，方法可以进一步通过确定具有主订单标识符的所有动作来计算订单的持续时间。同样，计算订单的持续时间可以进一步包括通过从具有主订单标识符的最后动作的最后时间戳减去具有主订单标识符的最早动作的最早时间戳来计算消耗的持续时间。此外，计算订单的持续时间可以包括通过将具有主订单标识符的动作的持续时间相加来计算合计持续时间。

此外，方法可以进一步包括通过将应用数据库中所有订单的持续时间相加来确定平均订单时间。每个订单的持续时间可以按上文所述确定。方法可以进一步包括通过将执行应用期间执行的动作的持续时间相加来确定处理订单期间执行的每个应用的平均持续时间。

在某些情况下，方法可以包括基于平均订单持续时间来确定是否执行性能改进，以及当执行性能改进时：

-基于执行每个应用的平均持续时间来标识用于性能改进的应用，以及

-基于执行每个应用的平均持续时间和/或动作的持续时间来标识用于性能改进的动作。

在某些情况下，性能改进包括减少由标识动作执行的数据库操作。

另外，属性可以进一步描述对应应用数据库的键。

此外，每个应用数据库可以具有不同于任意其他应用数据库模式的模式。

同样，每个应用数据库可以具有不同于任意其他应用数据库的数据类型和键的至少一个数据类型和/或至少一个键。

另外，方法可以进一步包括标识多次调用的每个动作，以及通过聚集标识动作的调用以及将调用的持续时间相加来计算每个标识动作的分组持续时间。另外，方法可以进一步包括显示每个所标识的动作然后是所述动作的所述分组持续时间。

根据另一方面，提供了包括计算机可读指令的计算机程序产品。当在计算机系统上记录并执行时，所述指令使得计算机系统根据上文所述方法之一执行操作。

根据又一方面，提供了计算机系统。计算机系统可以包括可操作用于计算动作持续时间的客户端计算机，其中动作包括至少一个数据库操作，其中动作是为了处理请求执行的多个动作之一。同样，计算机系统可以包括多个应用数据库，每个应用数据库可操作用于存储持续时间信息并且从客户端计算机获取至少一个查询。另外，处理请求可以包括执行多个应用，每个应用具有对应的应用数据库。执行应用中的一个应用可以包括执行对应应用数据库上的动作并且存储针对该动作的持续时间信息。

客户端计算机能够可操作用于通过确定动作的主订单标识符来计算该动作的持续时间。另外，客户端计算机能够可操作用于通过主订单标识符导出至少一个次订单标识符。客户端计算机能够进一步可操作用于查询存储的持续时间信息。

查询可以包括指定多个关系的属性的真子集，关系包括至少一个表，每个关系包括多个行。属性可以描述主订单标识符。属性可以进一步描述次订单标识符。属性还可以描述持续时间信息中包括动作开始时间的子集。该持续时间信息的子集可以进一步包括动作的结束时间。查询可以进一步包括指定必须由关系的至少一行满足的条件，其中至少一个条件指定多个关系。

另外，查询可以包括根据条件获取关系的至少一行中的指定属性。此外，查询可以包括基于动作的开始时间来计算该动作的持续时间。该动作的持续时间的计算还可以基于该动作的结束时间。

在某些情况下，客户端计算机能够进一步可操作用于基于执行应用期间执行的多个动作的持续时间来计算应用执行的持续时间。另外，客户端计算机能够可操作用于基于动作持续时间和/或应用执行持续时间来计算处理请求的持续时间。客户端计算机能够进一步可操作用于执行上文所述任意方法。

Claims (10)

1.一种用于计算处理订单的持续时间的计算机实现的方法，其中所述订单包括动作，所述动作包括至少一个数据库操作，

其中处理所述订单包括执行应用，所述应用中的每个应用具有多个应用数据库中的对应的应用数据库，

其中执行所述应用包括执行所述对应的应用数据库上的动作并且存储针对所述动作的持续时间信息，

其中每个应用数据库具有不同于所述应用数据库中的任意其他应用数据库的数据类型和键的至少一个数据类型和至少一个键，所述方法包括：

-确定所述动作的主订单标识符；

-通过使用所述主订单标识符查询映射表导出次订单标识符，其中应用以下的至少一项：

--所述主订单标识符是至少一个所述应用数据库的键；

--所述次订单标识符是至少一个所述应用数据库的键；以及

--所述主订单标识符是所述应用数据库中的仅一个应用数据库的键；

-查询所存储的持续时间信息，所述查询包括：

--指定关系的属性的子集，所述关系包括至少一个表，所述关系中的每个关系包括多个行，所述属性的子集描述：

---所述主订单标识符和所述次订单标识符，以及

---所述存储的持续时间信息中包括所述动作的开始时间的子集；

--指定必须由所述关系的至少一行满足的条件；以及

--根据所述条件，获取所述关系的所述至少一行的所指定的属性的子集；

--针对所述应用中与所述主订单标识符相关联的每个应用，确定所述动作中的哪些动作在每个应用的执行期间被执行；

--通过以下至少一种来计算针对与所述主订单标识符相关联的每个应用的应用执行的持续时间：

---标识所确定动作的最早动作和所确定动作的最晚动作，并且从所标识最晚动作的最晚时间戳中减去所标识最早动作的最早时间戳；以及

---将与所述主订单标识符相关联的每个应用的执行期间执行的所确定动作的持续时间相加；

--针对所述应用中与所述次订单标识符相关联的每个应用，确定所述动作中的哪些动作在所述应用的执行期间被执行；

--针对与所述次订单标识符相关联的每个应用的应用执行的持续时间；以及

--通过跨与所述主订单和次订单相关联的所有所述应用将与所述主订单标识符相关联的所述动作的所述持续时间和与所述次订单标识符相关联的所述动作的所述持续时间相加，计算所述订单的所述持续时间。

2.根据权利要求1所述的方法，其中确定所述主订单标识符包括：

接收所述主订单标识符；或者

接收账户标识符，以及

基于所述账户标识符确定所述主订单标识符。

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

通过将所述应用数据库中所有订单的所述持续时间相加，确定平均订单持续时间；以及

通过将执行所述应用期间执行的所述动作的所述持续时间相加，确定在处理所有所述订单期间执行应用的平均持续时间。

4.根据权利要求3所述的方法，包括：

基于所述平均订单持续时间，确定是否执行性能改进；以及

响应于确定执行所述性能改进：

基于执行每个应用的所述平均持续时间，标识用于所述性能改进的应用，以及

基于执行每个应用的所述平均持续时间和/或所述动作的所述持续时间，标识所述动作中用于所述性能改进的动作。

5.根据权利要求4所述的方法，其中所述性能改进包括减少由所标识的动作执行的数据库操作的数目。

6.根据权利要求1所述的方法，其中所述属性的子集进一步描述所述对应的应用数据库的键。

7.根据权利要求1所述的方法，其中每个应用数据库具有不同于任意其他应用数据库模式的模式。

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

标识多次调用的每个动作；

通过聚集所标识的动作的调用以及将所述调用的持续时间相加，计算每个所标识的动作的分组持续时间；以及

显示每个所标识的动作然后是所述动作的所述分组持续时间。

9.一种嵌入有计算机可读指令的计算机可读介质，当所述计算机可读指令在计算机系统上加载并执行时，使得所述计算机系统根据前述权利要求中的任意一项所述的方法执行操作。

10.一种计算机系统，包括：

硬件处理器；

应用数据库，所述应用数据库中的每个应用数据库可操作用于存储持续时间信息以及从所述硬件处理器获取至少一个查询，其中每个应用数据库具有不同于所述应用数据库中的任意其他应用数据库的数据类型和键的至少一个数据类型和至少一个键；以及

存储设备，所述存储设备包括在由所述硬件处理器执行时使得所述硬件处理器执行以下操作的指令：

计算处理包括动作的所请求订单的持续时间，其中所述动作包括执行应用，每个应用对应于所述至少一个应用数据库，其中为了计算所述动作的每个动作的持续时间，所述指令使得所述硬件处理器：

-确定所述动作的主订单标识符；

-通过使用所述主订单标识符查询映射表导出次订单标识符，其中应用以下的至少一项：

--所述主订单标识符是至少一个所述应用数据库的键；

--所述次订单标识符是至少一个所述应用数据库的键；以及

--所述主订单标识符是所述应用数据库中的仅一个应用数据库的键；

-查询所存储的持续时间信息，其中为了查询所存储的持续时间信息，所述硬件处理器：

--指定关系的属性的子集，所述关系包括至少一个表，所述关系中的每个关系包括多个行，所述属性的子集描述：

---所述主订单标识符和所述次订单标识符，以及

---所述存储的持续时间信息中包括所述动作的开始时间的子集；

--指定由所述关系的所述多个行中的至少一行满足的条件；

--根据所述条件，获取所述关系的所述至少一行的所指定的属性的子集；

--针对所述应用中与所述主订单标识符相关联的每个应用，确定所述动作中的哪些动作在每个应用的执行期间被执行；

--通过以下至少一种来计算针对与所述主订单标识符相关联的每个应用的应用执行的持续时间：

---标识所确定动作的最早动作和所确定动作的最晚动作，并且从所标识最晚动作的最晚时间戳中减去所标识最早动作的最早时间戳；以及

---将与所述主订单标识符相关联的每个应用的执行期间执行的所确定动作的持续时间相加；

--针对所述应用中与所述次订单标识符相关联的每个应用，确定所述动作中的哪些动作在所述应用的执行期间被执行；

--针对与所述次订单标识符相关联的每个应用的应用执行的持续时间；以及

--通过跨与所述主订单和次订单相关联的所有所述应用将与所述主订单标识符相关联的所述动作的所述持续时间和与所述次订单标识符相关联的所述动作的所述持续时间相加，计算所述订单的所述持续时间。