CN103412911A - 数据库系统的性能监控方法以及装置 - Google Patents

Abstract

本发明提供一种数据库系统的性能监控方法及装置，所述的性能监控方法包括：获取预先设定的性能指标以及调度时间表；从目标端数据库系统上按照所述的调度时间表采集所述的性能指标对应的数据；从性能指标报警阈值表中获取预先设定的与所述的目标端数据库系统相对应的静态阈值以及动态阈值；判断所述的数据是否同时超出所述的静态阈值以及动态阈值；当判断为否时，根据所述数据的类型统一所述数据的单位；否则，根据所述的数据生成报警信息。能够基于每一台数据库性能基线的动态监控指标，对性能的改变值进行对比分析，根据不同服务器动态调整预警阈值，并根据业务增长量自动修正未来性能预期的性能容量。

Description

数据库系统的性能监控方法以及装置

技术领域

本发明是关于数据库系统技术领域，特别是关于数据库系统的监控技术，具体的讲是一种数据库系统的性能监控方法以及装置。

背景技术

目前，数据库系统在开放平台应用上的使用非常广泛，如何让服务器、存储资源能够有效被利用，在保证数据库性能的前提下，有效减少资源的开销，节省生产成本，成为当今信息科技的一个主要问题。随着数据量的不断增长，特别是随着我国各企业建设数据中心，进行数据的集中处理后，数据量大幅增加，数据库系统服务器资源可用量逐渐减少，性能逐渐降低。

现有技术中，数据库系统的监控系统一般均是基于时点值信息进行的，如CPU空闲率、内存使用率、磁盘读写速度等。但是在生产系统的日常维护中，基于时点值的监控往往存在一些不足。比如某数据库CPU日常使用率在40%左右，而在某次应用程序变更后，日常使用率上升至60%左右。对于一般报警阈值(经验值为80%)，则并未到达报警阈值，但并不能说数据库的性能不存在问题。

因此，如何进行数据性能监控，统一阈值的性能容量报警以满足现有生产运维对于运维前瞻性的要求一直是困扰业界的一个难题。

发明内容

为了克服现有技术存在的上述技术难题，本发明实施例提供了一种数据库系统的性能监控方法以及装置，能够基于每一台数据库性能基线的动态监控指标，对性能的改变值进行对比分析，根据不同服务器动态调整预警阈值，并根据业务增长量自动修正未来性能预期的性能容量。

本发明的目的之一是，提供一种数据库系统的性能监控方法，所述的性能监控方法包括：获取预先设定的性能指标以及调度时间表；从目标端数据库系统上按照所述的调度时间表采集所述的性能指标对应的数据；从性能指标报警阈值表中获取预先设定的与所述的目标端数据库系统相对应的静态阈值以及动态阈值；判断所述的数据是否同时超出所述的静态阈值以及动态阈值；当判断为否时，根据所述数据的类型统一所述数据的单位；否则，根据所述的数据生成报警信息。

本发明的目的之一是，提供一种数据库系统的性能监控装置，所述的性能监控装置包括：性能指标及调度时间表获取模块，用于获取预先设定的性能指标以及调度时间表；数据采集模块，用于从目标端数据库系统上按照所述的调度时间表采集所述的性能指标对应的数据；静态阈值及动态阈值获取模块，用于从性能指标报警阈值表中获取预先设定的与所述的目标端数据库系统相对应的静态阈值以及动态阈值；第一判断模块，用于判断所述的数据是否同时超出所述的静态阈值以及动态阈值；第一处理模块，用于当所述的第一判断模块判断为否时，根据所述数据的类型统一所述数据的单位；第二处理模块，用于当所述的第一判断模块判断为否时，根据所述的数据生成报警信息。

本发明的有益效果在于，提供了一种数据库系统的性能监控方法以及装置，为数据库系统量身打造，用动态调整的性能容量基线来动态评估每一台数据库系统的性能情况，能够对未来的性能问题作出较为准确的预判，根据首创的性能消耗恢复期望来酌情对数据库所需资源做出较为精确地调整，在保证数据库性能和资源充足的前提下，减少了不必要的资源浪费，提高资金的使用效率，减少了生产运行成本，对于使用数据库系统企业，有较为重要的现实意义。

为让本发明的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种数据库系统的性能监控方法的实施方式一的具体流程图；

图2为本发明实施例提供的一种数据库系统的性能监控方法的实施方式二的具体流程图；

图3为图1中的步骤S105的具体流程图；

图4为本发明实施例提供的一种数据库系统的性能监控方法的实施方式三的具体流程图；

图5为本发明实施例提供的一种数据库系统的性能监控方法的实施方式四的具体流程图；

图6为本发明实施例提供的一种数据库系统的性能监控方法的实施方式五的具体流程图；

图7为本发明实施例提供的一种数据库系统的性能监控装置的实施方式一的结构框图；

图8为本发明实施例提供的一种数据库系统的性能监控装置的实施方式二的结构框图；

图9为图7中的第一处理模块的具体结构框图；

图10为本发明实施例提供的一种数据库系统的性能监控装置中基线值更新单元的实施方式一的结构框图；

图11为本发明实施例提供的一种数据库系统的性能监控装置中基线值更新单元的实施方式二的结构框图；

图12为本发明实施例提供的一种数据库系统的性能监控装置的实施方式五的结构框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明是一种通用的数据库系统性能容量采集与分析方法，通过对系统性能指标的建模和基线收集，达到精算每月每日的性能改变或资源消耗，以达到精确判定未来性能容量占用趋势的目的。

本发明对每台数据库单独建立基线，根据此基线计算相关性能指标动态变化率，当变化率超过一定百分率时，提示生产维护人员关注。此外本发明利用采集成熟的性能指标基线，独创了性能消耗期望与性能消耗恢复期望两项性能容量分析方法。性能消耗期望有助于判定数据库系统性能在某未来时点（一月、半年等）时的性能容量预估值，提前对可能产生的性能容量问题提前预知和准备，对数据库系统问题进行“预先维护”。性能消耗恢复期望有助于帮助生产维护人员对数据库所需资源做出较为精确地调整，在保证数据库性能和资源充足的前提下，减少了不必要的资源浪费，提高资金的使用效率，减少了生产运行成本。

本发明预先设定数据存储装置，其主要完成数据库实例配置信息存储、调度时间表存储、性能指标采集方法存储、采集数据存储、基线存储五大功能。至少包含调度时间表、数据库实例信息表、性能指标定义表、采集异常表、时段基线临时表、性能结果存储集、性能指标基线表、性能指标报警阈值表以及性能消耗增长率存储表。

调度时间表主要包含所需采集性能指标的运行时间，作为采集作业运行的基础，调度时间表至少包含如表1所示的字段：

表1

数据库实例信息表主要包含开放平台所辖各数据库实例基本信息，作为采集队列的生成基础，数据库实例信息表至少包含如表2所示的字段：

表2

性能指标定义表主要包含性能指标的相关定义信息，作为采集作业的实际内容，性能指标定义表至少包含如表3所示的字段：

表3

采集异常表主要包含采集异常的作业的记录，便于分析采集作业的正常完成情况，采集异常表至少包含如表4所示的字段：

表4

时段基线临时表主要包括上一次性能数据采集的时点值信息，用于生成两次性能数据的差值，因此时段基线临时表至少包含如表5所示的字段：

表5

性能结果存储集主要包括每次采集信息的存放工作，由于数据量较大，采用分区表的形式进行，以采集时间作为分区字段。性能结果存储集至少包含如表6所示的字段：

表6

性能指标基线表主要包括根据采集结果更新的现有数据库实例各性能指标的基线值，这些基线值跟随采集结果而发生变化，能够真实地模拟生产环境的负荷，是真实系统性能的最好体现。性能指标基线表应至少包含如表7所示的字段：

表7

性能指标报警阈值表主要包含性能基线与实际采集数据的可波动性关系，其中静态阈值为一固定数值，直接和实际采集数据进行比对，动态阈值为一百分比值，实际采集数据需要和基线与动态阈值的百分比乘积进行比对，如果同时超过静态阈值和动态阈值，则会将此条性能数据输出至性能报警装置005。性能指标报警阈值表应至少包含如表8所示的字段：

表8

性能消耗增长率存储表主要包括性能容量指标在每台服务器上的业务增长修正值，此单元的引入使得性能容量基线能够正确获得未来某一时间的预期值。性能消耗增长率存储表应至少包含如表9所示的字段：

表9

图1为本发明实施例提供的一种数据库系统的性能监控方法的实施方式一的具体流程图，由图1可知，所述的方法具体包括：

S101：获取预先设定的性能指标以及调度时间表。主要完成对于数据采集的控制和采集对象的筛选功能。以调度时间表为基准，对数据采集动作进行控制。该步骤主要用于限定每次性能指标采集的采集范围，包括采集的数据库id和被采集数据库的database link信息。

S102：从目标端数据库系统上按照所述的调度时间表采集所述的性能指标对应的数据。在具体实施方式中，性能指标定义表中存放着性能指标对应查询语句，依次按照调度时间表完成对各目标端数据库实例相应性能指标对应数据的采集。若采集正常，则保存采集结果。如果采集出现异常，则对异常采集信息进行收集，然后存入存储装置相应的采集异常表中。

此步骤在集中采集端轮询发起采集作业，逐一访问各生产数据库环境抓取所需性能容量指标，直至所有环境的指标均被正常采集。

此步骤只返回每次需要采集的范围，不采集的范围不列在其中。如下述表10所示，如果性能指标采集范围为1、3、4数据库，则本步骤应当至少返回下表中粗体标识的3行信息。

表10

dbid	database link
		1	dblink1
2	dblink2
		3	dblink3
4	dblink4

S103：从性能指标报警阈值表中获取预先设定的与所述的目标端数据库系统相对应的静态阈值以及动态阈值；

S104：判断所述的数据是否同时超出所述的静态阈值以及动态阈值；

该步骤可先从性能指标报警阈值表中获取当前性能指标的报警静态与动态报警阈值，然后从性能指标基线表中获取当前性能指标的基线情况，之后从性能结果集中获取最新一次性能数据值，按照如下公式（1），判定是否需要发起一条报警，即是否需要执行步骤S106。

A_lert=(V_alue>TS_upper∪V_alue<TS_lower)∩(V_alue>B_ase|TD_upper∪V_alue<B_ase|TD_lower)   （1）

其中，A_lert表示所述数据同时超出静态阈值以及动态阈值，TS_lower为静态下限阈值，TS_upper为静态上限阈值，TD_lower为动态下限阈值，TD_upper为动态上限阈值，B_ase为存量基线，V_alue为当前采集的所述数据。

此步骤根据已经存储的性能容量指标采集结果进行筛选，对同时超出动态阈值和静态阈值的性能容量指标结果的标识位进行更新，将这些性能“毛刺”排除在性能基线统计范围之外，使得性能基线的生成更加准确，容错性也更强。清除毛刺的存储结果可参照表11所示：

表11

dbid	性能指标	值	是否有效
				4	a2	450	1
4	a2	398	1
				4	a2	12804	0
4	a2	393	1

S105：当判断为否时，根据所述数据的类型统一所述数据的单位；

S106：否则，根据所述的数据生成报警信息。如果采集的性能数据同时超过静态阈值和动态阈值，则说明该数据库的某种性能指标存在问题需要报警。在其他实施方式中，该步骤还包括将所述数据的数据标志位设置为“不纳入基线”，并存储在性能结果存储集中。该步骤主要处理实时采集的性能数据，对异常数据直接发送维护人员形成实时报警，用于处理对实时性要求较高的性能数据，即时将异常结果发送给运行维护人员。

根据所述的数据生成报警信息具体包括：将原始报警信息和数据库实例信息进行关联后生成易于阅读的报警，由原始信息中只包含数据库ID信息，增加了数据库名称，数据库SID和数据库所在服务器IP信息等内容，方便系统维护人员进行查看。未处理的报警信息如表12所示，不易于阅读，所以需要增加上述数据库配置信息，对报警进行封装，封装后的报警至少包含如表13所示的信息。将封装好的报警信息推送给生产运行维护人员，目前采用的方式是通过电子邮件方式进行通知。通过SMTP服务器将报警发送至生产维护人员邮箱，便于生产人员对数据库性能情况做详尽了解。

表12

dbid	性能指标	报警值	增长率
				53	a1	1752.1	330.9%

表13

图2为本发明实施例提供的一种数据库系统的性能监控方法的实施方式二的具体流程图，由图2可知，所述的方法在步骤S101即图2的步骤S201之后还包括：

S202：获取数据库实例信息表以及性能指标定义表；

S203：根据所述的数据库实例信息表以及所述的性能指标定义表筛选出所述的性能指标对应的服务器列表，即以数据库实例信息表以及性能指标定义表为基础，筛选性能指标涉及的服务器列表。

S204：根据所述的服务器列表确定所述的目标端数据库。

图3为图1中的步骤S105的具体流程图，由图3可知，该步骤具体包括：

S301：判断所述的数据是否为时点类数据。按照性能指标的不同，性能数据可分成如下两类：时点性能指标时段性能指标。

S302：当判断为是时，统一所述数据的单位。即对于时点性能指标，对采集的数据的单位进行处理。然后对数据按照性能指标的不同，存储进不同的性能结果存储集中。

S303：当所述的数据为时段类数据时，获取时段基线临时表中预先存储的与所述目标端数据库系统对应的临时数据。此处的临时数据即为上一次性能数据采集的时点值信息。也即时段类数据需要利用时点类数据进行预处理后使用。

S304：确定所述的临时数据与所述数据的差值；

S305：统一所述数据的单位。

S306：当所述的数据为时段类数据时，将所述的时段基线临时表中的临时数据用所述的数据进行替换。

此外，如图1所示，当所述的数据未同时超出所述的静态阈值以及动态阈值时，所述的方法还包括：根据所述的数据更新所述的性能指标对应的基线值。

图4为本发明实施例提供的一种数据库系统的性能监控方法的实施方式三的具体流程图，由图4可知，在实施方式三中，根据所述的数据更新所述的性能指标对应的基线值具体包括：

S407：获取性能指标基线表中预先存储的与所述的性能指标相对应的存量基线；

S408：将所述的数据与所述的存量基线进行线性平均，得到与所述的数据对应的基线值；

S409：将所述的性能指标基线表中的存量基线替换为所述的基线值。

也即在该步骤中，首先摒弃掉性能结果存储集中数据标志位设置为“不纳入基线”的数据，对其他正常数据进行线性平均。对同一时段同一数据库实例的同一指标进行分析。

此步骤将使用已经校准的性能容量指标结果来更新不同时段的性能指标基线，时段划分为按每周不同工作日每10分钟的时段间隔来进行统计，使得基线更为准确，更加真实的反映真实生产环境负载。基线的存储方式如表14所示：

表14

dbid	时间基点	基线值
			1	0:00	21
1	0:10	39
			1	0:20	35
1	…	…
			1	23:50	20
2	0:00	3
			2	0:10	5
2	…	5

图5为本发明实施例提供的一种数据库系统的性能监控方法的实施方式四的具体流程图，由图5可知，在实施方式四中，根据所述的数据更新所述的性能指标对应的基线值具体包括：

S507：获取性能指标基线表中预先存储的与所述的性能指标相对应的存量基线；

S508：将所述的数据与所述的存量基线进行加权平均，得到与所述的数据对应的基线值；

S509：将所述的性能指标基线表中的存量基线替换为所述的基线值。

也即在该步骤中，首先摒弃掉性能结果存储集中数据标志位设置为“不纳入基线”的数据，对其他正常数据进行加权平均。对同一时段同一数据库实例的同一指标进行分析。

在其他实施方式中，还可按照每一次采集的存量来更新性能指标基线表。

图6为本发明实施例提供的一种数据库系统的性能监控方法的实施方式五的具体流程图，该方式中主要按时对基线和本周采样数据进行对比，给出未来一定时间内的性能指标期望值。可预先定制各性能指标期望的时间点，根据性能指标的不同可能定制成每周、每月或每日进行性能期望。由图6可知，在实施方式五中，该方法还包括：

S607：从性能指标基线表中获取预先存储的与所述的性能指标相对应的存量基线；

S608：根据所述的数据以及所述的存量基线确定平均性能日均消耗率。平均性能日均消耗率通过如下公式得到：

现将本日Today的采集值设为V_alueToday，Day日前的采集值设为V_alueDay，当日日均消耗率定义为R_ateToday，平均性能日均消耗率定义为

则有：

$R_{\mathrm{ateToday}}=\frac{V_{\mathrm{alueToday}}-V_{\mathrm{alueDay}}}{\mathrm{Todya}-\mathrm{Day}}$

$R_{\mathrm{ateToday}-1}=\frac{V_{\mathrm{alueToday}-1}-V_{\mathrm{alueDay}-1}}{\mathrm{Today}-\mathrm{Day}}$

$R_{\mathrm{ateToday}-n}=\frac{V_{\mathrm{alueToday}-n}-V_{\mathrm{alueDay}-n}}{\mathrm{Today}-\mathrm{Day}}$

$\stackrel{\&OverBar;}{R_{\mathrm{ate}}}=\frac{{\mathrm{\&Sigma;}}_{i=0}^n{R}_{\mathrm{ateToday}-i}}{n}$

S609：从性能消耗增长率表中获取预先存储的与所述的性能指标相对应的存量增长率。

S610：根据所述的平均性能日均消耗率、所述的数据修正所述的存量增长率，得到性能指标修正值。对性能消耗增长率存储表中的存量增长率进行修正，动态调整性能消耗增长率数据，以反应最新的生产性能数据增长率，算法如下：

假设今日的性能采集值为V_alueToday，将Day日前性能采集值定义为V_{alueToday-Day}，将Day日前预估的今日性能期望值定义为Expe1，平均性能日均消耗率定义为

性能指标修正值为Rev，则有：

$R_{\mathrm{ev}}=\sqrt[\mathrm{Day}]{V_{\mathrm{alueToday}}-\mathrm{Expel}}-\stackrel{\&OverBar;}{R_{\mathrm{ate}}}$

S611：根据所述的平均性能日均消耗率、性能指标修正值、所述的数据确定性能消耗预期。该步骤主要的功能为计算消耗型性能指标在未来的期望值，消耗型性能指标指在生产运行过程中较为恒定，且随着业务量增大而逐渐减少的资源，这些性能指标如表15所示：

表15

消耗型性能指标	注释
		CPU使用率	数据库服务器CPU使用率
内存使用率	数据库服务器内存使用率
		磁盘使用率	数据库服务器磁盘使用率
表空间使用率	数据库表空间使用率
		数据文件数使用率	数据库文件数目占dbfile设置值的比值
数据库序列使用率	数据库sequence使用占sequence最大值的比值

对于以上性能指标，该步骤按周对性能指标增长率进行估算，算法如下：

假设今日的性能采集值为Value，将Day日后性能消耗预期定义为Expe1，性能日均消耗率定义为

性能指标修正值为Rev，则有：

$\mathrm{Expel}=V_{\mathrm{alue}}\&times;{(1+\stackrel{\&OverBar;}{R_{\mathrm{ate}}}+R_{\mathrm{ve}})}^{\mathrm{Day}}$

根据较为准确的性能指标基线信息，对未来一定时间内生产服务器的资源消耗情况进行较为准确的预估。提前反映未来一定时间段内的生产服务器负载信息，拓宽了生产运行维护的宽度和广度。

此外，还可对消耗型性能指标恢复时所需增加的资源项进行期望，根据较为准确的性能指标基线信息，对需要扩充资源的系统，寻找扩充资源量和再次到达报警阈值时间之间的关系，让生产维护人员可以准确的了解扩充后系统需要多长时间才会再次需要扩充，即减少了扩充资源等操作的变更次数，减少风险，又不至于造成生产资源浪费，减少了生产成本。性能消耗恢复期望的具体示例可参照表16所示：

表16

该步骤的主要功能为获取S610的分析结果，让业务增长率成为扩充CPU、内存、磁盘等变更操作的基础，扩充量既满足了业务要求，又不会过多的浪费资源，减少了生产维护成本。

本发明提供的基于动态基线期望的数据库系统性能容量集中采集与分析方法，解决了数据库系统系统性能与容量准确预估的难题，该使用了消耗型性能指标分析方法，并加入了二次修正，使得分析结果更加准确。此外，本系统首次使用了性能消耗恢复期望指标，在对系统所需资源进行提前预判扩充时，可对资源进行更加有效地利用，能够有效地避免资源浪费和资源不足的情况，在保证性能的前提下，尽可能的节省生产成本，减少资源浪费。

图7为本发明实施例提供的一种数据库系统的性能监控装置的实施方式一的结构框图，由图7可知，所述的性能监控装置具体包括：

性能指标及调度时间表获取模块100，用于获取预先设定的性能指标以及调度时间表。主要完成对于数据采集的控制和采集对象的筛选功能。以调度时间表为基准，对数据采集动作进行控制。该步骤主要用于限定每次性能指标采集的采集范围，包括采集的数据库id和被采集数据库的database link信息。

数据采集模块200，用于从目标端数据库系统上按照所述的调度时间表采集所述的性能指标对应的数据。在具体实施方式中，性能指标定义表中存放着性能指标对应查询语句，依次按照调度时间表完成对各目标端数据库实例相应性能指标对应数据的采集。若采集正常，则保存采集结果。如果采集出现异常，则对异常采集信息进行收集，然后存入存储装置相应的采集异常表中。

此步骤在集中采集端轮询发起采集作业，逐一访问各生产数据库环境抓取所需性能容量指标，直至所有环境的指标均被正常采集。

此步骤只返回每次需要采集的范围，不采集的范围不列在其中。如下述表10所示，如果性能指标采集范围为1、3、4数据库，则本步骤应当至少返回下表中粗体标识的3行信息。

静态阈值及动态阈值获取模块300，用于从性能指标报警阈值表中获取预先设定的与所述的目标端数据库系统相对应的静态阈值以及动态阈值；

第一判断模块400，用于判断所述的数据是否同时超出所述的静态阈值以及动态阈值。该模块可先从性能指标报警阈值表中获取当前性能指标的报警静态与动态报警阈值，然后从性能指标基线表中获取当前性能指标的基线情况，之后从性能结果集中获取最新一次性能数据值，按照如下公式（1），判定是否需要发起一条报警。

第一处理模块500，用于当所述的第一判断模块判断为否时，根据所述数据的类型统一所述数据的单位；

第二处理模块600，用于当所述的第一判断模块判断为否时，根据所述的数据生成报警信息。如果采集的性能数据同时超过静态阈值和动态阈值，则说明该数据库的某种性能指标存在问题需要报警。在其他实施方式中，该步骤还包括将所述数据的数据标志位设置为“不纳入基线”，并存储在性能结果存储集中。该步骤主要处理实时采集的性能数据，对异常数据直接发送维护人员形成实时报警，用于处理对实时性要求较高的性能数据，即时将异常结果发送给运行维护人员。

根据所述的数据生成报警信息具体包括：将原始报警信息和数据库实例信息进行关联后生成易于阅读的报警，由原始信息中只包含数据库ID信息，增加了数据库名称，数据库SID和数据库所在服务器IP信息等内容，方便系统维护人员进行查看。未处理的报警信息如表12所示，不易于阅读，所以需要增加上述数据库配置信息，对报警进行封装，封装后的报警至少包含如表13所示的信息。将封装好的报警信息推送给生产运行维护人员，目前采用的方式是通过电子邮件方式进行通知。通过SMTP服务器将报警发送至生产维护人员邮箱，便于生产人员对数据库性能情况做详尽了解。

图8为本发明实施例提供的一种数据库系统的性能监控装置的实施方式二的结构框图，由图8可知，所述的装置还包括：

数据库实例信息表获取模块700，用于获取数据库实例信息表以及性能指标定义表；

筛选模块800，用于根据所述的数据库实例信息表以及所述的性能指标定义表筛选出所述的性能指标对应的服务器列表，即以数据库实例信息表以及性能指标定义表为基础，筛选性能指标涉及的服务器列表；

目标端数据库确定模块900，用于根据所述的服务器列表确定所述的目标端数据库。

图9为图7中的第一处理模块500的具体结构框图，由图9可知，第一处理模块具体包括：

判断单元501，用于判断所述的数据是否为时点类数据；按照性能指标的不同，性能数据可分成如下两类：时点性能指标时段性能指标。

第一处理单元502，用于当所述的判断单元判断为是时，统一所述数据的单位。即对于时点性能指标，对采集的数据的单位进行处理。然后对数据按照性能指标的不同，存储进不同的性能结果存储集中。

第二处理单元503，用于当所述的数据为时段类数据时，获取时段基线临时表中预先存储的与所述目标端数据库系统对应的临时数据。此处的临时数据即为上一次性能数据采集的时点值信息。也即时段类数据需要利用时点类数据进行预处理后使用。

差值确定单元504，用于确定所述的临时数据与所述数据的差值；

单位统一单元505，用于统一所述数据的单位。

此外，第一处理模块还包括：数据替换单元506，当所述的数据为时段类数据时，将所述的时段基线临时表中的临时数据用所述的数据进行替换。

基线值更新单元507，用于当所述的数据未同时超出所述的静态阈值以及动态阈值时，将所述的时段基线临时表中的临时数据用所述的数据进行替换。

图10为本发明实施例提供的一种数据库系统的性能监控装置中基线值更新单元的实施方式一的结构框图，由图10可知，所述基线值更新单元具体包括：

存量基线获取单元5071，用于获取性能指标基线表中预先存储的与所述的性能指标相对应的存量基线；

线性平均单元5072，用于将所述的数据与所述的存量基线进行线性平均，得到与所述的数据对应的基线值；

替换单元5073，用于将所述的性能指标基线表中的存量基线替换为所述的基线值。

也即在该单元中，首先摒弃掉性能结果存储集中数据标志位设置为“不纳入基线”的数据，对其他正常数据进行线性平均。对同一时段同一数据库实例的同一指标进行分析。

此单元将使用已经校准的性能容量指标结果来更新不同时段的性能指标基线，时段划分为按每周不同工作日每10分钟的时段间隔来进行统计，使得基线更为准确，更加真实的反映真实生产环境负载。基线的存储方式如表14所示。

图11为本发明实施例提供的一种数据库系统的性能监控装置中基线值更新单元的实施方式二的结构框图，由图11可知，所述基线值更新单元还包括：

加权平均单元5074，用于将所述的数据与所述的存量基线进行加权平均，得到与所述的数据对应的基线值。

也即在该单元中，首先摒弃掉性能结果存储集中数据标志位设置为“不纳入基线”的数据，对其他正常数据进行加权平均。对同一时段同一数据库实例的同一指标进行分析。

在其他实施方式中，还可按照每一次采集的存量来更新性能指标基线表。

图12为本发明实施例提供的一种数据库系统的性能监控装置的实施方式五的结构框图，该方式中主要按时对基线和本周采样数据进行对比，给出未来一定时间内的性能指标期望值。可预先定制各性能指标期望的时间点，根据性能指标的不同可能定制成每周、每月或每日进行性能期望。由图12可知，在实施方式五中，该装置还包括：

获取模块1000，用于从性能指标基线表中获取预先存储的与所述的性能指标相对应的存量基线；

平均性能日均消耗率确定模块1100，用于根据所述的数据以及所述的存量基线确定平均性能日均消耗率；

存量增长率获取模块1200，用于从性能消耗增长率表中获取预先存储的与所述的性能指标相对应的存量增长率；

性能指标修正值确定模块1300，用于根据所述的平均性能日均消耗率、所述的数据修正所述的存量增长率，得到性能指标修正值。对性能消耗增长率存储表中的存量增长率进行修正，动态调整性能消耗增长率数据，以反应最新的生产性能数据增长率。

1400，用于根据所述的平均性能日均消耗率、性能指标修正值、所述的数据确定性能消耗预期。该模块主要的功能为计算消耗型性能指标在未来的期望值，消耗型性能指标指在生产运行过程中较为恒定，且随着业务量增大而逐渐减少的资源。根据较为准确的性能指标基线信息，对未来一定时间内生产服务器的资源消耗情况进行较为准确的预估。提前反映未来一定时间段内的生产服务器负载信息，拓宽了生产运行维护的宽度和广度。

此外，还可对消耗型性能指标恢复时所需增加的资源项进行期望，根据较为准确的性能指标基线信息，对需要扩充资源的系统，寻找扩充资源量和再次到达报警阈值时间之间的关系，让生产维护人员可以准确的了解扩充后系统需要多长时间才会再次需要扩充，即减少了扩充资源等操作的变更次数，减少风险，又不至于造成生产资源浪费，减少了生产成本

目前已经利用本发明，对生产性能指标进行了监控与分析，包括DatabaseTime性能指标，数据库表空间容量预测，数据库数据文件数量指标，数据库段容量指标，数据库失效对象指标，数据库非默认参数指标，数据库序列上限预警等。在生产运行维护中起到了良好的效果。

综上所述，本发明提供了一种数据库系统的性能监控方法以及装置，通过对系统性能指标的建模和基线收集，达到精算每月每日的性能改变或资源消耗，以达到精确判定未来性能容量占用趋势的目的，其优势在于：

1、本发明对于个性化性能容量指标的添加存在优势，可以任意自定义数据库性能容量指标并纳入采集队列。

2、本发明无需在生产服务器部署任何脚本或代理程序，减少了对生产系统的改造成本和安全风险系数。本发明在数据采集时对生产系统的性能影响很小。

3、本发明在投入使用之后，利用独创的性能消耗恢复期望，有效地减少了频繁扩充系统资源等变更操作，降低了生产变更风险。同时较为准确的预估了生产系统的性能消耗水平，避免了因资源扩充过度而造成的资源浪费，有效降低了生产成本。同时也因集中式的性能容量指标采集，为生产维护人员节省了维护时间，降低了生产运维成本。

4、本发明能够有效防范商业银行系统由于业务量的增长而导致各种容量不足，并且能够减少因过度扩充资源导致的资源浪费和企业生产成本上涨问题，以上两点对于能进一步提升我行在众多商业银行中的竞争力，避免了因性能容量不足或过剩而带来的经济损失，为采集与分析性能容量的通用性方法做了较为有益的探索与尝试。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一般计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-OnlyMemory，ROM）或随机存储记忆体（Random Access Memory，RAM）等。

本领域技术人员还可以了解到本发明实施例列出的各种功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。

本发明中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (18)

1.一种数据库系统的性能监控方法，其特征是，所述的性能监控方法包括：

获取预先设定的性能指标以及调度时间表；

从目标端数据库系统上按照所述的调度时间表采集所述的性能指标对应的数据；

从性能指标报警阈值表中获取预先设定的与所述的目标端数据库系统相对应的静态阈值以及动态阈值；

判断所述的数据是否同时超出所述的静态阈值以及动态阈值；

当判断为否时，根据所述数据的类型统一所述数据的单位；

否则，根据所述的数据生成报警信息。

2.根据权利要求1所述的性能监控方法，其特征是，所述的性能监控方法还包括：

获取数据库实例信息表以及性能指标定义表；

根据所述的数据库实例信息表以及所述的性能指标定义表筛选出所述的性能指标对应的服务器列表；

根据所述的服务器列表确定所述的目标端数据库。

3.根据权利要求1所述的性能监控方法，其特征是，根据所述数据的类型统一所述数据的单位具体包括：

判断所述的数据是否为时点类数据；

当判断为是时，统一所述数据的单位；

当所述的数据为时段类数据时，获取时段基线临时表中预先存储的与所述目标端数据库系统对应的临时数据；

确定所述的临时数据与所述数据的差值；

统一所述数据的单位。

4.根据权利要求3所述的性能监控方法，其特征是，所述的性能监控方法还包括：

当所述的数据为时段类数据时，将所述的时段基线临时表中的临时数据用所述的数据进行替换。

5.根据权利要求1所述的性能监控方法，其特征是，所述的性能监控方法还包括：

当所述的数据未同时超出所述的静态阈值以及动态阈值时，根据所述的数据更新所述的性能指标对应的基线值。

6.根据权利要求5所述的性能监控方法，其特征是，根据所述的数据更新所述的性能指标对应的基线值具体包括：

获取性能指标基线表中预先存储的与所述的性能指标相对应的存量基线；

将所述的数据与所述的存量基线进行线性平均，得到与所述的数据对应的基线值；

将所述的性能指标基线表中的存量基线替换为所述的基线值。

7.根据权利要求5所述的性能监控方法，其特征是，根据所述的数据更新所述的性能指标对应的基线值具体包括：

获取性能指标基线表中预先存储的与所述的性能指标相对应的存量基线；

将所述的数据与所述的存量基线进行加权平均，得到与所述的数据对应的基线值；

将所述的性能指标基线表中的存量基线替换为所述的基线值。

8.根据权利要求1所述的性能监控方法，其特征是，所述的性能监控方法还包括：

从性能指标基线表中获取预先存储的与所述的性能指标相对应的存量基线；

根据所述的数据以及所述的存量基线确定平均性能日均消耗率；

从性能消耗增长率表中获取预先存储的与所述的性能指标相对应的存量增长率；

根据所述的平均性能日均消耗率、所述的数据修正所述的存量增长率，得到性能指标修正值。

9.根据权利要求8所述的性能监控方法，其特征是，所述的性能监控方法还包括：

根据所述的平均性能日均消耗率、性能指标修正值、所述的数据确定性能消耗预期。

10.一种数据库系统的性能监控装置，其特征是，所述的性能监控装置包括：

性能指标及调度时间表获取模块，用于获取预先设定的性能指标以及调度时间表；

数据采集模块，用于从目标端数据库系统上按照所述的调度时间表采集所述的性能指标对应的数据；

静态阈值及动态阈值获取模块，用于从性能指标报警阈值表中获取预先设定的与所述的目标端数据库系统相对应的静态阈值以及动态阈值；

第一判断模块，用于判断所述的数据是否同时超出所述的静态阈值以及动态阈值；

第一处理模块，用于当所述的第一判断模块判断为否时，根据所述数据的类型统一所述数据的单位；

第二处理模块，用于当所述的第一判断模块判断为否时，根据所述的数据生成报警信息。

11.根据权利要求10所述的性能监控装置，其特征是，所述的性能监控装置还包括：

数据库实例信息表获取模块，用于获取数据库实例信息表以及性能指标定义表；

筛选模块，用于根据所述的数据库实例信息表以及所述的性能指标定义表筛选出所述的性能指标对应的服务器列表；

目标端数据库确定模块，用于根据所述的服务器列表确定所述的目标端数据库。

12.根据权利要求10所述的性能监控装置，其特征是，所述的第一处理模块具体包括：

判断单元，用于判断所述的数据是否为时点类数据；

第一处理单元，用于当所述的判断单元判断为是时，统一所述数据的单位；

第二处理单元，用于当所述的数据为时段类数据时，获取时段基线临时表中预先存储的与所述目标端数据库系统对应的临时数据；

差值确定单元，用于确定所述的临时数据与所述数据的差值；

单位统一单元，用于统一所述数据的单位。

13.根据权利要求12所述的性能监控装置，其特征是，所述的第一处理模块还包括：

数据替换单元，用于当所述的数据为时段类数据时，将所述的时段基线临时表中的临时数据用所述的数据进行替换。

14.根据权利要求10所述的性能监控装置，其特征是，所述的第一处理模块还包括：

基线值更新单元，用于当所述的数据未同时超出所述的静态阈值以及动态阈值时，根据所述的数据更新所述的性能指标对应的基线值。

15.根据权利要求14所述的性能监控装置，其特征是，所述的基线值更新单元具体包括：

存量基线获取单元，用于获取性能指标基线表中预先存储的与所述的性能指标相对应的存量基线；

线性平均单元，用于将所述的数据与所述的存量基线进行线性平均，得到与所述的数据对应的基线值；

替换单元，用于将所述的性能指标基线表中的存量基线替换为所述的基线值。

16.根据权利要求14所述的性能监控装置，其特征是，所述的基线值更新单元具体包括：

存量基线获取单元，用于获取性能指标基线表中预先存储的与所述的性能指标相对应的存量基线；

加权平均单元，用于将所述的数据与所述的存量基线进行加权平均，得到与所述的数据对应的基线值；

替换单元，用于将所述的性能指标基线表中的存量基线替换为所述的基线值。

17.根据权利要求10所述的性能监控装置，其特征是，所述的性能监控装置还包括：

获取模块，用于从性能指标基线表中获取预先存储的与所述的性能指标相对应的存量基线；

平均性能日均消耗率确定模块，用于根据所述的数据以及所述的存量基线确定平均性能日均消耗率；

存量增长率获取模块，用于从性能消耗增长率表中获取预先存储的与所述的性能指标相对应的存量增长率；

性能指标修正值确定模块，用于根据所述的平均性能日均消耗率、所述的数据修正所述的存量增长率，得到性能指标修正值。

18.根据权利要求17所述的性能监控装置，其特征是，所述的性能监控装置还包括：

性能消耗预期模块，用于根据所述的平均性能日均消耗率、性能指标修正值、所述的数据确定性能消耗预期。

Images