数据库资源池分配方法、装置、设备、介质及程序产品

本申请涉及云平台技术领域，尤其涉及一种数据库资源池分配方法、装置、设备、介质及程序产品。

随着云计算快速发展，应用系统集、租户规模越来越大，对数据库资源池需求的复杂程度呈日益增长的趋势。现有的技术方案中，为了实现数据库资源池分配，主要是通过人工判断或是随机分配的方式，导致资源分配不均衡。

上述内容仅用于辅助理解本申请的技术方案，并不代表承认上述内容是现有技术。

本申请的主要目的在于提供一种数据库资源池分配方法、装置、设备、介质及程序产品，旨在解决相关技术中对数据库资源池分配不均衡的技术问题。

为实现上述目的，本申请的实施例提供一种数据库资源池分配方法，包括：

接收资源分配申请，所述资源分配申请中包括需求参数；

基于所述资源分配申请，获取多个数据库资源池对应的多个指标数据集，其中，所述指标数据集中包括所述数据库资源池的多个性能指标对应的多个性能指标值；

基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值；

将满足所述需求参数且所述综合性能值大于性能阈值的目标数据库资源池对外分配。

可选地，所述性能指标，包括：吞吐量指标、实例活动状态指标、写入读取IO状态指标、等待事件指标、锁存器申请等待率指标、操作系统OS性能指标和警报日志指标中的至少一种。

可选地，所述基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值的步骤，包括：

基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得各所述数据库资源池的各性能指标对应的分值；

对各所述数据库资源池的各性能指标值对应的分值进行加权，获得多个所述数据库资源池对应的多个综合性能值。

可选地，所述接收用户的资源分配申请的步骤之前，所述方法还包括：

获取所述多个数据库资源池的多个性能指标对应的多个历史性能指标值；

基于所述历史性能指标值，获得各所述性能指标对应的指标阈值。

可选地，所述获取所述多个数据库资源池的多个性能指标对应的多个历史性能指标值的步骤之后，所述方法还包括：

基于所述历史性能指标值，获得所述性能阈值。

可选地，所述基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值的步骤之后，所述方法还包括：

若不存在满足所述需求参数和/或所述综合性能值大于性能阈值的数据库资源池，输出预警信息。

此外，为实现上述目的，本申请的实施例还提出一种数据库资源池分配装置，包括：

申请接收模块，用于接收资源分配申请，所述资源分配申请中包括需求参数；

指标获取模块，用于基于所述资源分配申请，获取多个数据库资源池对应的多个指标数据集，其中，所述指标数据集中包括所述数据库资源池的多个性能指标对应的多个性能指标值；

性能获得模块，用于基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值；

资源分配模块，用于将满足所述需求参数且所述综合性能值大于性能阈值的目标数据库资源池对外分配。

此外，为实现上述目的，本申请还提供计算机设备，所述设备包括处理器，存储器以及存储在所述存储器中的计算机程序，所述计算机程序被处理器运行时实现上述方法的步骤。

此外，为实现上述目的，本申请还提供一种计算机存储介质，所述计算机存储介质上存储有计算机程序，所述计算机程序被处理器运行时实现上述方法的步骤。

此外，为实现上述目的，本申请还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例提出的一种数据库资源池分配方法，包括：接收资源分配申请，所述资源分配申请中包括需求参数；基于所述资源分配申请，获取多个数据库资源池对应的多个指标数据集，其中，所述指标数据集中包括所述数据库资源池的多个性能指标对应的多个性能指标值；基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值；将满足所述需求参数且所述综合性能值大于性能阈值的目标数据库资源池对外分配。也即，该方法根据数据库资源池的性能指标数据进行综合性能评估，并结合用户的需求匹配，获得满足需求且综合性能好的目标数据库资源池。相对于现有技术中基于人工或随机分配，该方法在分配数据库资源时考虑了数据库资源池的性能情况和用户需求，有效规避人为选择数据库资源池资源的不科学、不合理以及采用自动随机分配导致的业务系统性能瓶颈问题，降低了人工处理的盲区和不确定性，解决现有技术中对数据库资源池分配不均衡技术问题，提高了数据库资源池的利用率。

图1为本申请实施例涉及的硬件运行环境的计算机设备结构示意图；

图2为本申请实施例的数据库资源池分配方法流程示意图；

图3为本申请实施例中S60的一种实施方法的流程示意图；

图4为本申请实施例数据库资源池分配装置的结构示意图；

图5为本申请实施例数据库资源池分配的场景原理示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

本申请实施例的主要解决方案是：提供一种数据库资源池分配方法，包括：接收资源分配申请，所述资源分配申请中包括需求参数；基于所述资源分配申请，获取多个数据库资源池对应的多个指标数据集，其中，所述指标数据集中包括所述数据库资源池的多个性能指标对应的多个性能指标值；基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值；将满足所述需求参数且所述综合性能值大于性能阈值的目标数据库资源池对外分配。

构建一个合理的数据库资源池，是实现从传统的“烟囱式IT”迈向云计算基础架构的第一步。在传统的“烟囱式IT”基础架构中，应用和专门的资源捆绑在一起，为了应对少量的峰值负载，往往会过度配置资源，导致资源利用率低下。据统计，在传统的数据中心里，IT资源的平均利用率不到20％。

构建数据库资源池也就是通过虚拟化的方式将服务器、存储、网络等资源全面形成一个巨大的资源池。云计算就是基于这样的数据资源池，通过分布式的算法进行数据库资源的分配，从而消除物理边界，提升资源利用率，统一资源池分配。那么，在构建了共享的数据库资源池后，如何进行数据库资源池的合理分配就显得尤为重要。

该方法根据数据库资源池的性能指标数据进行综合性能评估，并结合用户的需求匹配，获得满足需求且综合性能好的目标数据库资源池。相对于现有技术中基于人工或随机分配，该方法在分配数据库资源时考虑了数据库资源池的性能情况和用户需求，有效规避人为选择数据库资源池资源的不科学、不合理以及采用自动随机分配导致的业务系统性能瓶颈问题，降低了人工处理的盲区和不确定性，解决现有技术中对数据库资源池分配不均衡技术问题，提高了数据库资源池的利用率。

参照图1，图1为本申请实施例方案涉及的硬件运行环境的计算机设备结构示意图。

如图1所示，该计算机设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)存储器，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及电子程序。

在图1所示的计算机设备中，网络接口1004主要用于与网络服务器进行数据通信；用户接口1003主要用于与用户进行数据交互；本发明计算机设备中的处理器1001、存储器1005可以设置在计算机设备中，所述计算机设备通过处理器1001调用存储器1005中存储的数据库资源池分配装置，并执行本申请实施例提供的数据库资源池分配方法。

图2为本申请的实施例提供的一种数据库资源池分配方法，基于前述硬件设备，该方法包括：

S20、接收资源分配申请，所述资源分配申请中包括需求参数。

在具体实施过程中，资源分配申请是用户(也称租户)针对可使用的数据库资源池的开通申请。为了匹配需求，资源分配申请中包括需求参数，具体的，需求参数可以包括连接数、并发数、表空间和空间增长量等。

此外，用户可以是一个或多个，对应的资源分配申请也可以是一个或多个。因此，可以对一个或多个用户同时进行数据库资源分配。

S40、基于所述资源分配申请，获取多个数据库资源池对应的多个指标数据集，其中，所述指标数据集中包括所述数据库资源池的多个性能指标对应的多个性能指标值。

在具体实施过程中，数据库资源池部署在云端数据库服务器中，例如，对于多租户数据库，CDB即Container DataBase，容器数据库，是作为多租户架构数据库中的容器存在，它是作为容纳整合后的其他数据库的一个容器而存在。CDB容器里面可以整合多个PDB(PDB即Pluggable DataBase，可以连接为12c中独立的数据库)，从而形成多租户的数据库。具体的，一个服务器或者一个服务器集可以布局一个或多个CDB，以构成一个数据库资源池，而每个数据库资源池对应的服器或服务器集的硬件及软件的指标构成了数据库资源池的性能指标。因此，对于每个数据库资源池，其包括多个性能指标，这些性能指标对应的性能指标值构成了指标数据集。

作为一种实施例，指标数据集中的性能指标值为实时数据。实时数据可以更准确的反应当前数据库资源池的性能状况，以更准确的为租户分配性能优秀的数据库资源池。

具体的，性能指标，包括：吞吐量指标、实例活动状态指标、写入读取IO状态指标、等待事件指标、锁存器申请等待率指标、操作系统OS性能指标和警报日志指标中的至少一种。具体的性能指标参见表1。

表1数据库资源池性能指标

表1中的性能指标，包括吞吐量指标、实例活动状态指标、写入读取IO状态指标、等待事件指标、锁存器申请等待率指标、操作系统OS性能指标和警报日志指标等一级指标。各一级指标又包括多个二级指标(例如，一级指标吞吐量中包括内存memory、磁盘disk、消除行迁移table fetch continued row、表扫描table scans、索引快速全扫描index fastfull scans和每秒I/O速度等二级指标，具体二级指标请参见表1，这里不再赘述)。

需要说明的是，吞吐量、实例活动状态、IO状态三部分组成数据库资源池的整体性能KPI，整体反应一个数据库资源池系统性能好坏最直观的指标，几乎所有的性能问题都会反应在SQL吞吐量上。通常在一个数据库中，SQL的吞吐量将以指标平均响应时间来衡量，正常应该在毫秒级别。具体来说，对于数据库，基于内存的排序、基于硬盘的排序、消除行迁移、表扫描以及索引快速全表扫描的次数越少，代表数据库资源池的吞吐量越小，数据库资源池的性能越好，；此外，当前登录数的每分钟增加次数越少以及会话PGA内存越小，代表数据库资源池的实例活动越少，数据库资源池的性能越好；写入读取状态IO状态中，主要从内存读取(缓冲区缓存读取占比高)，而尽量少的从硬盘直接读取，且I/O等待时间以及数据文件读取用时越少，则读取状态IO状态越好，数据库资源池的性能越好。因此，二级指标的得分标准可以设置为表中的标准。

等待事件指标：构成数据库资源池的等待事件KPI，等待事件说明了整体数据库资源池中因为资源争用所等待的具体原因和时间(即等待时间)，可以明确表明当前数据库的健康状态和运行状态。等待时间即数据库服务器等待的时间占比，包括IO等待，锁等待等非空闭等待，它反应的是数据库因为某种瓶颈而浪费的时间。理想情况下等待时间占比应该为0，该指标变大意味这数据库出现了严重的瓶颈。因此，非空闲等待事件数量越少，代表数据库资源池性能越好，因此，设置的得分标准越低。

锁存器申请等待率指标：可以反映锁存器Latch争用情况，Latch争用通常意味着某个进程持有latch的时间过长。如果latch争用明显，系统性能将显著下降。在高并发的环境中，latch争用经常发生，并且你无法完全消除latch争用。例如，用户在以独占方式访问block的时候所需要的latch，如：户进程A以只读(select)的方式访问Block，这个时候获得了该latch，同时用户进程B也以只读的方式访问Block，那么这个时候由于是只读的访问，用户进程B也可以获得该latch。但是，如果用户进程B要以独占的方式访问Block，那么用户进程B就会等待用户进程A释放该latch，这个时候Oracle就会对用户进程B标记一个latch。因此，锁存器申请等待率(Latch Pct Get Miss)中的二级指标越小，latch争用不明显，系统性能较好，因此，得分标准越高。

操作系统OS指标：数据库资源池的性能非常依赖服务器的硬件和操作系统的性能。因此，在诊断性能问题时，会将操作系统资源指标视为整体性能指标的一部分。其中CPU、内存、I/O是既相互独立又相互关联的三大操作系统资源。

警告日志Alter Log：ORA日志报错是非常严重的事情，常规的除了无法的警示性的ORA错误之外，类似ORA-600、ORA-7445、ORA-4031等错误可能会对数据库资源池造成碰撞Crash。

S60、基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值；

在具体实施过程中，可以对各性能指标设置指标阈值，以根据各性能指标值与指标阈值的关系，获得对应的性能指标的得分，以反应数据库资源池的性能。表1中的二级指标都对应设置了指标阈值，并分别规定了各二级指标对应的性能指标值与指标阈值不同的关系，所对应的二级指标得分标准。

作为一种实施例，所述基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值的步骤，包括：

S602、基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得各所述数据库资源池的各性能指标对应的分值。

在具体实施过程中，请参见表1，首先，可以根据对数据库资源池的二级指标的性能指标值与指标阈值的关系，获得各二级指标的对应的分值。举例来说，吞吐量中的二级指标基于内存的排序，基于内存的排序与指标阈值的关系包括基于内存的排序<50次时，得分为10，50次<基于内存的排序<80次时，得分为9,基于内存的排序>80次时，得分为8。其中，50次和80次为基于内存的排序对应的指标阈值。

S604、对各所述数据库资源池的各性能指标值对应的分值进行加权，获得多个所述数据库资源池对应的多个综合性能值。

在获得各二级指标对应的分值后，利用如下公式进行加权，获得数据库资源池综合性能值：

其中，x代表指标(一级指标或二级指标)的得分，w代表权重，n代表指标数量。

需要说明的是，x可以是单个二级指标，也可以是多个二级指标的组合，也可以是一级指标。权重的设置原理如下：

吞吐量、实例活动状态、IO状态三部分组成数据库资源池的整体性能KPI，整体反应一个数据库资源池系统性能好坏最直观的指标，几乎所有的性能问题都会反应在SQL吞吐量上。通常在一个数据库中，SQL的吞吐量将以指标平均响应时间来衡量，正常应该在毫秒级别。因此，将整体性能KPI的满分设置为100分，权重设置为35％。

等待事件指标：构成数据库资源池的等待事件KPI，等待事件说明了整体数据库资源池中因为资源争用所等待的具体原因和时间(即等待时间)，可以明确表明当前数据库的健康状态和运行状态。等待时间即数据库服务器等待的时间占比，包括IO等待，锁等待等非空闭等待，它反应的是数据库因为某种瓶颈而浪费的时间。理想情况下等待时间占比应该为0，该指标变大意味这数据库出现了严重的瓶颈。因此，将等待事件KPI的满分设置为100分，权重设置为25％。

锁存器申请等待率指标：可以反映锁存器Latch争用情况，Latch争用通常意味着某个进程持有latch的时间过长。如果latch争用明显，系统性能将显著下降。在高并发的环境中，latch争用经常发生，并且你无法完全消除latch争用。因此，将锁存器申请等待率的满分设置为60分，权重设置为10％。

操作系统OS指标：数据库资源池的性能非常依赖服务器的硬件和操作系统的性能。因此，在诊断性能问题时，会将操作系统资源指标视为整体性能指标的一部分。其中CPU、内存、I/O是既相互独立又相互关联的三大操作系统资源。因此，将操作系统OS中CPU使用率的满分设置为20分，权重设置为20％；CPU变化率的满分设置为15分，权重设置为20％；内存使用率的满分设置为20分，权重设置为10％；换页率的得分设置为50分，权重设置为10％。

警告日志Alter Log：ORA日志报错是非常严重的事情，常规的除了无法的警示性的ORA错误之外，类似ORA-600、ORA-7445、ORA-4031等错误可能会对数据库资源池造成碰撞Crash。满分设置为100，权重设置为20％。

如此，如表1中，各指标加权后满足之和为100。在具体实施过程中，按照二级指标得分标准获得得分后，进行加权，获得的加权后的分数相加即为综合性能值。

作为一种实施方式，所述接收用户的资源分配申请的步骤之前，所述方法还包括：获取所述多个数据库资源池的多个性能指标对应的多个历史性能指标值；基于所述历史性能指标值，获得各所述性能指标对应的指标阈值。

在具体实施过程中，可以对数百个数据库资源池的各性能指标进行采样分析，利用线性回归、聚类算法、深度学习等方法获得指标阈值。

S80、将满足所述需求参数且所述综合性能值大于性能阈值的目标数据库资源池对外分配。

在具体实施过程中，性能阈值是界定数据库资源池性能属于优或劣的阈值，性能阈值的取值并不受限制，例如，可以将综合性能值排名前一半的界定为性能优，反之界定为劣。具体的，可以通过可以对数百个数据库资源池系统的各性能指标进行采样分析，发现60分所在的指标值对应于所有这些数据库资源池优化之前的中位数，即在大规模优化之前，该指标项评分60分以上和以下的数据库资源池约各占一半，因此，性能阈值可以取60。可以理解的是，为了给租户分配性能更优数据库资源池，也可以适当的提高性能阈值的取值，例如65、70。为了提前获得性能阈值，作为一种实施方式，所述获取所述多个数据库资源池的多个性能指标对应的多个历史性能指标值的步骤之后，所述方法还包括：基于所述历史性能指标值，获得所述性能阈值。

此外，在考虑数据库资源池的性能基础上，还需要考虑数据库资源池的容量能否满足租户的需求，即数据库资源池的的参数能否满足需求参数。具体的，可以通过分析数据库资源池空间增长趋势及增长率，来预测是否满足租户需求中的最低空间要求。可以在判断综合性能值大于性能阈值后，再判断该数据库资源池是否满足需求参数，如果都满足，则获得的目标数据库资源池可以分配给发出资源分配申请的租户。

作为一种实施方式，所述基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值的步骤之后，所述方法还包括：若不存在满足所述需求参数和/或所述综合性能值大于性能阈值的数据库资源池，输出预警信息。

在具体实施过程中，预警信息可以有多种，例如，预警文字、预警语音、预警动作等，在本实施例中并不受限制。

可以理解的是，没有性能大于阈值的数据库资源池，则代表目前数据库资源池的性能都较差，此时，为了提示租户，不管最终给租户分配或不分配相应的数据库资源池，都可以输出预警信息。而不存在满足租户的需求参数的数据库资源池则无法给租户分配相应的数据库资源池，此时，需要输出预警信息。而当两者都不满足时，也可以输出预警信息。

应当理解的是，以上仅为举例说明，对本申请的技术方案并不构成任何限制，本领域的技术人员在实际应用中可以基于需要进行设置，此处不做限制。

通过上述描述不难发现，本实施例的方法根据数据库资源池的性能指标数据进行综合性能评估，并结合用户的需求匹配，获得满足需求且综合性能好的目标数据库资源池。相对于现有技术中基于人工或随机分配，该方法在分配数据库资源时考虑了数据库资源池的性能情况和用户需求，有效规避人为选择数据库资源池资源的不科学、不合理以及采用自动随机分配导致的业务系统性能瓶颈问题，降低了人工处理的盲区和不确定性，解决现有技术中对数据库资源池分配不均衡技术问题，提高了数据库资源池的利用率。同时，使数据库资源池达到业务运行性能最佳，提升业务系统用户体验。

基于同样的发明思路，本申请的实施例还提供了一种数据库资源池分配装置，参见图4，该装置包括：

申请接收模块，用于接收资源分配申请，所述资源分配申请中包括需求参数；

指标获取模块，用于基于所述资源分配申请，获取多个数据库资源池对应的多个指标数据集，其中，所述指标数据集中包括所述数据库资源池的多个性能指标对应的多个性能指标值；

性能获得模块，用于基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得多个所述数据库资源池对应的多个综合性能值；

资源分配模块，用于将满足所述需求参数且所述综合性能值大于性能阈值的目标数据库资源池对外分配。

作为一种实施方式，性能获得模块还可以包括：

数据分析模块，用于基于各所述指标数据集中的多个性能指标值与各所述性能指标对应的指标阈值的关系，获得各所述数据库资源池的各性能指标对应的分值；

综合评级模块，用于对各所述数据库资源池的各性能指标值对应的分值进行加权，获得多个所述数据库资源池对应的多个综合性能值。

作为一种实施方式，本实施例的装置，还可以包括：

历史数据分析模块，用于通过分析数据库资源池空间增长趋势及增长率，以预测数据库资源池是否满足租户需求中的最低空间要求。

在具体实施过程中，数据库资源池分配装置中各模块的具体实施方式可参照前述方法实施例中的具体实施方式，这里不再赘述。

作为一种实施方式，可以在前述实施例的计算机设备中设置Kafka消息模块，Kafka消息模块可以采集以及缓存数据库资源池的性能指标数据，供数据库资源池分配装置消费性能指标数据。Kafka消息模块的存在可以暂时的缓存性能数据，供数据库资源池分配装置随时消费，以提高数据库资源池性能评估的效率。

参见图5，本实施例提供了数据库资源池分配的场景原理示意图。图中，假设至少包括第一数据库资源池和第二数据库资源池，租户A和租户B发出资源分配请求，数据库资源池分配装置接收到资源分配请求后，从Kafka消息模块中消费第一数据库资源池和第二数据库资源池的性能指标数据，然后通过前述方法实施例中的实施方式进行数据库资源池的分配，从而将较优的数据库资源池分配给租户A或租户B。

应当理解的是，以上仅为举例说明，对本申请的技术方案并不构成任何限制，本领域的技术人员在实际应用中可以基于需要进行设置，此处不做限制。

通过上述描述不难发现，本实施例的装置根据数据库资源池的性能指标数据进行综合性能评估，并结合用户的需求匹配，获得满足需求且综合性能好的目标数据库资源池。相对于现有技术中基于人工或随机分配，该方法在分配数据库资源时考虑了数据库资源池的性能情况和用户需求，有效规避人为选择数据库资源池资源的不科学、不合理以及采用自动随机分配导致的业务系统性能瓶颈问题，降低了人工处理的盲区和不确定性，解决现有技术中对数据库资源池分配不均衡技术问题，提高了数据库资源池的利用率。同时，使数据库资源池达到业务运行性能最佳，提升业务系统用户体验。

此外，在一种实施例中，还提供一种计算机设备，所述设备包括处理器，存储器以及存储在所述存储器中的计算机程序，所述计算机程序被处理器运行时实现前述实施例中方法的步骤。

此外，在一种实施例中，本申请还提供一种计算机存储介质，所述计算机存储介质上存储有计算机程序，所述计算机程序被处理器运行时实现前述实施例一中方法的步骤。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。计算机可以是包括智能终端和服务器在内的各种计算设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如只读存储器/随机存取存储器、磁碟、光盘)中，包括若干指令用以使得一台多媒体终端设备(可以是手机，计算机，电视接收机，或者网络设备等)执行本申请各个实施例所述的方法

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。