CN106293941B

CN106293941B - 一种数据库系统资源的分配方法

Info

Publication number: CN106293941B
Application number: CN201610645323.5A
Authority: CN
Inventors: 程永新; 孙玉颖; 孙田
Original assignee: Shanghai New Torch Network Information Technology Ltd By Share Ltd
Current assignee: Shanghai New Torch Network Information Technology Ltd By Share Ltd
Priority date: 2016-08-09
Filing date: 2016-08-09
Publication date: 2019-12-31
Anticipated expiration: 2036-08-09
Also published as: CN106293941A

Abstract

本发明公开了一种数据库系统资源的分配方法，包括如下步骤：a)定时采集数据库系统资源使用情况；b)提取CPU及IO使用情况指标，并为每月同一天的系统资源消耗以及每天同一时间的系统资源消耗建立系统快照；c)通过每月同一天，每天同一时间快照比对，估算出未来时间片里系统的空闲资源及空闲时长；d)建立队列任务，并在估算出的空闲时长内选取执行匹配的任务。本发明提供的数据库系统资源的分配方法，自动对系统的空闲资源以及任务占用的系统资源进行估算，通过在估算出的空闲时长内选取执行匹配的任务，能够更加合理的利用系统资源，大大提高了系统资源的利用率。

Description

一种数据库系统资源的分配方法

技术领域

本发明涉及一种计算机系统资源的分配方法，尤其涉及一种数据库系统资源的分配方法。

背景技术

信息技术已成为电信行业至关重要的一种生产力，海量信息的管理和运营需要强大的业务系统支撑。业务系统的稳定性会直接影响到客户的信任度和满意度，如何掌握数据库资源使用规律，合理有效地利用空闲时段，缓解业务高峰，是业务支撑部门一项十分重要的职责。

现有技术中，系统资源的分配方法主要有如下两种：

1)、通过系统或数据库的定时任务实现。DBA根据经验判断，某时段较为空闲，剩余资源可以执行某任务，于是将该任务以指定时间执行的方式配置到定时任务中，由系统或数据库调度。

2)、手工执行，DBA发现数据库目前较为空闲，于是手工启动任务并值守至其结束，有业务高峰，数据库压力较大时，需要杀死任务进程，以确保业务处理进程能获得所需资源。

现有技术存在以下缺点：

1)、方法一依赖于DBA长期积累的维护经验，且无法预估和处理突发情况，如在执行某任务时，应用系统业务突增，导致数据库资源争用。或者数据库业务骤减，当时却并没有配置定时任务执行，导致数据库资源浪费。

2)、方法二需要人工值守，依赖于DBA的技术水平及判断，被杀死的任务进程需回滚，下次启动时无法从断点继续执行，容易造成数据状态不一致等问题。

发明内容

本发明所要解决的技术问题是提供一种数据库系统资源的分配方法，能够自动对系统的空闲资源以及任务占用的系统资源进行估算，使得系统在空闲时调用合适的任务运行，对空闲资源以及任务占用资源的估算更加准确，能够更加合理的利用系统资源，大大提高了系统资源的利用率。

本发明为解决上述技术问题而采用的技术方案是提供一种数据库系统资源的分配方法，包括如下步骤：a)定时采集数据库系统资源使用情况；b)提取CPU及IO使用情况指标，并为每月同一天的系统资源消耗以及每天同一时间的系统资源消耗建立系统快照；c)通过每月同一天，每天同一时间快照比对，估算出未来时间片里系统的空闲资源及空闲时长；d)建立队列任务，并在估算出的空闲时长内选取执行匹配的任务。

上述的数据库系统资源的分配方法，其中，所述步骤c)通过连续的快照得出系统资源消耗变化趋势，估算过程如下：

某时段CPU使用情况预估计算公式为：

fc＝(c₁+c₂+c₃+....+c_n)/n

某时段IO使用情况预估计算公式为：

fp＝(p₁+p₂+p₃+....+p_n)/n

其中n为采集天数,c_n为第N天该时段快照中CPU使用率，p_n为第N天该时段快照中IO量；

当前空闲CPU时间的计算公式为：

c＝c1/c2×(100-R-c1)

其中c1为当前系统CPU使用百分比，c2为数据库CPU的时间，R为系统CPU预留百分比常量；

当前空闲IO的计算公式为：

p＝p1/p2×(R-p1)

其中p1为当前系统IO使用量，p2为数据库物理读使用量，R为系统IO最大值。

上述的数据库系统资源的分配方法，其中，所述步骤d)将关键业务作为一个任务，建立关键业务流程的SQL性能基线，并通过数据采集不断校正基线，使SQL语句与业务流程双向直接关联，通过定时监测SQL语句的性能对业务性能进行监测和评估。

上述的数据库系统资源的分配方法，其中，所述步骤a)定时从数据库动态性能视图中采集SQL的性能数据，所述步骤d)基于采集到的SQL性能数据建立队列任务基线库，对于未在基线库中的业务SQL，推送到未绑定业务标签列表，由业务人员打上业务标签，再回存到基线库；对于已存在基线库的业务SQL，根据采集到的SQL性能数据，与基线库中的对应的已存在SQL性能数据相对比，如果性能变化未超出指定阀值，则校正基线，否则，如果性能变化超出指定阀值，则发出性能预警。

上述的数据库系统资源的分配方法，其中，所述基线库中设置的基线包括SQL性能指标、SQL消耗增长指标以及业务关联指标。

上述的数据库系统资源的分配方法，其中，所述SQL性能指标包括CPU时间/次，执行时间/次，逻辑读/次，物理读/次和频次，所述SQL性能指标通过采集提取数据库动态性能视图获得，所述数据库动态性能视图包括V$SQL、V$SQL_PLAN和V$SQLARER；所述SQL消耗增长指标包括CPU时间增长率、执行时间增长率、逻辑读增长率、物理读增长率和频次增长率。

上述的数据库系统资源的分配方法，其中，还包括根据业务关联指标基线判断SQL对应的业务模块是否属于关键业务，若属于关键业务，则建立或校正队列任务基线库，若不属于关键业务，则建立或校正应用基线库。

上述的数据库系统资源的分配方法，其中，所述业务关联指标包括业务模块、上线时间、最新版本以及最后更新时间。

上述的数据库系统资源的分配方法，其中，还包括将任务在队列中按照基线库中采集的系统资源消耗进行排序，按照估算出的空闲时长及空闲资源在队列中提取匹配任务，如果没有匹配任务则进行下一次定时采集。

上述的数据库系统资源的分配方法，其中，启动队列中的匹配任务之后，当预知范围外的应用高峰到来时，将正在执行的队列任务暂停，保存进程的中间状态，释放进程资源，产生断点，等待下一次的任务匹配；当监控到系统高峰过后，重新按照估算出的空闲时长及空闲资源在队列中提取匹配任务，如果匹配任务有断点，进行任务恢复，从断点恢复资源，任务继续执行。

本发明对比现有技术有如下的有益效果：本发明提供的数据库系统资源的分配方法，自动对系统的空闲资源以及任务占用的系统资源进行估算，通过在估算出的空闲时长内选取执行匹配的任务，能够更加合理的利用系统资源，大大提高了系统资源的利用率。

附图说明

图1为本发明数据库系统资源的分配流程示意图；

图2为本发明的数据库系统一天内系统CPU及IO使用分配示意图；

图3为本发明的数据库系统一月内同一时段内系统CPU及IO使用分配示意图；

图4为本发明的队列任务基线的简历和校正流程示意图；

图5为本发明的数据库系统优选前的CPU及IO使用分配示意图；

图6为本发明的数据库系统优选后的CPU及IO使用分配示意图；

图7为本发明的队列任务动态匹配调度流程示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的描述。

本发明提供的数据库系统资源的分配方法，包括如下步骤：

a)定时采集数据库系统资源使用情况；

b)提取CPU及IO使用情况指标，并为每月同一天的系统资源消耗以及每天同一时间的系统资源消耗建立系统快照；

c)通过每月同一天，每天同一时间快照比对，估算出未来时间片里系统的空闲资源及空闲时长；

d)建立队列任务，并在估算出的空闲时长内选取执行匹配的任务。

下面对本发明的主要步骤进行详细展开描述。

一、空闲系统资源评估

本流程执行步骤如图1所示，主要包括：采集层中配置定时任务，对系统性能做定时采集，提取CPU及IO使用情况指标，并为每月同一天的系统资源消耗以及每天同一时间的系统资源消耗建立系统快照，根据与每月同一天，每天同一时间快照相比对，得出系统消耗规律，并在结果层中进行系统消耗周期性预估，估算出未来时间片里，系统的空闲资源及时长。

1.系统消耗规律监控

系统消耗趋势图(一天内各时段和一月内同一时段)，见图2和图3。通过连续的快照可得出以上的趋势图，并预估未来某时段资源使用情况及时长。

某时段CPU使用情况预估计算公式为：

fc＝(c₁+c₂+c₃+....+c_n)/n

某时段IO使用情况预估计算公式为：

fp＝(p₁+p₂+p₃+....+p_n)/n

其中n为采集天数,cn为第N天该时段快照中CPU使用率，pn为第N天该时段快照中IO量。

2.空闲资源评估

当前空闲CPU time的计算公式为：

c＝c1/c2×(100-R-c1)

其中c1为当前系统CPU使用百分比，c2为数据库CPU的时间，R为系统CPU预留百分比常量，值为15。

当前空闲IO的计算公式为：

p＝p1/p2×(R-p1)

其中p1为当前系统IO使用，p2为数据库物理读使用量，R为系统IO最大值。

二、任务队列的建立

在本流程中，将关键业务作为一个任务，通过建立每个任务的性能指标基线，对每个任务需占用的资源进行评估，并建立任务队列。

1.关键业务性能基线建立和校正总流程

业务流程的执行，即是数据交互的过程，业务性能问题常常出现在数据交互的环节，即性能问题比较高频率的发生在数据库上。因此，从数据库层面出发，建立关键业务流程的SQL性能基线，并通过数据采集不断校正基线，使SQL语句与业务流程双向直接关联，通过定时监测SQL语句的性能来对业务性能进行监测和评估。基线建立以及校正流程如图4所示：

1)在采集层中配置定时任务，定时从数据库动态性能视图(V$SQL、V$SQL_PLAN等)采集SQL的性能数据，并提取SQL性能指标；

2)对于未在基线库中的业务SQL，推送到未绑定业务标签列表，由业务人员打上业务标签，再回存到基线库，即基于采集到的SQL性能数据建立基线库；

3)对于已存在基线库的业务SQL，根据采集到的SQL性能数据，与基线库中的对应的已存在SQL性能数据相对比，针对相关SQL性能指标进行增长率计算，如果性能变化未超出指定阀值(如正负偏离在1％以内)，则校正基线，否则，如果性能变化超出指定阀值，则发出性能预警；

4)判断SQL对应的业务模块是否属于关键业务，若属于关键业务，则建立或校正结果层中的队列任务基线库，若不属于关键业务，则建立或校正结果层中的应用基线库。

进一步地，上述关键业务的基线涉及到如下三类指标：

SQL性能指标：SQL性能指标均存在基线，在上述步骤1)中，从数据库中定时采集SQL性能指标，主要从V$SQL、V$SQLAREA等动态性能视图里面获取、计算。如SQL未在基线库中，则将首次采集到的信息作为基线，记录到基线库。

SQL消耗增长指标：因为考虑到业务的变化，如相关业务表的数据量、功能模块的访问量，需要定期的对基线进行校正，该指标用于基线校正。在基线建立之初为空，在上述步骤3)中，通过计算本次得到的各性能指标值与已有基线中的对应的各性能指标值的差值得到SQL消耗增长指标，并根据SQL消耗增长指标对基线进行校正。

业务关联指标：需要业务人员手工填写。在上述步骤4)中，通过业务关联指标确定采集的SQL对应的业务是否为关键业务。一般在装置上线后，批量初始化，对后期新增的SQL(如业务变更、新增业务等)则手工增量追加填写即可。对于稳定的业务系统，一般后期需要追加填写的情况比较少见。

2.关键业务基线中SQL消耗增长指标的确定方法

建立基表，保存SQL性能指标每小时统计的性能信息快照，计算每日同时的环比增长(例如每日的下午5点各性能指标的变化)。将每日采集的性能信息快照汇总，计算与历史表中每月同日环比增长(例如每月1日各性能指标的变化)，更新基线库中SQL消耗增长指标。

1)频次指标基线修正

频次增长率的计算方法为：

gr＝freq/freq’

其中freq为当日快照中该SQL频次的值，freq’为上月同日快照中该SQL频次的值。

基线库中，修正频次增长指标的计算方法为：

其中freq为当日快照中频次的值，freq1为前一月当日快照中频次的值,freq2为前两月当日快照中频次的值，以此类推，n为快照的样本数。

2)消耗指标基线修正

消耗指标分为CPU时间指标、执行时间指标、逻辑读指标和物理读指标四种。

以CPU时间为例，增长率的计算方法为：

gr＝(cp×freq)/(cp’×freq’)

其中cp和freq分别为当日快照中每次执行所用cpu_time的值和频次的值，cp’和freq’分别为上月同日快照中每次执行所用cpu_time的值和频次的值。

基线库中，修正CPU增长指标计算方法为：

其中cp和freq分别为当日快照中每次执行所用cpu_time的值和频次的值，cp1和freq1分别为前一月同日快照中每次执行所用cpu_time的值和频次的值,cp2和freq2分别为前两月同日快照中每次执行所用cpu_time的值和频次的值，以此类推，n为快照的样本数。

图5为本发明的数据库系统优选前的CPU及IO使用分配示意图；图6为本发明的数据库系统优选后的CPU及IO使用分配示意图。

请继续参见图5和图6，采用本发明资源分配方法动态分配资源后效果比对，经过动态调度，使系统资源得到合理利用，系统运行状态平稳，较少出现峰值。

1)避免了对于DBA经验的依赖，无需指定队列任务的具体执行时间，将控制权交由本装置自动根据当前系统负载情况自动调度。使系统既不会过于繁忙，也不会过于空闲，合理地利用空闲时段运行队列任务，规避了应用高峰期资源争用的问题。提高了系统的可维护性和高可用性。

2)启动队列任务之后，当预知范围外的应用高峰到来时，能保存进程的中间状态，释放进程资源，产生断点。当监控到系统高峰过后，从断点恢复资源，任务继续执行。避免了资源的浪费，提高了系统的利用率。

3)定时采集业务模块及任务的资源消耗，能清晰的知道系统的关键业务占用资源比重，为业务逻辑检查，系统拆分提供有力依据。

4)能够评估队列任务的精确消耗，确保执行时不会超过系统的最高负载，有效地避免了此类故障。

本发明根据关键业务所占资源比重，建立任务队列，实现了SQL与关键业务模块的双向联动，依赖建立的强大的基线库，根据SQL性能指标，分析出各关键业务占用的数据库资源(CPU、物理读、逻辑读等指标均可)比重。以某CRM核心业务系统的数据库资源占用分析结果为例，工单管理、短信下发、空中充值、服务状态变更四个业务模块占用了较多的数据库CPU资源和IO资源。

进一步地，通过系统的关键业务占用资源比重，还可以确定各关键业务占用比重是否合理，对于业务实际使用与资源占用不合理的业务模块，可以从业务出发，成立专题，重新梳理业务流程，并进行优化。对于占用资源比重超过预设阀值的关键业务，可以将该关键业务独立出业务系统单独运行，独立出业务系统能极大地解决负载过高的情况，但是需要额外地投入硬件资源，接口传输代价等，故拆分的决策需要长时间的数据支持。本发明能很好的为此决策提供支撑，当采集到业务系统消耗占比极大，且系统负载持续过高的情况，为业务系统拆分的提供依据。

另外，还可根据快照库，分析某一个业务模块的资源占比变化，对于资源占比增长较快的业务模块，可以成立专题分析，避免滚雪球式的性能问题发生；并可通过可视化的资源比重模型，进一步加强了业务性能的管理。

本发明根据关键业务所占资源比重，建立各关键业务对应的任务的任务队列，当确定出系统资源空闲时间时，根据在该时间空闲出的系统资源大小，从任务队列中确定与该资源大小匹配的任务，并在系统空闲时间运行该任务。具体流程如图7所示。

1)根据定时采集的系统CPU和IO指标进行空闲资源评估，如果系统负载较轻，凭借上面提及流程进行系统消耗周期性预估。

2)将任务在队列中按照基线库中采集的消耗进行排序，按照系统消耗周期性预估中的消耗及时长在队列中提取匹配任务。如果没有匹配任务则进行下一次定时采集。

3)如果匹配任务有断点，即代表曾经执行过，进行任务恢复。如果没有断点则直接启动任务。

4)如果判断系统负载过高，为了保证高优先级的应用正常运行，将正在执行的队列任务暂停，保存中间状态，释放系统资源。

虽然本发明已以较佳实施例揭示如上，然其并非用以限定本发明，任何本领域技术人员，在不脱离本发明的精神和范围内，当可作些许的修改和完善，因此本发明的保护范围当以权利要求书所界定的为准。

Claims

1.一种数据库系统资源的分配方法，其特征在于，包括如下步骤：

a）定时采集数据库系统资源使用情况；

b）提取CPU及IO使用情况指标，并为每月同一天的系统资源消耗以及每天同一时间的系统资源消耗建立系统快照；

c）通过每月同一天，每天同一时间快照比对，估算出未来时间片里系统的空闲资源及空闲时长；

d）建立队列任务，并在估算出的空闲时长内选取执行匹配的任务；

所述步骤c）通过连续的快照得出系统资源消耗变化趋势，估算过程如下：

某时段CPU使用情况预估计算公式为：

fc=(c₁+c₂+c₃+....+c_n)/n

某时段IO使用情况预估计算公式为：

fp=(p₁+p₂+p₃+....+p_n)/n

其中n为采集天数,c_n为第N天同一时段快照中CPU使用率，p_n为第N天同一时段快照中IO量；

当前空闲CPU 时间的计算公式为：

c=c1/c2×(100-R-c1)

当前空闲IO的计算公式为：

p=p1/p2×(R-p1)

其中p1为当前系统IO使用量，p2为数据库物理读使用量，R为系统IO最大值；

所述步骤d）将关键业务作为一个任务，建立关键业务流程的SQL性能基线，并通过数据采集不断校正基线，使SQL语句与业务流程双向直接关联，通过定时监测SQL语句的性能对业务性能进行监测和评估；

所述步骤a）定时从数据库动态性能视图中采集SQL的性能数据，所述步骤d）基于采集到的SQL性能数据建立队列任务基线库，对于未在基线库中的业务SQL，推送到未绑定业务标签列表，由业务人员打上业务标签，再回存到基线库；对于已存在基线库的业务SQL，根据采集到的SQL性能数据，与基线库中的对应的已存在SQL性能数据相对比，如果性能变化未超出指定阀值，则校正基线，否则，如果性能变化超出指定阀值，则发出性能预警。

2.如权利要求1所述的数据库系统资源的分配方法，其特征在于，所述基线库中设置的基线包括SQL性能指标、SQL消耗增长指标以及业务关联指标。

3.如权利要求2所述的数据库系统资源的分配方法，其特征在于，所述SQL性能指标包括CPU时间/次，执行时间/次，逻辑读/次，物理读/次和频次，所述SQL性能指标通过采集提取数据库动态性能视图获得，所述数据库动态性能视图包括V$SQL、V$SQL_PLAN和V$SQLARER；所述SQL消耗增长指标包括CPU时间增长率、执行时间增长率、逻辑读增长率、物理读增长率和频次增长率。

4.如权利要求2所述的数据库系统资源的分配方法，其特征在于，还包括根据业务关联指标基线判断SQL对应的业务模块是否属于关键业务，若属于关键业务，则建立或校正队列任务基线库，若不属于关键业务，则建立或校正应用基线库。

5.如权利要求4所述的数据库系统资源的分配方法，其特征在于，所述业务关联指标包括业务模块、上线时间、最新版本以及最后更新时间。

6.如权利要求1所述的数据库系统资源的分配方法，其特征在于，还包括将任务在队列中按照基线库中采集的系统资源消耗进行排序，按照估算出的空闲时长及空闲资源在队列中提取匹配任务，如果没有匹配任务则进行下一次定时采集。

7.如权利要求6所述的数据库系统资源的分配方法，其特征在于，启动队列中的匹配任务之后，当预知范围外的应用高峰到来时，将正在执行的队列任务暂停，保存进程的中间状态，释放进程资源，产生断点，等待下一次的任务匹配；当监控到系统高峰过后，重新按照估算出的空闲时长及空闲资源在队列中提取匹配任务，如果匹配任务有断点，进行任务恢复，从断点恢复资源，任务继续执行。