x86服务器动态硬分区方法、装置、存储介质和计算机设备与流程

本发明涉及信息
技术领域：
，特别是涉及一种x86服务器动态硬分区方法、装置、存储介质和计算机设备。
背景技术：
：随着x86服务器技术的逐步成熟，基于x86芯片技术的不断进步以及服务器的配置越来越高，x86服务器的总体处理能力已经接近甚至超过了低端unix服务器。现代数据库系统，例如oracle数据库提供了非常精细化的资源管理功能，可以提供对io、并行计算资源、内存以及cpu的细粒度管理，但是这种资源管理技术建立在共享底层操作系统所管理的全局资源之上，资源容易动态扩充但是收缩速度较慢。而x86服务器并未提供如ibmunix服务器的逻辑分区(lpar)，或者hpeunix服务器的分区(npar)功能，用以将高配置的unix服务器分割成高度物理隔离且运行单独操作系统的“服务器”。基于当前的x86服务器硬件功能无法提供有效的物理隔离能力，以保障oracle数据库服务质量。技术实现要素：基于此，有必要针对上述问题，提供一种可有效保障oracle数据库服务质量的x86服务器动态硬分区方法、装置、存储介质和计算机设备。一种x86服务器动态硬分区方法，包括以下步骤：通过控制族群中部署在x86服务器的oracle数据库各节点的核心引擎，对对应节点进行分区初始化处理；通过所述核心引擎对对应节点初始化处理后的分区进行负载监控得到监控数据；通过所述核心引擎根据所述监控数据和存储的管理策略对对应分区的状态进行评估得到评估结果；通过所述核心引擎根据所述评估结果对对应分区进行调整。一种x86服务器动态硬分区装置，包括：分区初始化模块，用于通过控制族群中部署在x86服务器的oracle数据库各节点的核心引擎，对对应节点进行分区初始化处理；数据监控模块，用于通过所述核心引擎对对应节点初始化处理后的分区进行负载监控得到监控数据；状态评估模块，用于通过所述核心引擎根据所述监控数据和存储的管理策略对对应分区的状态进行评估得到评估结果；分区调整模块，用于通过所述核心引擎根据所述评估结果对对应分区进行调整。一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。一种计算机设备，包括存储器、x86服务器以及存储在存储器上并可在x86服务器上运行的计算机程序，所述x86服务器执行所述程序时实现上述方法的步骤。上述x86服务器动态硬分区方法、装置、存储介质和计算机设备，通过控制族群中部署在x86服务器的oracle数据库各节点的核心引擎，对对应节点进行分区初始化处理。通过核心引擎对对应节点初始化处理后的分区进行负载监控得到监控数据；通过核心引擎根据监控数据和存储的管理策略对对应分区的状态进行评估得到评估结果；通过核心引擎根据评估结果对对应分区进行调整。将控制族群与oracle数据库相结合，利用部署在oracle数据库各节点的核心引擎对各分区进行数据监控和评估，根据评估结果对分区进行动态调整，实现x86服务器的动态硬分区功能，提供有效的物理隔离能力，可有效保障oracle数据库服务质量。附图说明图1为一实施例中x86服务器动态硬分区方法的流程图；图2为另一实施例中x86服务器动态硬分区方法的流程图；图3为一实施例中动态硬分区技术实现架构图；图4为一实施例中核心引擎的架构图；图5为一实施例中核心引擎中状态机状态评估示意图；图6为一实施例中分区状态扩展迁移示意图；图7为一实施例中低负载分区示意图；图8为一实施例中中度负载波动分区示意图；图9为一实施例中分区状态收缩迁移示意图；图10为一实施例中分区以高负载状态运行的示意图；图11为一实施例中分区以低负载状态运行的示意图；图12为一实施例中执行器指令流程示意图；图13为一实施例中分区负载测试示意图；图14为一实施例中x86服务器动态硬分区装置的结构图；图15为另一实施例中x86服务器动态硬分区装置的结构图。具体实施方式在一个实施例中，一种x86服务器动态硬分区方法，适用于配置了多颗多核心intelxeon处理器并且配置了较多内存的x86服务器。具体可以以x86作为硬件平台，采用linux操作系统和oracledatabase12c数据库，实现x86服务器动态硬分区技术。如图1所示，该方法包括以下步骤：步骤s110：通过控制族群中部署在x86服务器的oracle数据库各节点的核心引擎，对对应节点进行分区初始化处理。控制族群(controlgroups，cgroup)是linux内核提供的一种可以限制、记录、隔离进程组(processgroups)所使用的物力资源(如cpumemoryi/o等)的机制。具体地，cgroup是将任意进程进行分组化管理的linux内核功能，其本身是提供将进程进行分组化管理的功能和接口的基础结构，i/o或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。这些具体的资源管理功能称为cgroup子系统或控制器。cgroup子系统有控制内存的memory控制器、控制进程调度的cpu控制器等。运行中的内核可以使用的cgroup子系统由/proc/cgroup来确认。cgroup提供了一个cgroup虚拟文件系统作为进行分组管理和各子系统设置的用户接口。要使用cgroup必须挂载cgroup文件系统，这时通过挂载选项指定使用哪个子系统。cgroup支持的文件种类如表1所示。表1在cgroup中，任务就是系统的一个进程。控制族群就是一组按照某种标准划分的进程。cgroup中的资源控制都是以控制族群为单位实现。一个进程可以加入到某个控制族群，也从一个进程组迁移到另一个控制族群。一个进程组的进程可以使用cgroup以控制族群为单位分配的资源，同时受到cgroup以控制族群为单位设定的限制。控制族群可以组织成层级(hierarchy)的形式，即一棵控制族群树。控制族群树上的子节点控制族群是父节点控制族群的孩子，继承父控制族群的特定的属性。一个子系统就是一个资源控制器，比如cpu子系统就是控制cpu时间分配的一个控制器。子系统必须附加到一个层级上才能起作用，一个子系统附加到某个层级以后，这个层级上的所有控制族群都受到这个子系统的控制。每次在系统中创建新层级时，该系统中的所有任务都是那个层级的默认cgroup(可称之为rootcgroup，此cgroup在创建层级时自动创建，后面在该层级中创建的cgroup都是此cgroup的后代)的初始成员。一个子系统最多只能附加到一个层级，一个层级可以附加多个子系统。一个任务可以是多个cgroup的成员，但是这些cgroup必须在不同的层级。系统中的进程(任务)创建子进程(任务)时，该子任务自动成为其父进程所在cgroup的成员。然后可根据需要将该子任务移动到不同的cgroup中，但开始时它总是继承其父任务的cgroup。本实施例中，oracle数据库采用oracle数据库12c，引入了processor_group(oracle,oracledatabase12crelease1(12.1.0.1)newfeatures,2016)特性，利用这一特性，oracle数据库12c可以与linux或者solaris紧密结合，从而利用操作系统的处理器集合及其相关的资源，实现将数据库实例进程及内存绑定到操作系统层面特定的处理器及其内存资源上，而这一特性主要受限于当前x86服务器设计所采用的numa(non-uniformmemoryaccess，非统一内存访问架构)架构。numa是一种为多处理器的电脑设计的内存，内存访问时间取决于内存相对于处理器的位置。在numa下，处理器访问它自己的本地内存的速度比非本地内存(内存位于另一个处理器，或者是处理器之间共享的内存)快一些。numa的特点是：被共享的内存物理上是分布式的，所有这些内存的集合就是全局地址空间。所以处理器访问这些内存的时间是不一样的，显然访问本地内存的速度要比访问全局共享内存或远程访问外地内存要快些。另外，numa中内存可能是分层的：本地内存，群内共享内存，全局共享内存。基于当前的intelxeon处理器技术，目前的4路服务器可能配置了64核心，128线程；如果是两路服务器可能配置了32核心，64线程。对于很多中小型企业，如果在这样的平台上运行单独的数据库，通常会利用率不足，进行业务的整合就势在必然。目前的8路服务器的核心数可能为192核，384线程。综合常见的4路，8路服务器配置来看，目前的硬件处理能力与很多unix服务器在性能上持平，甚至超越了unix服务器。但是性能上的超越不能为企业带来稳定的运行环境,而传统unix服务器上使用广泛的分区技术具备很强的实用性，因为这一技术可以在充分利用硬件资源的基础上，为企业应用提供必要的隔离性，从而保证企业应用的稳定性。通过在x86服务器上运行linux操作系统及oracle数据库12c进行业务整合时，实现数据库实例的动态硬分区以保证数据库服务质量。动态硬分区指部署在同一台x86pc服务器上的数据库实例独占一个数据cpu，或者一颗cpu内的一个或者数个计算核心，当消耗尽其独占的计算资源时，该数据库实例不会占用其他数据库实例所分配的计算资源，从而保证该x86服务器上的数据库服务质量。具体地，将控制族群中的核心引擎布置在oracle数据库的各个节点，核心引擎的数量与节点数量对应。核心引擎属于微内核产品，即所有的组件均内建在核心引擎内，组件之间紧耦合，最终确保本核心引擎的稳定、可靠。核心引擎负责本服务器计算机资源控制器的初始化，确保各计算资源在运行期间的可用性。步骤s130：通过核心引擎对对应节点初始化处理后的分区进行负载监控得到监控数据。利用核心引擎对当前节点内的所有分区的负载进行监控，获取的监控数据用作后续进行分区调整的依据。步骤s140：通过核心引擎根据监控数据和存储的管理策略对对应分区的状态进行评估得到评估结果。具体可预先接收管理策略进行保存，还可以实时接收新的管理策略对已存储的策略进行更新。管理策略的种类并不唯一，从适用范围来分，管理策略可包括统一策略和单独策略。其中，统一策略指该策略在集群内的所有节点都通用，策略的每次变更，必须复制至整个集群，确保每个分区(或者数据库实例)具备一致的计算资源。单独策略指该策略仅在某个单独的服务器上有效，该策略无须复制至整个集群。从用途来分，管理策略可包括扩展策略和收缩策略。其中，扩展策略指在当前分区的计算资源如果达到预设的上限门限值时，通常为了业务的稳定运行通常需要对当前分区的计算资源进行扩展，计算资源的扩展通常会根据上限门限值进行迁移。收缩策略指在当前分区的计算资源如果处于闲置状态，通常为了当前节点的其他分区储备计算资源时需要对当前分区的计算资源进行收缩，计算资源的收缩通常会根据下限门限值进行收缩。收缩策略不是扩展策略的简单逆向操作，收缩策略需要通过停止数据库实例进行资源的释放，然后才能释放资源。扩展或者收缩由核心引擎结合监控数据进行确定得到评估结果，然后根据评估结果进行最终的扩展或者收缩。在一个实施例中，管理策略包括分区状态与门限值的对应关系，步骤s140包括步骤142和步骤144。步骤142：根据监控数据和分区状态与门限值的对应关系，得到对应分区的目标状态。分区计算资源的扩展收缩依赖于策略管理器制定的门限值，门限值的设定通常依赖于当前节点的硬件配置以及运维监控规范。目标状态即指分区需要迁移的状态。举例说明，分区状态包括a、b和c三种，对应的门限值分别为a、b和c。若获取的监控数据与门限值c匹配，则该分区的目标状态为c。步骤144：分别根据各分区的当前状态和目标状态得到对应分区的评估结果。同样以分区的目标状态为c为例，若分区的当前状态为a，则得到的评估结果为a->c，需要将该分区从a状态迁移至c状态。步骤s150：通过核心引擎根据评估结果对对应分区进行动态调整。在得到各分区的评估结果之后，核心引擎根据评估结果直接对对应分区进行动态调整。具体地，与管理策略可包括扩展策略和收缩策略对应，步骤s150包括：根据评估结果对对应分区的计算资源进行扩展或收缩调整。在一个实施例中，如图2所示，步骤s110之后，步骤s130之前，该方法还包括步骤s120。步骤s120：通过核心引擎对初始化处理后的分区进行隔离性测试。分区在配置完毕后，通常需要进行各个分区的隔离性测试，可以在每个分区内单独运行以下脚本，以验证分区的高度隔离性，提高了x86服务器动态硬分区可靠性。利用核心引擎对初始化处理后的分区进行隔离性测试，并在隔离性测试通过后进行的步骤s130。在一个实施例中，步骤s140之后，还包括通过控制族群中的消息总线进行各核心引擎之间的消息传输的步骤。控制族群还包括连接各核心引擎的消息总线，消息总线负责各个节点间的消息传递，消息传递具体可包括对统一策略的传递，确保策略在集群内的一致性。消息传递还可包括对分区迁移指令的传递，确保集群内的其他节点的分区状态的一致性。可以理解，如果系统仅有一个节点，配置单独的核心引擎即可，不需要部署消息总线；仅在部署集群环境时才需要部署消息总线进行核心引擎之间的消息传递。为了便于更好地理解上述x86服务器动态硬分区方法，下面结合具体的实施例进行详细的解释说明。动态硬分区的实现依赖于linux操作系统的cgroup和oracle数据库12c的一个重要特性processor_group_name，当把二者结合起来即可在x86服务器上实现类似unix服务器上才具备的动态硬分区功能，动态硬分区技术实现架构图如3所示。在每个节点上部署动态硬分区的核心引擎，核心引擎之间通过节点外部的消息总线进行消息的传递。x86服务器动态硬分区由核心引擎驱动和管理，其架构图如图4所示。核心引擎包括监视器、状态机、策略管理器和执行器。监视器负责当前节点内的所有分区的负载监控，状态机结合配置的策略进行每个分区状态的评估，并最终由执行器负责执行状态机对每个分区容量最终的评估结果；策略管理器负责策略的配置以及策略在整个集群内的复制，确保策略在集群内的一致性。每个节点的核心引擎都处于平等的地位，每个引擎发起的操作都可以广播或者复制到其他节点的引擎。cgroup在使用前需要依赖cpuset子系统正常运行，核心引擎负责该子系统的初始化，具体脚本如下：#mkdir/etc/cpuset#touch/etc/cpuset.conf#mkdir/dev/cpuset#mount–tcpusetcpuset/dev/cpuset#load_partition#servicecgconfigstart#servicecgredstart其中load_partition负责从/etc/cpuset.conf内读取分区的正确配置，并将其进行合适的初始化，否则后续的数据库实例无法独占cpu资源。核心引擎负责计算资源集合内的内存处于独占状态，并且保证内存处于不可迁移状态，已确保数据库实例运行状态的稳定性和排他性，具体脚本如下：#echo1>/dev/cpuset/partition/mem_exclusive#echo1>/dev/cpuset/partition/memory_migrate当分区初始化完毕后，数据库实例即可以一种独占状态独占计算资源(cpu和内存)，即使该实例消耗尽该分区内的资源它也无法申请其他分区的资源，具体脚本如下：sql>altersystemsetprocessor_group_name＝oraclescope＝spfile；sql>shutdownimmediatesql>startup核心引擎未引入其它第三方商业软件，因此不增加额外的投资成本。监视器负责对每个分区的负载进行监控并进行存储。负载监控采用系统默认自带的的系统监控工具sar；同一个节点上通常会存在多个分区，监控负载时首先获得监控分区的cpuset值，然后进行监控，最后将采集负载数据存储到本地的工作负载库内。如果系统未配置系统活动监视采集器，则需要自定义监视采集器。监视器进行监控是第一步需要获取系统内定义的分区信息，可通过以下脚本进行获得：#！/bin/bashcd/cgroup/cpusetfind./-typed|egrep-o"[[:alnum:]]"*然后获取分区内的cpu信息：#！/bin/bashcgget-gcpuset:$1|grepcpuset.cpus|cut-d':'–f2#注意获取的结果是一个cpucore的起始值，需要进一步处理根据获取的cpuset信息进行进一步的监控。例如如下列命令所示：#sar–p0，15如果系统配置系统活动监视采集器，监视器可以从sar的监控结果中定期的进行分析获取相关的结果亦可。策略管理器负责监控策略的管理，以及分区计算机资源的扩展收缩策略的管理及复制，鉴于在一个集群内可能存在不同的业务数据库的整合，即同一集群内各个节点的负载可能并不一致，因此策略管理器要对不同的策略进行区别对待。分区计算资源的扩展收缩依赖于策略管理器制定的门限值，门限值的设定通常依赖于当前节点的硬件配置以及运维监控规范。如表2所示，该样例设定的分区状态迁移和通常的运维监控指标关系表，门限值按照25％的幅度进行递增或者递减。达到预设的门限值后，通常需要按照一定的数量对计算核心进行扩展或者收缩。状态门限值1门限值2门限值3s1≤25％s2≤50％s3≤75％表2如表3所示，该样例设定的分区扩展按照基线累进策略进行扩展，主要是考虑到分区进行跨越式迁移时要满足业务负载的实际需要。状态扩展1扩展2扩展3s1+2s2+4s3+6表3如表4所示为一样例设定的分区收缩关系表。状态收缩1收缩2收缩3s1-2s2-4s3-6表4分区收缩是一个复杂的过程，由于计算资源独占，不能通过简单的降低计算资源数量而让分区进行动态的稳步收缩，稳定可靠的方法是通过关闭分区(数据库实例)释放资源，然后收缩分区计算资源，然后重新启动该分区。这也是目前虚拟化容器计算资源收缩主要的收缩方式。通过有限状态机有效稳定控制分区的计算资源扩展或者收缩，确保分区运行稳定可控。状态机负责根据策略管理器制定的策略以及监控数据对分区进行调整，具体的调整指令由执行器负责执行，并传递到整个集群内的每个节点上。图5所示为状态机状态评估示意图。下面分别对分区状态扩展迁移和分区状态收缩迁移进行解释说明。图6为分区状态扩展迁移示意图。图7所示为一低负载分区的监测数据，该分区一直运行平稳，基于策略管理器设定的分区扩展门限值，该分区无须进行计算资源的扩展。该分区的状态迁移路径为：s1->s1。图8所示为一中度负载波动分区的监测数据，该分区负载波动较为明显，基于策略管理器设定的分区扩展门限值，应该为该分区进行计算资源的扩展，增加2个核心的计算资源。该分区的迁移状态路劲为：s1->s2。状态机会根据策略管理器制定的策略，评估当前分区是否有可用的资源进行扩展，如果有可用的资源进行扩展，则状态机会向执行器生成计算资源扩展的具体指令：echomin-current+2>/dev/cpuset/partition/cpus如果无可用的资源进行扩展，则状态机会向执行器发出告警信息。当前分区计算资源的扩展可以快速完成，分区扩展指令也可以以极快的速度传递到整个集群并且快速对各个分区进行计算资源的扩展。图9为分区状态收缩迁移示意图。如果分区的资源使用率不足，发生较大的变化，通常需要进行分区资源的回收。如图10所示为一分区以高负载状态运行的监测数据图，该分区以较高的负载运行，若负载下降到一直如下图11所示，则该分区需要进行分区资源的收缩。资源收缩时一个耗时复杂的过程，没办法直接将资源从分区内回收，通常需要将数据库实例停机，然后回收资源；然后再在其他节点执行类似操作。$srvctlstopinstance–dborcl–instanceorcl1#echomin-current-6>/dev/cpuset/partition/cpus执行器是核心引擎内最终的指令执行体，它负责执行监视器下发的监控指令，执行策略管理器下发的策略变更同步指令，执行状态机下发的分区迁移指令，执行其他执行器投递到消息总线的指令，还负责执行器也负载将统一指令投递到消息总线，确保集群内的其他节点的分区状态的一致性。如图12所示为执行器指令流程图。消息总线负载将各个节点的消息传递。分区在配置完毕后，通常需要进行各个分区的隔离性测试，可以在每个分区内单独运行以下脚本，以验证分区的高度隔离性。具体脚本如下：在运行该脚本时要确保其他分区处零负载运行状态。如果在满足条件的情况下测试，其他分区有较高负载运行状态，则说明cgroup或者cpuset等低层资源配置存在错误。正常情况下，分区负载图如图13所示。上述x86服务器动态硬分区方法，将控制族群与oracle数据库相结合，利用部署在oracle数据库各节点的核心引擎对各分区进行数据监控和评估，根据评估结果对分区进行动态调整，实现x86服务器的动态硬分区功能，提供有效的物理隔离能力，可有效保障oracle数据库服务质量。在一个实施例中，一种x86服务器动态硬分区装置，适用于配置了多颗多核心intelxeon处理器并且配置了较多内存的x86服务器。如图14所示，该装置包括分区初始化模块110、数据监控模块130、状态评估模块140和分区调整模块150。分区初始化模块110用于通过控制族群中部署在x86服务器的oracle数据库各节点的核心引擎，对对应节点进行分区初始化处理。具体地，将控制族群中的核心引擎布置在oracle数据库的各个节点，核心引擎的数量与节点数量对应。核心引擎属于微内核产品，即所有的组件均内建在核心引擎内，组件之间紧耦合，最终确保本核心引擎的稳定、可靠。核心引擎负责本服务器计算机资源控制器的初始化，确保各计算资源在运行期间的可用性。数据监控模块130用于通过核心引擎对对应节点初始化处理后的分区进行负载监控得到监控数据。利用核心引擎对当前节点内的所有分区的负载进行监控，获取的监控数据用作后续进行分区调整的依据。状态评估模块140用于通过核心引擎根据监控数据和存储的管理策略对对应分区的状态进行评估得到评估结果。具体可预先接收管理策略进行保存，还可以实时接收新的管理策略对已存储的策略进行更新。在一个实施例中，管理策略包括分区状态与门限值的对应关系，状态评估模块140包括目标状态获取单元和评估结果获取单元。目标状态获取单元用于根据监控数据和分区状态与门限值的对应关系，得到对应分区的目标状态。分区计算资源的扩展收缩依赖于策略管理器制定的门限值，门限值的设定通常依赖于当前节点的硬件配置以及运维监控规范。目标状态即指分区需要迁移的状态。举例说明，分区状态包括a、b和c三种，对应的门限值分别为a、b和c。若获取的监控数据与门限值c匹配，则该分区的目标状态为c。评估结果获取单元用于分别根据各分区的当前状态和目标状态得到对应分区的评估结果。同样以分区的目标状态为c为例，若分区的当前状态为a，则得到的评估结果为a->c，需要将该分区从a状态迁移至c状态。分区调整模块150用于通过核心引擎根据评估结果对对应分区进行动态调整。在得到各分区的评估结果之后，核心引擎根据评估结果直接对对应分区进行动态调整。具体地，与管理策略可包括扩展策略和收缩策略对应，分区调整模块150具体根据评估结果对对应分区的计算资源进行扩展或收缩调整。在一个实施例中，如图15所示，x86服务器动态硬分区装置还包括隔离性测试模块120。隔离性测试模块120用于在分区初始化模块110对对应节点进行分区初始化处理之后，数据监控模块130通过核心引擎对对应节点初始化处理后的分区进行负载监控得到监控数据之前，通过核心引擎对初始化处理后的分区进行隔离性测试，并在隔离性测试通过后控制数据监控模块130通过核心引擎对对应节点初始化处理后的分区进行负载监控得到监控数据。在一个实施例中，x86服务器动态硬分区装置还包括消息传输模块。消息传输模块用于在状态评估模块140通过核心引擎根据监控数据和存储的管理策略对对应分区的状态进行评估得到评估结果之后，通过控制族群中的消息总线进行各核心引擎之间的消息传输。控制族群还包括连接各核心引擎的消息总线，消息总线负责各个节点间的消息传递，消息传递具体可包括对统一策略的传递，确保策略在集群内的一致性。消息传递还可包括对分区迁移指令的传递，确保集群内的其他节点的分区状态的一致性。可以理解，如果系统仅有一个节点，配置单独的核心引擎即可，不需要部署消息总线；仅在部署集群环境时才需要部署消息总线进行核心引擎之间的消息传递。上述x86服务器动态硬分区装置，将控制族群与oracle数据库相结合，利用部署在oracle数据库各节点的核心引擎对各分区进行数据监控和评估，根据评估结果对分区进行动态调整，实现x86服务器的动态硬分区功能，提供有效的物理隔离能力，可有效保障oracle数据库服务质量。在一个实施例中，一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。存储介质具体可以是软盘、光盘、dvd、硬盘、闪存、u盘等，具体类型并不唯一。上述计算机可读存储介质，将控制族群与oracle数据库相结合，利用部署在oracle数据库各节点的核心引擎对各分区进行数据监控和评估，根据评估结果对分区进行动态调整，实现x86服务器的动态硬分区功能，提供有效的物理隔离能力，可有效保障oracle数据库服务质量。在一个实施例中，一种计算机设备，包括存储器、x86服务器以及存储在存储器上并可在x86服务器上运行的计算机程序，x86服务器执行程序时实现上述方法的步骤。上述计算机设备，将控制族群与oracle数据库相结合，利用部署在oracle数据库各节点的核心引擎对各分区进行数据监控和评估，根据评估结果对分区进行动态调整，实现x86服务器的动态硬分区功能，提供有效的物理隔离能力，可有效保障oracle数据库服务质量。以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。当前第1页12