数据库诊断界面系统的制作方法

本发明一般地涉及数据库，并且更具体地，涉及用于提供用于在数据库系统中诊断问题的界面和设计工具的装置和方法。

背景技术：

问题的即时并且准确诊断对正确地维护数据库系统是重要的。随着数据库系统的规模和复杂度增加，会导致问题的可能性也增加。但是，增加的规模和复杂度也往往增加了设计、部署和监视数据库诊断工具的时间和复杂度。

在数据库中诊断问题会是非常棘手的任务，其利用了各种不同的度量和数据库状态信息。数据库管理员(dba)需要大量的专业知识，以便知道需要哪些诊断信息来诊断和解决数据库问题。

传统上，当数据库问题发生时，dba得到问题的警告，并且然后利用数据库工具工作来收集和分析数据库状态信息，以确定引起问题的原因。数据库问题可能往往是不定时发生的，并且可能间歇性地或随机地并且往往只在短暂的时间段发生或表现。dba可能不具有或者可能只有小的时间窗口来收集有用的数据库状态信息以便准确地诊断问题。所执行的分析类型可能是主观的，因为dba会主观地选择分析的类型和要收集的数据来确定引起问题的原因。在许多情况下，，当问题正在发生时dba可能在时间窗口期间没有足够的时间或专门技术来运行最好的诊断工具或过程，从而导致没有产生诊断数据或者产生可能与数据库问题无关的诊断数据。dba可能没有时间来执行分析或者可能不能对特定的数据库问题执行优选的分析。

因此，期望的是用于诊断问题的改进的系统、装置和方法。

技术实现要素：

在一些实施例中，一种用于数据诊断的系统包括一个或多个处理器和与该处理器耦合并且能由该处理器读取的存储器。存储器和处理器存储一系列指令，使得当指令被处理器执行时，这些指令使得处理器向用户呈现图形用户界面。图形用户界面可以允许选择脚本，该脚本当条件发生时要在目标数据库系统上执行。图形用户界面也可以允许设置一个或多个参数，该一个或多个参数定义脚本的报告功能，其中报告功能返回与目标数据库系统有关的数据。该系统也可以定义插件结构，其中插件结构包括脚本和一个或多个参数，并且插件进一步定义触发该脚本的执行的条件。该系统也可以使插件在目标数据库系统上执行，其中在执行期间并且当条件发生时，插件可以根据一个或多个参数返回与目标数据库系统有关的数据。

在实施例中，条件可以是周期性定时器，并且条件可以以周期性的调度触发脚本的执行。条件也可以是用于目标数据库系统的参数的阈值，并且在一些实施例中，阈值可以在插件执行期间当阈值被超过时被动态地改变。脚本的选择可以包括从预定义脚本的列表中选择预定义的库脚本。在实施例中，插件结构可以通过生成包括脚本功能的机器可执行模块来定义。

在另一种实施例中，一种用于定义数据库系统诊断工具的方法呈现了显示用于选择脚本的选项的第一图形用户界面。该方法包括步骤：如果利用第一图形用户界面选择脚本，则该脚本当条件发生时要在目标数据库系统上执行。该方法还呈现了显示用于定义参数的选项的第二图形用户界面，其中参数可以是报告参数。报告参数可以描述脚本的报告功能，其中报告功能返回与目标数据库系统有关的数据。该方法可以生成插件结构，该插件结构可以包括脚本和报告参数，并且定义触发该脚本的执行的条件。此外，该方法可以呈现显示用于将插件结构部署到目标数据库系统的选项的图形用户界面。插件结构可以利用该界面进行部署，并且插件可以在目标数据库系统上执行，以及在执行期间并且条件发生时，插件可以根据报告参数返回与目标数据库系统有关的数据。

在其它实施例中，一种驻留在非临时性处理器可读介质上并且包括处理器可读指令的计算机程序产品可以被配置为使得一个或多个处理器呈现显示用于选择脚本的选项的图形用户界面。指令可以被配置为利用图形用户界面接受对脚本的选择，该脚本当条件发生时要在目标数据库系统上执行。附加的指令可以使图形用户界面显示用于限定参数的选项，并且利用图形用户界面接受对报告参数的选择，该报告参数可以描述脚本的报告功能。报告功能可以返回与目标数据库系统有关的数据。指令可以生成插件结构，该插件结构可以包括脚本和报告参数，并且插件结构可以进一步定义触发该脚本的执行的条件。此外，指令也可以使图形用户界面显示用于将插件结构部署到目标数据库系统的选项和在目标数据库系统上执行插件。在执行期间并且当条件发生时，插件可以根据报告参数返回与目标数据库系统有关的数据。

附图说明

可以通过参考以下示图来实现对各种实施例的本质和优点的进一步理解。

图1示出了具有远程诊断界面的数据库系统的实施例的框图。

图2示出了插件的组件的框图。

图3示出了用于部署插件的方法的实施例。

图4示出了用于设计和部署诊断插件的系统的界面的实施例。

图5示出了用于根据配置库显示和设计配置的系统的界面的实施例。

图6示出了用于显示和设计配置的系统的界面的实施例。

图7示出了用于定义和部署诊断插件的组件的方法的实施例。

图8示出了用于定义和部署诊断插件的组件的方法的另一种实施例。

图9示出了计算机系统的实施例。

具体实施方式

数据库问题或性能下降在没有系统的及时且相关的分析和报告的情况下可能难以诊断。数据库诊断工具可以监视和报告数据库系统状态信息，以帮助数据库管理员(dba)诊断数据库问题。有许多参数、动作、行为、系统状态等可以对数据库问题或数据库性能下降给出信号或做标记。同样，在数据库内有许多数据库参数、状态信息和行为可以被捕获和分析以诊断导致数据库问题的原因。在许多复杂的数据库系统中，监视、捕获或分析所有可能的数据库参数、状态信息、行为等是不切实际的或者不可能的。可能需要dba来更改数据库监视和报告工具的参数，以只监视和报告一组特定的数据库系统状态参数、行为等。

如这里所详细描述的，给出了一种数据库诊断系统，其可以被配置为呈现允许dba定义、部署和监视数据库诊断工具的界面系统。该界面提供了对现有诊断工具库的访问。该界面系统也可以包括创建和定义新诊断工具来监视或报告特定目标数据库系统参数、状态、行为等的能力。

由界面系统创建和指定的工具可以是模块化脚本、配置和插件的组合。一个或多个脚本、配置和插件可以被组装或串联在一起，以组成复杂的诊断任务。每个脚本、配置和插件是自包含的(self-contained)可重用模块。dba可以使用界面系统来组装脚本、配置和插件中一个或多个，以执行期望的诊断任务。

界面系统对数据库系统来说可以是本地的，或者可以远离数据库系统。界面可以在除执行目标数据库系统的计算机之外的系统或计算机上执行。在实施例中，界面系统可以与用于执行或运行由界面创建或设计的脚本、配置和插件的运行时引擎耦合。运行时引擎可以执行监视和报告工具并且将输出诊断工具发送回到界面系统。界面系统还可以包括用于编目(catalog)、分析和修改从数据库系统发送的诊断工具的输出的工具或功能。

在实施例中，由运行时引擎执行的诊断工具可以被配置为周期性地运行或以“拌线(trip-wire)”机制运行，使得只有当达到特定的可定义数据库系统阈值或参数状态时才收集诊断数据。由运行时引擎对工具的定期或拌线执行允许即使dba不知道数据库问题或者当问题正发生时dba不可用于捕捉系统状态信息时，也能自动地捕获数据库系统状态。

诊断系统是可扩展的并且可以用于监视系统状态参数、行为等以及报告和分析许多不同数据库系统状态参数。界面系统的报告和监视功能可以用于收集性能数据、使用情况数据等并且也可以用于数据库系统的优化和微调。

在实施例中，诊断系统包括两组组件。第一组组件包括配置为在目标数据库系统上操作的诊断运行时模块。第二组组件包括界面系统。界面系统提供了可用来定义、生成、维护和部署诊断工具的开发环境。通过利用诊断运行时模块利用第一组组件来执行诊断工具。

图1绘出了根据本发明实施例的具有诊断能力的数据库的系统100。系统100包括界面系统130和数据库系统110。数据库系统110包括数据库模块118和数据库引擎模块114。数据库引擎模块114被配置为接收和处理对数据库模块118的请求。数据库模块118和数据库引擎模块114可以是多种数据库引擎和数据库中的一种，并且本领域技术人员将理解数据库引擎模块114和数据库模块118的各种组件。

在数据库系统110的实施例中，该系统可以包括用于执行诊断工具的诊断运行时模块116和可选的诊断脚本储存库120，其存储要由诊断运行时模块116执行的诊断工具。诊断运行时模块116至少部分地由界面系统130控制和监视。与数据库系统110和界面系统的通信分别经由界面系统130和数据库系统110的通信接口132、112来执行。

界面系统130可以包括通信接口132、呈现模块134和计算模块136。界面系统130及其元素向用户提供用于生成、监视和部署可利用诊断运行时模块116在数据库系统110处执行的诊断工具的用户界面。每个组件中的一些或全部功能可以由计算机硬件、软件和/或固件来执行。图9的计算机系统900可以执行界面系统130和数据库系统110的组件中的一些或全部组件的功能。各个组件的功能可以被合并到较少的模块中或者被分到较多数量的模块中。

在实施例的一个方面，界面系统可以包括驻留在非临时性处理器可读介质上以用于提供界面系统的计算机程序产品。该计算机程序产品可以包括配置为使处理器生成、改变诊断工具以及将诊断工具部署到数据库系统的处理器可读指令。该计算机程序产品可以包括配置为使处理器使得显示图形用户界面的界面系统的界面被呈现，从而使用户能够生成、编辑、监视和部署诊断工具的处理器可读指令。

在诊断系统的实施例中，界面系统130可以远离数据库系统110，如例如在图1中所绘出的。界面系统可以被安装和驻留在单独的系统、计算机系统等中，并且可以经由网络140与诊断运行时模块116通信或者与其一起操作。

在诊断系统的其它实施例中，界面系统130对数据库系统可以是本地的。界面系统可以在与数据库系统110相同的计算机系统中驻留和执行。数据库系统110可以被部署在计算机、集群、计算机网络、工作站、服务器、数据中心等中。界面系统130的模块可以驻留在计算机、集群、计算机网络、工作站、服务器、数据中心等的存储器系统中。界面系统与诊断运行时模块可以经由本地网络、系统总线、局部总线、无线等进行通信。

如本文所描述的，界面系统及其元素向用户提供用于生成、监视和部署利用诊断运行时模块在数据库系统处执行的诊断工具的界面。诊断工具可以包括各种包、脚本、插件、配置、可执行代码等。诊断工具可以是直接可执行的或者可能需要数据库系统上的解释器、虚拟机等。诊断工具的确切配置、结构和设计可以取决于目标数据库系统的类型、诊断工具被配置为执行的任务和动作的类型、工具的性能或安全性要求、等等。

在实施例中，诊断工具可以包括数据库插件。插件本身可以包括由配置进行控制并且被组装成插件结构的一个或多个脚本。插件结构可以被部署到数据库系统，以用于由诊断运行时模块执行。

图2示出了插件的实施例的主要组件的框图。插件202可以包括子模块，诸如脚本210和/或操作系统命令208。在实施例中，脚本可以是包含sql、ddl、plsql语句或代码的脚本。插件202的脚本210可以利用配置206配置为具有附加参数。配置206可以用作用于所有脚本210的包含定义(containmentdefinition)并且定义参数，诸如脚本的执行次序、触发每个脚本的执行的条件、用于启动脚本的执行的os命令、脚本功能到数据库系统功能的映射等。插件202可以被配置为引用或指向配置文件中的一个或多个配置文件。插件、配置、脚本等的模块中的每个模块可以是模块化的和可重用的。每个插件可以引用一个或多个配置。每个配置可以包括一个或多个不同的脚本。同样，配置和脚本可以分别被一个或多个不同的插件或配置引用。在诊断工具的这个实施例中，插件202的脚本210可以用作主建造块来定义和执行任务，诸如监视和报告数据库系统的系统状态。

在实施例中，插件结构可以封装脚本和配置，使得当插件被部署时，脚本和配置作为插件的一部分被部署或发送到目标数据库系统。在其它实施例中，插件可以只引用或指向可能已被存储在数据库系统中或存储在可由界面系统或数据库系统访问的单独的储存库中的配置的脚本。在这种实施例中，当插件被部署时，可以不必与插件一起发送脚本或配置。

诊断系统的界面系统130可用于生成、定义、监视和部署用于利用诊断运行时模块116在数据库系统110处执行的插件。界面系统可以用来将脚本和配置组装成插件以执行特定的诊断任务。一旦插件的所有模块和部分都被定义和封装，界面系统130就可以用来将插件传送到数据库系统110，用于由诊断运行时模块116执行。

诊断运行时模块116可以启动和控制由界面系统130生成和部署的诊断工具的执行。在其中诊断工具包括图2中绘出的和在本文描述的插件结构的实施例中，插件可以由界面系统通过将插件传送到数据库系统110进行部署。在传送时，插件利用对诊断运行时模块116的调用来初始化，诊断运行时模块116读取插件和由插件引用的配置并且根据在插件中定义的配置执行脚本。这些步骤在图3中示出。在诊断工具被部署到数据库系统之后(其中在这个例子中诊断工具是插件)，插件在步骤302中被初始化。插件的初始化可以包括检查其结构和有效性、并且确保插件包含所有必要的部分、检查恶意代码、检查由插件引用的所有配置或者与插件一起被封装或者在可访问的储存库中得到、等等。在初始化之后的下一步骤中，在步骤304中调用诊断运行时模块。诊断运行时模块可以进一步在步骤306中解析插件文件和读取配置。插件的配置可以包括与插件相关联的脚本的定义和列表。运行时引擎可以确保被引用的脚本是插件的一部分或者在可访问的储存库中。在下一步骤中，诊断运行时模块可以在步骤308中开始脚本的执行。脚本的执行可以由插件的配置中定义的参数来调度和控制。在脚本的执行期间，脚本可能需要执行特定的操作系统调用、读或写操作，等等。这些系统调用以及其它操作可以被传递给数据库系统的操作系统或者其它程序、硬件等用于处理。用于做出系统调用、执行读或写操作的设施和方法可以在插件的配置中进行控制或定义并且对每个数据库系统可以是不同的。

在数据库系统处由诊断运行时引擎对诊断工具的执行可以以间隔被调度或者根据标准有条件地执行。在一些实施例中，可以在一天中的特定时间、以特定的或随机的时间间隔、以特定或随机的次数等来执行诊断工具。例如，诊断工具可以被调度为每30秒运行一百次并且然后终止。在一些实施例中，可以基于数据库系统的参数或状态有条件地执行诊断工具。诊断工具的有条件执行可以基于数据库的活动、数据库状态的参数、数据库状态的特定值或变量，等等。用于执行诊断工具的条件标准可以是所谓的“拌线”条件。诊断工具可以只当数据库被监视的状态的参数值与阈值或值的区间相匹配时才有条件地执行。例如，诊断工具可以被配置为当在数据库处执行查询的平均时间超过预定值时才执行。

当拌线被触发时，诊断工具可以被配置为执行和报告特定数据库系统参数或状态信息，以帮助dba诊断数据库中的问题。在一些情况下，当拌线被触发时，诊断工具可以被配置为在数据库上启动维护动作或任务、提醒dba、向用户发电子邮件通知或者启动行动来解决问题。

拌线条件可以在利用界面系统在设计和部署诊断工具期间被静态地设置。拌线条件也可以在数据库的操作期间被动态地设置和调整。诊断工具可以监视数据库系统的状态和行为以及设置或调整阈值和拌线条件。诊断工具可以被配置为监视数据库参数以及“学习”或积累关于数据库参数或数据库状态行为的值的正常或预期范围的统计数据。诊断工具可以连续地或周期性地监视特定的数据库参数并且动态地为这些参数设置拌线条件。拌线条件可以基于一天中的时间、一年中的时间等被动态地调整。例如，诊断工具可以收集关于每个查询的平均服务时间的统计数据。查询时间通常会在当数据库经历大负荷量时的一天中的某些时间期间增加。对于例如当负荷量大时的时间段，用于拌线条件的阈值可以被增加。

在实施例中，阈值可以在插件级别进行设置并且可以是在插件文件内静态的。如果存在多于一个插件的迭代并且阈值被突破，则阈值可以被调整为新的突破的值并且在运行时引擎内被动态地维护。例如，阈值可以被跟踪作为由拌线返回的最高值。插件可以被配置为只有当最近被维护的阈值被突破时才激活或运行。但是，每次插件被重新初始化时，阈值可以被初始化为来自插件脚本中的静态值。

在实施例中，可以使用界面系统来设置或定义被监视的并且为其动态设置阈值的参数。可以在界面系统中定义诊断工具的动态变化的拌线条件的参数、行为、规则等。可以定义用于建立被监视参数的基线或预期值的方法和时间以及用于触发拌线条件的偏差或变化率。

在实施例中，诊断工具可以被配置为在大部分时间处于休眠或者睡眠。诊断工具可以只在很短的时间段期间或者当问题或拌线被识别时才是活动的，以便限制或最小化对数据库系统的资源的影响或使用。

对于在图2中绘出的诊断工具的结构，可以在插件的配置中定义执行标准。用于定义和部署插件的界面系统可以是可操作的，以允许配置的修改和设计。可以使用配置来定义插件的脚本如何、何时、以什么次序被诊断运行时模块执行。插件的配置可以定义脚本的执行的调度。脚本中的一些可以在配置中定义，以定期地(例如，每隔1分钟，10分钟或更多分钟)执行。配置可以定义拌线条件，其触发在插件中定义的一个或多个脚本的执行。配置可以定义条件语句，诸如定义触发一个或多个脚本的执行的拌线条件的sql语句。配置可以基于在一个脚本执行之后数据库系统的输出或行为定义脚本的执行调度或次序。配置可以被定义为执行监视脚本，其可以监视数据库的一个或多个参数或行为。监视脚本可以被配置为向诊断运行时引擎返回一个或多个值。插件的配置可以基于监视脚本的输出定义其它脚本的有条件的、缺省的、优选的等动作或脚本执行次序或调度。

在一些实施例中，脚本可以被定义为具有监视或报告能力。具有监视能力的脚本可以在一旦被数据库的诊断运行时模块执行时就监视数据库系统的一个或多个参数、值、行为等。监视脚本可以在其执行期间或在其执行完成时返回一个或多个值。监视脚本的返回值可以用作拌线条件来启动其它监视脚本的执行、启动报告脚本的执行、或者改变在插件中定义的脚本的执行调度或执行次序。具有报告能力的脚本可以在一旦被数据库系统的诊断运行时引擎执行时就报告数据库系统的一个或多个值、参数、行为、状态信息等。报告脚本的输出可以被传送到界面系统并且可以被定义为返回关于数据库的对诊断数据库问题可能有用的信息。

脚本的监视和报告功能可以被合并到一个脚本中。单个脚本可以定义这两种功能，而没有脱离本文所概述的诊断系统的主旨和结构。同样，在一些实施例中，报告和监视功能可以跨被执行以执行一个或多个监视或报告任务的多个不同脚本进行拆分。

在实施例中，报告、监视、执行、拌线、阈值参数等可以在插件的各个模块和组件中定义。取决于插件和脚本的功能可以在插件的不同级别中定义参数。在一些实施例中，可以在多于一个的插件级别中定义参数(即，在脚本、配置和插件中定义)。可以在多于一个位置中定义参数的层次。例如，在插件级别的参数定义可以覆盖(override)同一参数在脚本级别的定义。层次可以被定义为使脚本级别在层次中最低、配置级别为次低并且插件定义具有最高级别。在一个例子中，插件可以包括参数定义，其包括拌线和阈值参数、调度器选项、o/s命令和通信信道参数、插件名称参数、配置选项、以及报告目录位置。当插件引用包含其中一些脚本可能定义了嵌入参数的多个脚本的配置时，插件可以自动地拷贝在配置和脚本中定义的参数，并且在插件级别提供对这些参数的定义。在其中在多于一个级别中定义了参数的情况下，可以基于其定义的层次对参数定义进行整合(consolidate)和优先级化(prioritize)。

现在返回到诊断系统的界面系统。如上所述，诊断系统的界面系统可以用于生成、定义、监视和部署插件。可以使用界面系统将脚本和配置组装成可以被数据库系统的诊断运行时引擎部署和执行的插件。可以使用界面系统来定义参数，诸如脚本的执行调度、拌线条件、报告参数等。界面系统提供了加快创建可能复杂的监视和报告脚本和功能的界面。

在实施例中，界面系统可以向用户呈现具有用于配置、定义和部署插件的选择和输入控件的图形界面。界面系统的呈现模块134可以用来向用户呈现图形用户界面(gui)。呈现模块134可以经由远程连接对用户可用。例如，呈现模块134可以包括经由web浏览器呈现给用户的基于web的图形用户界面。因此，用户可以跨诸如互联网的网络与界面系统远程地交互。

图4示出了界面系统的图形用户界面的实施例。该gui可以是基于web的。因此，用户可以跨网络经由web浏览器与该gui交互。图4的gui可以对应于图1的系统的呈现模块134或者可以由图1的系统的呈现模块134生成。图4中的gui示出了用于与gui交互以便设计、定义、修改和部署诊断工具的主导航选项和方法。界面导航窗格420在顶级标签422中包括主要功能选择菜单栏。顶级标签422选择界面的模式。顶级标签422在与界面系统相关联的任务的主要类型之间选择gui的模式。在图4示出的实施例中，顶级标签422允许在插件开发(“plug-indevelopment”)、插件部署(“plug-indeployment”)、报告(“reporting”)和诸如sql编辑功能(“sqlworkshop”)、作业控制(“jobcontrol”)的若干种其它工具功能的模式之间进行选择。取决于顶级标签422的选择，gui的界面导航窗格420可以具有为顶级标签422的每个任务提供更多选项的较低级别标签421。图4的图示示出了用于插件开发任务的示例较低级别标签421。对于本文所述的特定诊断工具实施例，用于插件开发任务的较低级别标签421可以包括用于定义脚本参数(“scriptparameters”)、定义库脚本(“libraryscripts”)、定义配置(“condifurations”)、以及定义插件模块(“plug-inmodules”)的功能。用于插件开发任务的较低级别标签421还可以包括用于允许合并配置(“mergeconfigurations”)或拷贝对象(“copyobject”)功能的选项。

特定较低级别标签421的选择会启动用于定义在较低级别标签421中选择的特定功能的更多选项或工具的显示。图5示出了具有在界面导航窗格420下方的附加功能定义区域501的gui。功能定义区域501包括用于定义较低级别标签421选择的特定功能的选项和工具。取决于在功能定义区域501内执行的操作，功能定义区域501可以变化或者具有附加的视图。取决于在功能定义区域501中采取的动作，功能定义区域501可以具有带不同输入控件的一个或多个视图。例如，在图5和图6中对于顶级标签422和较低级别标签421的相同选择，功能定义区域501是不同的。在图5中，功能定义区域501被配置为具有从库配置的列表中选择配置的控件，而在图6的功能定义区域501被配置为具有定义或编辑配置参数的控件。

选择顶级标签422的“plug-indevelopment”定义较低级别标签421的选择和用于选择和定义诊断工具的组件和参数的功能定义区域501。在本文所述的示例实施例中，对诊断工具的定义包括定义脚本、脚本参数、配置、配置参数、插件和插件参数。

当在顶级标签422的“plug-indevelopment”任务期间定义包含插件的库脚本时，gui的功能定义区域501可以呈现用于选择、查看和列出预定义脚本的控件。该控件可以包括查看参数、源代码或编辑每个脚本的部分。该控件可以读取现有脚本的本地或远程储存库来显示给用户。可替代地，当定义包括插件的脚本时，gui的功能定义区域可以包括用于插入脚本的参数、脚本的描述、用来定义脚本的脚本语言的类型等的控件。gui可以包括用于由用户插入脚本代码的脚本源代码接收区域。源代码接收区域可以验证源代码的错误并且提供模板，以利用可重用的代码片段、头文件(header)等填充源代码。

当定义包括插件的配置时，gui的功能定义区域501可以呈现用于选择和列出预定义配置的控件。视图控件可以包括查看参数、源代码或编辑每个配置的部分。该控件可以读取现有配置的本地或远程储存库来显示给用户。可替代地，当定义配置时，gui的功能定义区域501可以包括用于插入配置的参数、配置的描述和配置的类别的输入控件。当创建或编辑配置时，gui可以包括用于选择由配置引用的脚本的脚本选择控件。用于脚本选择的控件可以可选地包括用于调度脚本执行、定义启动每个脚本的执行的“拌线”条件、配置的脚本的执行次序、调度条件等的用户输入。

当定义插件时，gui的功能定义区域501可以提供用于选择和列出预定义插件的控件。用于选择和列出预定义插件的查看控件可以包括查看每个插件的参数和配置的区域。插件的选择和查看控件可以读取现有插件的本地或远程储存库来显示给用户。可替代地，当定义插件时，gui的功能定义区域501可以包括用于插入插件的参数、插件的描述、输出参数和目的地等的输入控件。当创建或编辑插件时，gui可以包括用于选择由插件引用的配置的配置选择控件。用于编辑插件的控件可以包括用于调度插件的执行、定义启动每个插件的执行的“拌线”条件以及因此由每个插件定义的一组脚本和配置的用户输入。定义插件的执行调度可以包括用于输入执行的迭代数量、执行之间的睡眠间隔、用于调度执行的调度器等的控件。

在插件的开发期间，gui可以呈现工具来合并配置或者拷贝或合并插件、配置参数、插件参数等。可以使用合并操作将一个或多个脚本、配置或插件的功能合并成更大的模块。在合并配置操作期间，gui的功能定义区域501可以提供用于选择合并的配置的选择控件。

选择顶级标签422的“plug-indeployment”可以提供较低级别标签和在功能定义区域501中用于选择用于部署到目标数据库系统的已定义脚本、插件和配置模块的控件。在顶级标签的“plug-indeployment”功能期间，较低级别标签可以提供用于加载定义的脚本、加载定义的配置、生成配置和生成用于部署的插件的功能。当定义要部署的组件时，gui的功能定义区域501可以提供用于选择和列出定义的库组件的控件。gui的部署功能可以创建具有可以被诊断运行时模块在目标数据库处执行的所有必要配置、脚本和定义的封装插件。

在实施例中，界面系统可以呈现用于将代码从一种类型转换到另一种类型的选项。界面系统可以呈现后台转换工具。界面系统的计算模块136可以被配置为转换由界面系统的gui接收到的脚本、配置和插件的代码，以创建和输出目标代码。例如，如果脚本是用sql语言语法输入的，则可以由计算模块将接收到的脚本代码转换到另一种脚本语言代码，诸如plsql。将一种代码转换到另一种代码可以包括在界面系统的计算模块上运行的一个或多个转换工具。

应当理解，在其它实施例中，在gui内呈现的布局和特定信息可能不同。例如，gui的布局和组件可以被修改以在给定时间向用户呈现更多或更少的信息或输入选项。gui的布局和组件可以被修改以向用户呈现不同的界面来定义、监视和部署诊断工具。

例如，在不同的实施例中，gui可以被修改，以向用户呈现问答式界面。在该界面中，诊断工具可以由在gui中呈现的一系列问题来定义。gui可以呈现关于用户想要执行的分析或监视的类型、数据库正在经历的问题的症状等问题。gui可以呈现具有多选输入的控件或者允许用户对所呈现的问题定义其自己的答案的其它输入控件。基于所提供的答案，界面系统可以选择满足标准的一个或多个诊断工具。在实施例中，界面系统可以基于由用户提供的答案组装一组脚本、配置和插件，或者向用户呈现与所提供的答案相匹配或对应的若干个诊断工具的选项。可以向用户呈现具有用于编辑、选择或修改所呈现的诊断工具的附加输入控件。问题和答案界面可以为新手用户提供较简单的界面，从而允许用户专注于数据库的问题或诊断而不是诊断工具本身。在实施例中，界面系统的gui可以具有混合的界面并且可以包括两种或更多种操作模式。一种模式可以是所谓的“专家模式”，其允许用户输入、定义和指定大多数或所有的诊断工具参数。在另一种模式中，界面系统的gui可以呈现简化的界面，诸如问题和答案界面。

在另一种实施例中，界面系统可以向用户呈现基于文本或基于终端的界面。用户界面可以只依赖文本输入和输出来定义诊断工具。

在实施例中，可以针对每个用户、数据库系统或客户定制界面系统。界面系统可以具有多个预定义的库诊断工具，其可以包括脚本、配置、插件等。可以针对每个数据库系统、每个用户或客户定制预定义的工具。界面可以自动地确定诊断工具被设计用于的数据库系统并且将可用的预定义的工具列表过滤为只适用于该数据库系统的那些工具。

如本文所述，诊断工具和组成诊断工具的相应模块和元素可以是可重用的和模块化的。界面可以提供选项来从外部源或储存库中导入(import)诊断工具。界面系统可以接受由第三方通过电子邮件或电子方式发送给用户的诊断工具，诸如插件。诊断工具可以被导入到界面中并且利用界面系统部署到数据库系统。

可以利用图1的系统和/或图5的gui执行各种方法。图7示出了用于定义诊断工具的方法700的实施例。方法700的每个步骤可以利用图1的系统100或者配置为呈现用于诊断工具的界面系统gui的一些其它系统来执行。方法700的每个步骤可以由计算机系统来执行。例如，可以使用图9的计算机系统900来执行方法700的每个步骤。相应地，用于执行方法700的装置包括一个或多个计算机系统、网络和/或远程计算机系统。

在图7的方法的步骤705处，可以呈现界面系统的gui。图形界面可以呈现在界面系统的输出设备处，诸如监视器、移动屏设备、计算机等。gui界面可以是在图5中所示的图形界面并且向用户呈现定义、监视和部署诊断工具的选项。该界面可以具有用于从用户接收输入的各种输入控件。gui可以具有用于文本、多选、触摸、控制等的控件。

在步骤710处，可以定义诊断工具的至少一个监视参数。gui可以向用户呈现用于为数据库系统定义监视的各方面的选项。用户可以定义哪些状态、行为等可以被诊断工具监视或跟踪。该定义步骤可以包括从一个或多个预定义脚本的列表中选择脚本。

在步骤715处，可以定义诊断工具的至少一个报告参数。gui可以向用户呈现用于为数据库系统定义报告的各方面的选项。用户可以定义哪些状态、行为等可以被诊断工具跟踪或报告给用户。该定义步骤可以包括从一个或多个预定义脚本的列表中选择脚本。该定义步骤715可以定义要从数据库中捕获的、对诊断数据库问题或优化数据库的性能可能有用的状态、行为等。

在步骤720处，可以定义诊断工具的配置。gui可以向用户呈现用于定义配置的各方面的选项。配置可以定义一个或多个参数，诸如本文所讨论的脚本的执行调度、拌线条件、报告选项等。

在步骤725处，诊断工具可以被封装并且部署到目标数据库系统。gui可以向用户呈现用于定义和启动诊断工具的封装的选项。封装可以包括将用于执行监视/报告的脚本和配置一起放到插件结构中。gui可以向用户呈现用于将封装的插件发送到数据库的选项。

在步骤730处，可以启动封装并且部署的诊断工具的执行。在数据库系统处的诊断运行时引擎可以启动该执行。在界面系统处的gui可以向用户呈现用于启动、停止或暂停部署的诊断工具的执行的选项。

图8示出了用于定义诊断工具的方法800的另一种实施例。方法800的每个步骤可以利用图1的系统100或配置为呈现用于诊断工具的界面系统gui的一些其它系统来执行。方法800的每个步骤可以由计算机系统来执行。例如，可以使用图9的计算机系统900来执行方法800的每个步骤。相应地，用于执行方法800的装置包括一个或多个计算机系统、网络和/或远程计算机系统。

在图8的方法的步骤805处，可以呈现界面系统的gui。图形界面可以呈现在界面系统的输出设备处，诸如监视器、移动屏设备、计算机等。gui界面可以是在图5中所示的图形界面并且向用户呈现定义、监视和部署诊断工具的选项。该界面可以具有用于从用户接收输入的各种输入控件。gui可以具有用于文本、多选、触摸、控制等的控件。

在步骤810处，可以定义诊断工具的至少一个监视参数。gui可以向用户呈现用于为数据库系统定义监视参数的各方面的选项。用户可以定义哪些参数、状态、行为等可以被诊断工具监视或跟踪。该定义步骤可以包括从一个或多个预定义参数的列表中选择一个或多个监视参数。

在步骤815处，可以定义基于在步骤810中定义的监视参数的至少一个脚本。gui可以基于监视参数向用户呈现用于定义监视脚本的各方面的选项。脚本可以由用户通过利用脚本源代码定义脚本来定义。在实施例中，定义脚本可以包括自动地或半自动地生成脚本。脚本可以利用来自步骤810的监视参数通过模板生成，其中模板利用定义的参数自动地进行填充。

在步骤820处，可以定义诊断工具的至少一个报告参数。gui可以向用户呈现用于为数据库系统定义报告参数的各方面的选项。用户可以定义哪些参数、状态、行为等可以被诊断工具跟踪或报告给用户。该定义步骤820可以定义要从数据库中捕获的、对诊断数据库问题或优化性能可能有用的参数、状态、行为等。

在步骤825处，可以定义基于在步骤820中定义的报告参数的至少一个脚本。gui可以基于报告参数向用户呈现用于定义报告脚本的各方面的选项。脚本可以由用户通过利用脚本源代码定义脚本来定义。在实施例中，定义脚本可以包括自动地或半自动地生成脚本。脚本可以利用来自步骤820的报告参数通过模板来生成，其中模板利用定义的参数进行自动地填充。

在步骤830处，可以定义诊断工具的至少一个执行参数。gui可以向用户呈现用于为数据库系统定义执行次序、拌线条件、重复等的各方面的选项。用户可以定义在前面步骤中定义的脚本中哪些脚本要被执行、多频繁地执行、以及要被执行多少次。用户可以定义拌线条件或者定义可控制脚本执行的其它条件语句。

在步骤835处，可以定义基于在步骤830中定义的执行参数的至少一个配置。gui可以基于执行参数向用户呈现用于定义配置的各方面的选项。配置可以由用户通过利用代码、脚本语言、标记语言等定义配置来定义。在实施例中，定义配置可以包括自动地或半自动地生成配置代码。配置可以利用来自步骤830的执行参数通过模板来生成，其中模板利用定义的参数进行自动地填充。

在步骤840处，诊断工具可以被封装并且部署到目标数据库系统。gui可以向用户呈现用于定义和启动诊断工具的封装的选项。封装可以包括将定义的监视脚本、报告脚本和配置一起放到插件结构中。gui可以向用户呈现用于将封装的插件发送到数据库的选项。

图9示出了计算机系统的实施例。如在图9中示出的计算机系统可以被结合作为之前描述的诸如图1的系统100的计算机化的系统的一部分。计算机系统900可以代表在本申请中所讨论的计算机系统和/或远程计算机系统。图9提供了可以执行如本文所述的由各种实施例提供的方法的计算机系统900的实施例的示意图。应当指出，图9只是要提供各种组件的一般化示图，其中任何或所有组件都可以被适当地利用。因此，图9广泛地示出各个系统元素如何可以以相对分离或相对较集成的方式来实现。

计算机系统900被示为包括可以经由总线905被电耦合(或者适当地可以以其它方式进行通信)的硬件元件。硬件元件可以包括一个或多个处理器910，包括但不限于一个或多个通用处理器和/或一个或多个专用处理器(诸如数字信号处理芯片、图形加速处理器等)；一个或多个输入设备915，其可以包括但不限于鼠标、键盘等；以及一个或多个输出设备920，其可以包括但不限于显示设备、打印机等。

计算机系统900还可以包括一个或多个非临时性存储设备925(和/或与其通信)，非临时性存储设备可以包括但不限于，本地和/或网络可访问存储装置和/或可以包括但不限于盘驱动器、驱动器阵列、光存储设备、固态存储设备，诸如随机存取存储器(“ram”)和/或只读存储器(“rom”)，其可以是可编程的、闪存可更新的等。此类存储设备可以被配置为实现任何适当的数据存储库，包括但不限于各种文件系统、数据库结构等。

计算机系统900也可以包括通信子系统930，其可以包括但不限于调制解调器、网卡(无线或有线)、红外通信设备、无线通信设备、和/或芯片组(诸如蓝牙^tm设备、802.11设备、wifi设备、wimax设备、蜂窝通信设施等)，等等。通信子系统930可以允许与网络(仅举一个例子，诸如下面描述的网络)、其它计算机系统和/或本文所述的任何其它设备交换数据。在许多实施例中，计算机系统900还将包括工作存储器935，其可以包括如上所述的ram或rom设备。

计算机系统900也可以包括被示为当前位于工作存储器935内的软件元素，包括操作系统940、设备驱动器、可执行库和/或其它代码(诸如一个或多个应用程序945)，其中应用程序可以包括由各种实施例提供的计算机程序，和/或可以被设计为实现由其它实施例提供的方法和/或配置由其它实施例提供的系统，如本文所描述的。仅仅作为例子，关于以上讨论的(一个或多个)方法所描述的一个或多个过程可以被实现为可由计算机(和/或计算机内的处理器)执行的代码和/或指令；于是，在一方面，这种代码和/或指令可以用来配置和/或适配通用计算机(或其它设备)，以根据所述方法执行一个或多个操作。

这些指令和/或代码的集合可以存储在非临时性计算机可读存储介质上，诸如上述(一个或多个)非临时性存储设备925。在一些情况下，存储介质可以被结合在诸如计算机系统900的计算机系统中。在其它实施例中，存储介质可能与计算机系统分离(例如，可拆卸介质，诸如光盘)，和/或在安装包中提供，使得存储介质可以被用来利用其上存储的指令/代码来编程、配置和/或适配通用计算机。这些指令可能采用可由计算机系统900执行的可执行代码的形式，和/或可以采用源和/或可安装代码的形式，其中，当在计算机系统900上编译和/或安装该代码时(例如，利用任何各种一般可获得的编译器、安装程序、压缩/解压缩实用程序等)，则采用可执行代码的形式。

对本领域技术人员来说将很显然，可以根据具体需求做出实质性的变化。例如，也可以使用定制的硬件和/或可以用硬件、软件(包括可移植软件，诸如applet等)或者二者来实现特定的元件。另外，可以采用到诸如网络输入/输出设备的其它计算设备的连接。

如以上所提到的，在一方面，一些实施例可以采用计算机系统(诸如计算机系统900)来执行根据本发明的各种实施例的方法。根据一组实施例，此类方法的一些或全部过程由计算机系统900响应于处理器910执行包含在工作存储器935中的一条或多条指令的一个或多个序列(该一条或多条指令可以结合到操作系统940和/或其它代码中，诸如应用程序945)而执行。这种指令可以从另一计算机可读介质(诸如(一个或多个)非临时性存储设备925中的一个或多个)读取到工作存储器935中。仅仅作为例子，执行包含在工作存储器935中的指令序列会使得(一个或多个)处理器910执行本文所述方法的一个或多个过程。

如本文所使用的，术语“机器可读介质”和“计算机可读介质”指参与提供使机器以特定方式操作的数据的任何介质。在利用计算机系统900实现的实施例中，各种计算机可读介质可以参与向(一个或多个)处理器910提供用于执行的指令/代码和/或可以用来存储和/或携带这种指令/代码。在许多实现中，计算机可读介质是物理的和/或有形的存储介质。这种介质可以采用非易失性介质或易失性介质的形式。非易失性介质包括例如光盘和/或磁盘，诸如(一个或多个)非临时性存储设备925。易失性介质包括但不限于动态存储器，诸如工作存储器935。

物理的和/或有形的计算机可读介质的常见形式包括例如软盘、柔性盘、硬盘、磁带或者任何其它磁介质、cd-rom、任何其它光学介质、穿孔卡片、纸带、任何其它具有孔模式的物理介质、ram、prom、eprom、flash-eprom、任何其它存储器芯片或盒式磁带、或者计算机可以从中读取指令和/或代码的任何其它介质。

各种形式的计算机可读介质可以参与把一条或多条指令的一个或多个序列运送到(一个或多个)处理器910用于执行。仅仅作为例子，指令可以最初在远程计算机的磁盘和/或光盘上携带。远程计算机可以把指令加载到其动态存储器中并且把指令作为信号经传输介质发送，以便由计算机系统900接收和/或执行。

通信子系统930(和/或其组件)一般将接收信号，并且总线905然后可以把信号(和/或由这些信号携带的数据、指令等)运送到工作存储器935，(一个或多个)处理器910从工作存储器935检索和执行指令。由工作存储器935接收到的指令可以在被(一个或多个)处理器910执行之前或之后可选地存储在非临时性存储设备925上。

还应该理解，计算机系统的组件可以跨网络分布。例如，一些处理可以利用第一处理器在一个位置执行，而其它处理可以由远离第一处理器的另一个处理器执行。计算机系统900的其它组件可以类似地分布。

以上所讨论的方法、系统和设备是例子。各种配置可以适当地省略、替换或添加各种过程或部件。例如，在可替代的配置中，方法可以按与所述不同的次序执行，和/或各个阶段可以被添加、省略和/或组合。此外，关于某些配置所描述的特征可以在各种其它配置中组合。配置的不同方面和元素可以以类似的方式组合。此外，技术在发展，并且因此，许多元素是例子并且没有限制本公开内容或权利要求的范围。

在描述中给出了具体细节，以提供对示例配置(包括实现)的透彻理解。但是，在没有这些具体细节的情况下，配置也可以被实践。例如，没有不必要的细节的情况下示出了众所周知的电路、过程、算法、结构和技术，以避免模糊配置。这种描述仅仅提供示例配置，而没有限制权利要求的范围、适用性或配置。相反，之前对配置的描述将为本领域技术人员提供用于实现所述技术的可行描述。在不背离本公开内容的主旨或范围的情况下，可以对元素的功能和布置做出各种变化。

此外，配置可以被描述为被绘为流程图或框图的过程。虽然每个配置都可以把操作描述为顺序过程，但是许多操作可以并行地或者同时地执行。此外，操作的次序可以被重新布置。过程可以具有图中没有包括的附加步骤。此外，方法的例子可以由硬件、软件、固件、中间件、微代码、硬件描述语言或其任意组合来实现。当用软件、固件、中间件或微代码实现时，执行必要任务的程序代码或代码片段可以存储在诸如存储介质的非临时性计算机可读介质中。处理器可以执行所述的任务。

已经描述了若干种示例配置，在不背离本公开内容的主旨的情况下，可以使用各种修改、可替换构造和等价物。例如，上述元素可以是更大系统的组件，在该系统中，其它规则可以优先或以其它方式修改本发明的应用。此外，可以在以上元素被考虑之前、期间或之后采取许多步骤。相应地，以上描述没有约束权利要求的范围。