Oracle资源管理器在HIS系统中的应用

【摘要】系统管理员是否遇到过执行某个大数据量统计报表查询或者进行全库RMAN备份的时候，导致整个HIS系统的操作变慢甚至影响正常业务使用的情况，其实这是典型的服务器资源争用和等待的案例，如何合理的分配和管理有限的服务器资源，让更重要的业务更充分的利用资源，这是本文Oracle资源管理所实现的功能。

关键词：Oracle，资源管理

1. 前言

众所周知，业务系统的任何操作都需要消耗服务器资源，当一个服务器部署完成后，其总的可利用资源是一个有限值，所有的业务操作资源消耗都需要在这个范围内进行分配，如果同一时间业务对资源的消耗超过了服务器资源供给，势必会出现资源争用和等待，更为严重的时候，这个时候前台应用最直观的表现就是’慢’，更严重的后果这种争用和等待可能导致整个服务器性能急剧下降，出现性能问题，甚至导致服务器宕机。

最近几年，中联用户随着业务量增大和信息系统应用深入，对服务器的资源需求也越来越大，医院除了加大硬件投入逐步提高服务器的性能，增加服务器资源外，对资源的管理和分配完全依赖于操作系统的动态适应，这势必带来一些不合理的情况，如果让这些资源的管理和分配更加合理，这也是信息系统管理值得思考的问题。

1.1. 影响HIS系统的资源

资源是一个比较笼统的概念，它指可进行处理以更改应用程序行为的计算系统的任何方面。因此可以说资源就是应用程序隐式或显式请求的功能，如果拒绝或约束了此类功能，则应用程序就会无法执行或者变慢，例如是当服务器进程数很多时，操作系统进程和数据库服务进程间的来回切换会导致CPU占用率或内存使用率高，这时候整个服务器反应就会变慢，这就是我们常说的资源消耗。

ZLHIS系统是一个复杂的业务应用系统，其依托于Oracle数据库部署在服务器上，因此服务器上任何一个对HIS系统的运行起到至关重要的影响都可以说是HIS系统的资源，这类资源可以简单的分为硬件和非硬件两类，我们这里说得资源特别指非硬件类，比较常见有CPU使用率、内存消耗、IO操作以及网络等等。这些资源相对独立又互相关联，任何一点出现瓶颈都可能影响整个HIS系统业务的运行。

HIS系统的每个会话操作可以定义为一个‘业务’，整个HIS系统是一个业务系统的集合，其中的每个业务生命周期内会对资源的总体需求是不同的，而且这种需求也不是平均，可能某个时间点特别需要资源，其它时间又相对资源的需求不是很强烈，如下图是某三甲医院整点CPU使用率的采样，从中可以大致看出一天内（24小时）HIS系统对CPU资源的需求概况。



图1：某医院一天CPU使用率采样
从上图可以看到HIS系统对CPU资源的需求是波动的，同样的道理对其它资源如内存、IO操作需求也是一样，都不会是平稳不变，而是根据业务操作的不同进行波动，这些业务的重要程度各不相同，比如我们最看重的是窗口业务，如门诊收费、住院结账、记账、医嘱发送等，这些业务直接影响医院医疗效率和收入，应该保证有最充足的资源获取，而另外一些业务，如数据统计、数据备份、后勤业务等重要程度相对偏低，但是往往其对资源的消耗又比较大，这样就产生了一些矛盾，如果这些业务同时进行，势必会影响重要业务对资源的获取，如何让最重要的业务有充足的资源使用、其它业务的运行不对其资源造成影响，让资源的利用尽可能的平稳，合理有效的分配和利用资源，就是资源管理所要达到的目的。

1.2. 常用的资源管理方法

操作系统对资源的分配和回收是完全动态的，取决于业务请求的先后顺序，操作系统会尽可能的满足请求的资源，一旦资源被先请求的业务占用，后面的业务在获取资源不充足的情况下，只有等待之前的业务释放资源。这就会出现两个问题：1.业务请求的资源过多，将资源耗尽；2.资源被占用，重要业务无法获取资源，只有等待；以上两种情况都是我们不想看到的，但是操作系统又无法避免，这就需要管理员对资源进行管理，目前医院常见的管理方式有以下几种：

l 人为计划管理

这是最简单、最直观的一种管理方式，把对资源消耗多、重要性偏低的业务放在相对空闲的时间段进行，如系统备份、费用汇总表、数据采样等，这些操作对资源的需求高、但是时效性要求相对低，一般情况下医院都把这些操作放在晚上通过计划任务进行，因为对医院来说晚上常规业务如收费、记账、医嘱等业务量比较小，这时候空闲资源相对较多，能够满足备份操作都业务的资源需求，同时这些操作对常规业务的影响在这个时间段也相对较少。

l 第三方软件管理

现在虚拟化技术越来越多的得到应用，通过虚拟化软件，能够把多台服务器资源进行整合，达到资源共享的目的，类似的软件比较多，比较常见的如VMware vSphere虚拟化管理软件，其就是通过虚拟化技术，把多个服务器的资源整合为一个资源池，所有的业务操作所需的资源都是通过资源池进行管理和分配，其能够根据业务划分和资源的调度对资源进行合理的分配，达到合理利用，这也是现在比较推崇的一种管理模式。

l 概要文件资源限制

除了上面的两种方式，Oracle还有个概要文件，其可以对指定的用户连接操作的资源进行限制，如下图：



通过概要文件，限制非重点业务用户对资源的使用，也就间接控制了资源的分配，从而让更重要的业务优先和最大程度的使用资源。

1.3. 存在那些问题

这些常见的资源管理方式其都能对服务器资源进行一定的管理和分配，但是针对HIS服务器特有的业务环境，其也存在一些显而易见的问题，主要表现在以下几点：

l 管理局限

虽然有些业务可以通过人为的计划调动进行时段的分配，但是另外一些业务如报表查询统计、瞬时的大数据过滤、频繁的轮询查询等，这些没有特定的操作规律，根本无法通过用户方式进行控制，还有就是针对一些Oracle数据库的特有资源，例如：并行执行的服务数和活动的会话数等，这些管理都无法实现。

l 低效管理

利用操作系统管理调度数据库服务本身就占用一定的资源，最直接的其会占用CPU资源，而这些个资源是非常有限，而且效率还非常的低，当出现资源瓶颈后从而导致保持闩锁的数据库服务器进程会暂停，而且其从发现资源出现瓶颈到进行管理重新分配，这个时间过程也会比较长，在三甲医院高峰期窗口关键业务中，这样的业务暂停和等待是不可接受的。

l 成本过高

虚拟化虽然能够对业务的动态操作进行管理，但是其高昂软件的价格和部署成本对医院来说确实接受起来非常困难，另外虚拟化资源间相互的影响也非常大，常常出现‘木桶效应’，这也是为什么很多Oltp系统不愿意构建在虚拟化环境中的原因。

Oracle 资源管理（Oracle DatabaseResource Manager，简称DBRM）通过它的管理把硬件等资源的分配交给数据库服务器本身来解决以上问题，在某个数据库环境中，可能同时存在着多个用户请求数据库服务，并且他们所要完成的任务优先级不同，那么我们就应该区别对待这些会话请求。Oracle RMDB能让你根据各个会话的应用属性，将它们分组，然后为每组分配不同的数据库资源，最大化提高你的数据库应用性能。

2. oracle资源管理（RMDB）

2.1. 概述和特点

Oracle 资源管理用于管理混合的工作量，控制系统的性能，与通常只通过操作系统管理资源相比，可以对计算机资源的分配进行更多的控制，其最大的特点就是通过分组模式，把会话按照一定优先级进行分组，分成若干的用户组，再以组为单位对其进行资源的分配和限制，例如下图把HIS用户根据操作的业务属性的不同分为窗口用户组、医技用户组、后勤用户组，再结合其业务特点和重要性按优先级和份额对资源进行分配，如下图：



当然这样的组分配资源的规则也不会一成不变，通过控制数据库内部的执行调度，达到控制资源在各个会话之间的动态分布，确保资源分布与业务的实际需求相匹配。因此利用数据库资源管理器，无论系统的负载和用户的数量如何，都可以保证用户组的处理资源达到要求，满足业务的需求，资源管理是怎么实现这种动态的分配的呢？其主要通过资源计划和资源计划指令实现，通过其同资源使用者组的配合，达到灵活的动态管理资源的目的，这三者的关系如下：



“资源使用者组”：定义了具有相似的系统或数据库资源使用需求的一组用户或会话。

“资源计划指令”：指定如何在使用者组或子计划之间共享某个特定资源。通过计划指令，可以将资源使用者组及子计划与特定的资源计划关联起来。

“资源计划”：指定如何在各个资源使用者组之间分配资源。使用数据库资源管理器还可以在计划中创建计划，这称为“子计划”。

其中资源计划指令和资源计划共同组成了对资源用户组的“资源分配方法”，确定分配任何特定资源时使用的策略。

2.2. 资源管理的内容

Oracle资源管理器相对于其它方式的资源管理，除了管理服务器资源外，还能够对数据库内部的资源进行管理，这一点就大大增强了其管理能力,总结下来其可以管理数据库和操作系统资源主要包括如下：

1. 操作系统资源：

• CPU 使用率：可以指定在使用者组和子计划之间如何分配CPU 资源。

•I/O限制: Oracle资源管理器通过执行一个I/O密集的只读工作量来评估数据库服务器的存储系统的I/O性能，这个评估操作应该在非业务高峰期间执行，以确保校准不影响生产的工作量，以及生产的工作量对校准结果的影响，用户组可以基于I/O阀值(最大请求数或M字节)进行资源组自动切换。

• 活动会话数限制：可以限制使用者组或子计划的并发活动会话数。如果某个组的会话数超过了允许的最大值，则新的会话将放在队列中，等待某个活动会话完成。

2. 数据库资源：

• 并行度限制：Oracle的并行机制可以把一个大操作分割成若干小操作进行，从而提升运行速度，但是并行本身也是一种资源消耗， Oracle资源管理可以控制使用者组中任何操作的最大并行度，对这种资源消耗进行限制。

• 还原池：可以控制使用者组或子计划能够生成的还原操作的总数。当还原空间的总数超过UNDO_POOL指定的数量时，在同一组中其它会话释放还原空间或者增大使用者组的还原池之前，不允许执行任何新的INSERT、UPDATE或DELETE命令。如果使用者组在执行DML 语句时超过了限额，则中止操作并返回错误。此时仍可进行查询，即便使用者组已经超出其还原阈值。

3. 时间资源：

• 执行时间限制：可以指定操作所允许的最大执行时间。Oracle DB 使用基于成本的优化程序统计信息来估计操作所需的时间。如果耗时超过了所允许的最大时间(MAX_EST_EXEC_TIME)，则操作返回错误并且不会启动。如果资源使用者组有多个指定了MAX_EST_EXEC_TIME的计划指令，则资源管理器将选择所有传入值中限制性最强的那个值。

• 空闲时间限制：可以指定会话的空闲时间，超过该时间后将终止会话(MAX_IDLE_TIME)。你可以进一步限制资源管理器，使其只终止阻止其它会话的会话(MAX_IDLE_TIME_BLOCKER)。

4. 用户组资源：

• 使用者组切换：初始使用者组是在会话刚登录时所属的组。顶层调用被定义为将整个PL/SQL 块视为一个调用，或类似地，将客户机单独发出的SQL 语句视为单独调用。在中间层服务器实施会话共享的三层应用模型中，此功能的优势是最显而易见的。在这种情况下，中间层在为某个最终用户执行一个调用后，可使用相同的会话为另一个最终用户执行调用。因此，工作的分界线实际上为调用，并且上一个最终用户的操作不会影响下一个最终用户。可以创建一个计划指令，使资源管理器在顶层调用结束时将用户自动切换回初始使用者组。

要想对应用的资源合理的分配和控制，以上的资源管理都不能单一的进行，只有通过合理的搭配，资源间相互配合，才能达到真正的有效管理的目的，而这些组合和配合则需要通过‘资源计划指令’和‘资源计划’实现。

2.3. 资源管理的具体功能

Oracle资源管理器就是为Oracle用户分配用户组，然后通过该用户组设置对应的‘资源计划’和‘资源计划指令’，通过其合理的组合，可以实现对资源的灵活控制和管理，结合上面资源管理可以管理的资源，我们来看下Oracle资源管理具体可以实现那些功能：

1. 资源限制功能：

可以在系统启动时，限制某些会话请求只分配到最少的进程资源和用户使用上限。

限制同一组内用户对数据库操作的并行度。

建立一个活动的会话池。会话池由一组用户活动会话组成，对某一组用户来说，同一时间活动的会话数有特别的数量上限。如果会话池满了，新的会话请求会被放入等待队列，而且你还可以设置一个时间上限，超过这个上限，等待队列会被停止。会话池限制了同一时间活动的会话请求数量，保证了活动的会话请求更快的完成任务。

限制一个会话的空闲等待时间。

2. 资源分配功能：

为不同的用户或应用分配不同的CPU时间。在HIS应用中，门诊业务的CPU使用率的优先级应该最高，任何操作如报表查询、备份等都不能影响门诊业务的使用。

管理长时间未响应的会话或请求，这些会话或请求往往占用了很多的CPU或I/O资源。这些会话能被自动的结束掉，或者将它们换到其他低级的组去。

根据不同的资源分配需求，配置不同的模式。你可以动态的改变这些模式，例如，从白天运行模式变到夜间运行模式，而不用重启数据库服务。你还可以通过Oracle调度器来管理模式的改变。

3. 资源消耗估算：

Oracle资源控制器还有一个最大的功能就是可以对一些资源消耗进行估算，根据估算结果对用户进行一些控制，从而不必真正在运行过程中发现资源瓶颈，如通过优化器估算请求的运行时间，如果超出了某个限制，Oracle资源管理器会阻止它的请求。

以上就是Oracle资源管理器能够实现的几大功能，不过要想在实际过程中对HIS应用资源进行合理的管理，我们还要了解这些功能实现的具体细节和方式，以及对它们合理的运用和组合，才能实现真正的有效管理的目的。

2.4. 资源管理器的组成元素

我们前面介绍了，Oracle资源管理主要由资源使用组，资源计划和资源计划指令三个部分构成，这也是资源管理构成的三个主要的元素，接下来我们就分别对这三个元素进行介绍。

l 资源使用组（Resource Consumer Groups）

资源使用组是由许多用户会话组成，这些会话有相同的资源使用请求。新创建一个会话时，资源管理器会自动或者根据你的指定把它分配到某个组，你可以对这个组进行资源限制和分配，从而对该组的所有会话进行配置，一个用户可以隶属于多个组，但一个会话同一时间只能隶属于一个组，Oracle资管理器中默认有三类特别的组是系统组，它们不能被修改或删除，它们的名称和所起的作用如下表：

组名称	作用
SYS_GROUP	所有通过SYS和SYSTEM用户创建的会话的默认组，它可以设置会话资源使用规则。
DEFAULT_CONSUMER_GROUP	所有非SYS和SYSTEM用户创建会话的默认组，它可以设置会话资源使用规则，但是不能设置命名资源计划指令。
OTHER_GROUP	OTHER_GROUP不能算是一个独立的资源使用者组，准确的说应该算是资源使用组其它原则，当前非活动资源计划的会话都属于该资源使用组，它必须有一个资源计划指令中指定每一个计划。

除了以上三个系统默认的资源使用组，用户可以根据自己的需要，创建其它符合业务会话需求的资源使用组，这些组可以单独的命名，然后将相关的会话分配到该组中即可。

l 资源计划指令（Resource Plan Directives）

资源计划指令指定了资源计划和使用组之间的映射关系。同时通过存储过程来实现对资源的分配和限制的功能，如可以通过指令给对应的资源使用组分配一定百分比的总的CPU时间，或者限制一个组内最大活动的会话数等，资源计划和资源计划指令间有着一对多的关系，当然为了避免冲突资源计划中不能包含两条相同的资源计划指令，但是它可以包含多个不同资源的分配指令。

l 资源计划（Resource Plan）

包含一系列指令，这些指令决定了每个使用者组的资源使用分配，在一个数据库中，同一段时间内只能启用一个资源计划，但一个资源计划里面可以包含多个子资源计划，每个资源计划都必须包含给OTHER_GROUP分配的指令，如下图就是一个包含子计划的CPU使用率限制资源计划的例子。



可以看到，‘SALES_TEAM plan’是‘GREAT BREAD plan’子计划，其对应的是‘WHLESALE group’使用组，它的50%CPU的使用率限制是整个资源计划60%的使用限制而定，也就是这里的50%CPU其实最多也就是整个服务器30%CPU的使用率。

3. 典型的资源管理创建

那么说了这么多，如何来创建一个人资源管理模型呢？Oracle提供了两种方式，一种是通过EM创建，图形界面，操作直观而且简单，另外就是通过DBMS包创建，这个相对比较麻烦，要对一些参数有所了解才行，下面我们就演示下2种方式创建资源管理的过程。

3.1. 通过EM创建

以SYS用户登录数据库的EM，确认连接实例，点击【服务器】，就可以看到资源管理操作选项，如下图







这里有【入门】、【使用者组】、【使用者组映射】、【计划】、【设置】、【统计信息】6个选项，我们首先点击【入门】选项，这里面对资源管理器的作用和其它5个选择的作用作了简单的说明，如下：



通过这里的介绍，我们大致知道每个选项的功能，接下来我们就点击【使用者组】开始创建使用者组，点击进去后进入如下主界面，这里面已经有了很多系统初始化创建的使用者组，如AUTO_TASK_CONSUMER_GROUP、BATCH_GROUP等等，这些使用者组的作用在‘说明’列中有简单的介绍，不过我们从中可以看出，资源管理其实默认在数据库创建后就已经在使用，如晚上的统计信息收集、SQL自动调优等，都是建立了资源用户使用组，只是我们日常管理中没有留意而已。



这里我们点击<创建>按钮，进入资源使用者组创建界面，如下图，当然这里可以选择类似创建或者生成DDL语句创建，这个根据使用者自己的需求选择，在使用者组输入创建组的名称，说明那里对组进行简单的说明，可以把角色添加到该组中，也可以通过把用户添加到该组中，如下



在允许在该使用者组中运行的用户那里点击<添加>，为该组添加用户，如下



当然也可以按角色添加，如下



除了上面在创建使用者组的时候，就通过用户和角色指定那些对象属于这个使用者组之外，还可以通过会话的方式来指定，需要在【使用者组映射】中设置，这里提供了6种映射资源用户的方法。这6种映射方法分别是：

oracle用户：指定通过某个特定操作系统用户登录到数据库所产生的session属于某个用户组；

客户机操作系统用户：指定某个特定的客户端计算机名称登录的数据库所产生的session属于某个用户组；

客户机程序：指定某个应用程序登录到数据库所产生的session属于某个用户组。

服务：指定通过某个服务名登录到数据库所产生的session属于某个用户组；

模块：指定通过特定模块登录到数据库所产生的session属于某个用户组；

模块和操作：指定通过特定模块并执行特定动作登录到数据库所产生的session属于某个用户组。



我们可以在这里按照HIS系统运行的一定的规则，把对应的会话指定到不同的使用者组中，你可以通过用户，也可以通过机器名称还可以通过模块和操作等等，注意到这里有个【优先级】，就是有可能你设置的条件有冲突的情况，比如U00001用户在住院的机器上登录，如果你通过用户名映射的门诊窗口使用组，通过计算机机器名映射的住院用户组，那这时候就要根据优先级来判断该会话到底是属于那个资源组，默认情况下，用户的优先级是6，客户机的优先级是9，这个时候就要以优先级更高的用户为准。

对会话进行了资源组的分配，接下来就是要对资源组的资源进行管理，这就需要设置资源计划，我们进入【资源计划】界面，如下：



点击【创建】，进入资源计划创建界面，添加你想创建的计划的名称和说明，然后就是对资源进行分配，当然首先要对应资源使用者组，默认情况下只有一个系统必须的OTHER_GROUPS,点击【修改】按钮，添加上对应你的资源组，如这里添加我们之前创建的窗口用户组，然后就需要对资源进行分配，【一般信息】这里是对CPU的分配，有2种模式百分比和高级，如下：



百分比这个比较简单，我们重点讲下高级，如果选择高级，在资源计划中我们一共可以设置8个CPU使用的优先级，级别1为最高，级别8为最低，如下



注意，在不同级别中CPU的总额不能超过100%。同时，只有在CPU使用率达到100%的时候，这里指定的不同级别所使用的CPU百分值才会生效。也就是说，即使系统完全空闲时，那么Other_Groups的用户登录系统一样也可以使用100%的CPU。而如果当Other_Groups用户在执行操作过程中‘窗口用户组’用户登录数据库，造成系统CPU满负荷运转。那么Oracle会优先为‘窗口用户组’分配CPU，只有当‘窗口用户组’执行完毕后才会为other_group组成员分配CPU。

拿上面的例子来说，假设‘窗口用户组’消耗了系统的50%，那么‘住院用户组’和‘后勤用户组’就只能使用剩下的50%的资源，然后在这个50%的基础上，再进行分配，也就是分配能使用 40%和10%的CPU资源，如果‘住院用户组’和‘后勤用户组’已经完全使用了这些资源，那么作为下一级LEVEL 3的OTHER_GROUPS将不会获得任何CPU的资源。当‘窗口用户组’、‘住院用户组’和‘后勤用户组’总过只消耗了5%的CPU资源，那么作为下一级LEVEL 2的OTHER_GROUPS将会可以消耗95%的CPU资源。

换句话说，LEVEL 2所能获得的全部资源就是LEVEL 1所未能使用的那部分资源。

优先级：LEVEL1 > LEVEL 2 > LEVEL 3……LEVEL N-1>LEVELN

需要强调的一点是OTHER_GROUPS这个资源用户组。任何一个资源计划必须要包括这个OTHER_GROUPS用户组，如果你的资源计划没有包括这个用户组，那么将会得到一个ORA-07453的错误，要求你必须添加此用户组。这个用户组的作用就是作为一个候选项，当一个没有匹配到任何资源用户组的SESSION连接到数据库的时候会自动的匹配到OTHER_GROUPS下面，按照OTHER_GROUPS的资源限定执行SQL。

另外一个需要强调的是用户资源限定的生效条件。拿上面的例子来说，当系统的CPU使用率没有达到100%的时候，‘窗口部门资源计划’这个资源计划并不会生效，各个资源用户也不会按照限定来分配CPU的使用。仅仅当CPU的使用率为100%的时候，资源计划才可以发挥功效，来限制各个资源用户组的CPU分配。这点是常常被大家忽略的，一定特别注意下。

除了CPU的资源分配，还有【并行度】、【会话池】、【还原池】、【阈值】和【空闲时间】的设置，如下为我对‘窗口部门资源计划’的案例资源分配设置情况，整体预览如下：

在日常管理过程中，如果有EM的话，肯定可以非常直观的看到我们资源管理计划的详细情况，如果没有EM方式，建议大家制作一个如下的表格，可以一目了然的展示当前资源管理的设置情况，如下：

组或子计划	CPU资源
Level 1	Level 2	Level 3	组切换	最大并行度	最大会话数	最大空闲时间
窗口用户组	100		终止会话	1	100	600
住院用户组		80%	终止会话	1	100	3600
后勤用户组		20%	切换到：OTHER_GROUPS	1	400	3600
OTHER_GROUPS		100		无限制	无限制	无限制

最后就是把该计划激活，这里已启用自动计划切换，是指可以通过oracle内部的作业调动，使数据库在多个资源计划中进行切换，这里要注意，一个时间段oracle只能有一个资源计划为激活状态，当然，该资源计划可以包含若干子计划，这里我们就不再演示，计划的操作非常简单，如下

一个典型的资源管理创建就完成了，我们可以通过查询v$session会话视图，来观察下目前数据库会话属于那个资源组，可以看到U000001按照我们之前的映射，属于窗口用户组，而且其它没有映射的用户，默认会属于OTHER_GROUPS组，如下：

3.2. 通过DBMS包创建

除了通过EM创建资源管理以外，还可以通过DBMS_RESOURCE_MANAGER包在命令模式下进行创建，执行这个包的用户必须要有ADMINISTER_RESOURCE_MANAGER权限，这个包常用的功能介绍如下：

Procedure	Description
CREATE_SIMPLE_PLAN	创建一个简单的资源计划,包含8个使用者组,在一个步骤中完成。这是开始使用Oracle数据库资源管理器最快的方式。
CREATE_PLAN	创建一个资源计划,并指定它的分配方法。
UPDATE_PLAN	修改一个资源计划
DELETE_PLAN	删除资源计划和指令。
DELETE_PLAN_CASCADE	删除资源计划和及其它的子计划。
CREATE_CONSUMER_GROUP	创建一个用户使用组
UPDATE_CONSUMER_GROUP	修改用户使用组
DELETE_CONSUMER_GROUP	删除用户使用组
CREATE_PLAN_DIRECTIVE	指定资源计划指令,分配资源资源消费者团体或一个计划的子计划。
UPDATE_PLAN_DIRECTIVE	修改计划指令
DELETE_PLAN_DIRECTIVE	删除计划指令
CREATE_PENDING_AREA	创建一个等待区，还可以更改计划模式
VALIDATE_PENDING_AREA	验证变更等待区计划模式
CLEAR_PENDING_AREA	清除所有未决变更等待区
SUBMIT_PENDING_AREA	提交所有更改计划模式
SWITCH_CONSUMER_GROUP_FOR_SESS	切换的使用者组特定的会话
SWITCH_PLAN	设置当前的资源管理器的计划
SET_CONSUMER_GROUP_MAPPING	会话映射到使用者组
SET_CONSUMER_GROUP_MAPPING_PRI	建立会话属性映射的优先事项

从上面的介绍可以看到，如果我们是要建一个最简单的资源管理计划，使用一个CREATE_SIMPLE_PLAN就可以实现，但是这个简单的计划只限制CPU的使用，显然很多时候我们不光要限制CPU还需要限制其它的资源，下面我们就利用包来进创建一个典型的资源管理计划，要想创建资源管理计划，至少要经过下面几个步骤：

Step 1: 建立一个等待区（pendingarea）.

Step 2: 创建、修改或者删除一个用户使用组

Step 3: 创建一个资源计划

Step 4: 创建资源计划指令

Step 5: 验证等待区（pendingarea）

Step 6: 提交等待区（pendingarea）

这里我们看到有所区别，第一步就是要创建一个等待区（pending area）,什么是等待区？等待区是一个暂存区域,您可以创建一个新的资源计划,更新现有计划,或删除一个计划不影响当前正在运行的应用程序。当您创建一个等待区、数据库初始化,然后把现有计划复制到等待区,这样现有计划就可以更新。等待地区做出更改后,您验证等待区域,然后提交。提交后,所有未决变更应用到数据字典,和等待区域清理干净并停用。

如果您尝试创建、更新或删除一个计划(或创建、更新或删除使用者组或资源计划指令)没有首先创建等待区,就会收到一条错误消息。

提交等待区域并不激活您所创建的任何新计划;它只是存储新的或更新的计划信息数据字典。另外同一时间您只能创建一个等待区域 ,直到你提交或清除悬而未决的区域或注销。

第一步：创建一个等待区

使用CREATE_PENDING_AREA包创建等待区，在plsql执行的命令如下：

BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
END;
第二步：创建使用者组

使用CREATE_CONSUMER_GROUP包创建使用者组，在plsql执行下面的命令，创建一个默认的使用者组（备份用户组），如下：

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP (

CONSUMER_GROUP => '备份用户组',

COMMENT        => '该组用户备份时使用');

END;

同样的方法可以创建其它如‘窗口用户组’、‘住院用户组’等，如果要修改或者删除使用者组，就需要用到UPDATE_CONSUMER_GROUP和DELETE_CONSUMER_GROUP包，这里就不再单独介绍。

第三步：创建个资源计划

使用CREATE_PLAN包创建资源计划，在plsql执行如下命令创建一个‘中联资源管理计划’的资源计划，之前我们用EM创建计划的时候CPU使用率用的是分级法，这里我们用比例法（RATIO），如下：

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_PLAN

(PLAN             => '中联资源管理计划',

MGMT_MTH         => 'RATIO',

COMMENT          => 'HIS系统用户资源管理');

END;

同样的如果要修改或者删除资源计划，需要用到UPDATE_PLAN和DELETE_PLAN包，这里也不再单独介绍。

第四步：创建资源计划指令

使用CREATE_PLAN_DIRECTIVE程序创建资源计划指示，这个包的参数比较多，这里不多作介绍，有兴趣的可以下来单独研，用户组还是用我们之前创建的用户组，举个简单的例子：

BEGIN

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE

(PLAN             => '中联资源管理计划',

GROUP_OR_SUBPLAN => '窗口用户组',

COMMENT          => '窗口用户使用者',

MGMT_P1          => 50);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE

(PLAN             => '中联资源管理计划',

GROUP_OR_SUBPLAN => '住院用户组',

COMMENT          => '住院用户使用者',

MGMT_P1          => 20);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE

(PLAN             => '中联资源管理计划',

GROUP_OR_SUBPLAN => '后勤用户组',

COMMENT          => '后勤用户使用者',

MGMT_P1          => 10);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE

(PLAN             => '中联资源管理计划',

GROUP_OR_SUBPLAN => '备份用户组',

COMMENT          => '为备份专门提供的资源',

MGMT_P1          => 10);

DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE

(PLAN            => '中联资源管理计划',

GROUP_OR_SUBPLAN => 'OTHER_GROUPS',

COMMENT          => '其它用户',

MGMT_P1          => 10);

END;

这里只对CPU的比例进行了分配，窗口用户组，住院用户组，后勤用户组, 备份用户组,和OTHER_GROUPS分别分配为50:20:10:10:10，如果会话只存在于窗口用户组和住院用户组,CPU分配的比例就是50：20，这只是最简单的分配，如果涉及到其它资源，比如IO、空闲时间这些，就会要求一旦达到阈值资源组切换方式，这里的切换有SWITCH_TIME, SWITCH_IO_MEGABYTES和SWITCH_IO_REQS等一些参数控制，这些比较设置相对比较复杂，这里就不再举例。

第五步：验证等待区

通过前面的操作我们就完成了资源管理的创建，之后我们就是要验证创建的资源管理是够有效，这就需要我们进行验证，验证的方法就是在VALIDATE_PENDING_AREA看其是否有效，当然验证也必须遵守以下规则，否则会提示错误:

l 不包含任何循环的计划。一个循环发生在辅助方案包含一个指令,引用一个计划,计划层次的辅助方案。例如,一个辅助方案不能参考计划。

l 所有被计划指定的子计划和使用者组必须存在。

l 所有的计划都必须有计划指示,指出计划或使用者组。

l CPU所有的百分比不得超过100。

l 如果一个计划,目前被用作一个活动实例的高级计划不能被删除。

除了这些还有一些参数只能出现在使用者组的计划指示中，不能出现在其它资源计划中如：PARALLEL_DEGREE_LIMIT_P1，ACTIVE_SESS_POOL_P1，SWITCH_GROUP等等，具体可以参见Oracle®
DatabaseAdministrator's Guide11g Release 1 (11.1) Creating a Complex Resource Plan，验证的方法很简单，就是执行下面一条命令,如下：

BEGIN

DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();

END

验证完了并没有生效，如果要生效需要提交等待区，然后切换到所创建的资源管理，也是一个包执行以下：

-----提交等待区

BEGIN

DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();

END;

----切换资源管理

BEGIN

dbms_resource_manager.switch_plan( plan_name => '中联资源管理计划', sid => 'orcl' )

END;

最后就是清除等待区，完成整个资源管理的创建。

BEGIN

DBMS_RESOURCE_MANAGER.CLEAR_PENDING_AREA();

END;

这样一个最简单的通过DBMS包的方式创建资源管理的案例就完成了，如果清除了等待区，要对现有的计划进行调整，还需要重新创建等待区。当然真实环境下这样简单的资源管理肯定会有很多问题，我们需要根据具体的业务特性进行分析后进行设置才是真正有效的资源管理。

4. 资源管理效果案例测试

前面我们对资源管理的理论知识和创建过程进行了介绍，我们来做几个相对简单的资源（空闲时间、执行时间和并行度）管理测试，展示下资源管理的效果。

4.1. 空闲时间和执行时间限制

思路，我们就利用之前创建的用户组，然后分配用户到对用的使用者组中，对该组进行空闲时间和执行时间的限制（60秒），让其中一个用户连接不做任何操作，另外1个用户运行loop.sql脚本，该脚本为死循环脚本，可保持该会话一直处于执行状态，脚本内容如下：

loop.sql脚本如下:
declare
i number;
j number;
begin
i:=0;
loop
j :=sqrt(i);
i :=i+1;
end loop;
end;
/

脚本准备好后，接着我们来看下当前激活的资源计划的管理计划情况，我们这里只关注准备做实验的使用组‘窗口用户组’，资源限制如下：

重点关注红色的几个部分，其中执行时间如果超过60秒，当前会话的用户组就转到‘备份用户组’，设置完成后我们以U000001用户登录数据库，查看下登录会话所属的使用用户组，确认为我们需要的用户组，如下：

可以看到，接着我们一个不做操作，另外一个执行刚才的死循环脚本，等待60秒后，再次查询这个会话，结果如下：

我们可以看到60秒后，执行死循环的会话用户组已经切换到‘备份用户组’上，这个切换不会永久性的，当执行完成后，对资源进行了释放，该会话再次执行其它操作，会切换回原来的使用者组，而另外一个没做任何操作的空闲会话貌似没有什么变化，其实不然，我们到这个会话上去操作会提示ORA-02396: 超出最大空闲时间, 请重新连接，如下：

4.2. 并行度实验

并行度（parallel）是Oracle数据库的一个特有属性，通过合理的运用可以加快查询、备份、创建对象的效率，当然同时付出消耗资源的代价，如果过分的设置并行度可能会导致资源消耗过多，因此我们又是会对并行度进行限制，如下，我们这里对窗口用户组的并行度就进行了限制，最多只能3个并行：

以U000001（窗口用户组）用户登录一个会话1执行下列命令，进行并行度为5的查询

SQL>select /*+parallel(住院费用记录,5) */ * from 住院费用记录;
在会话2中执行下列命令

SQL> selectsid,qcsid,degree from v$px_session；

其中sid为从属进程所对应的SID，QCSID为这些从属进程所对应的父SID，DEGREE表示并行度，如果我们以另外一个用户U000002（非窗口用户组），执行同样的查询语句，得到的结果就不一样，如下：

通过上面的对比我们可以看到，同样是在hints里面指定了5个并行度，但是由于资源管理的限制，前面的在实际执行过程中只能最多3并发度的查询，而后面这个由于不受限制，因此可以按照设置的要求，实现了5个并行度的查询，通过这个事实证明资源管理确实生效。

5. 可应用于HIS系统的资源管理计划

通过上面的案例讲解，其实都是以我们ZLHIS系统为基础的资源管理计划设置，当然真实环境不可能这么简单，如果资源管理计划设置不合理，不但不能起到应有的作用，反而会对实际应用造成一定的影响，如何针对我们的HIS系统进行资源管理，那些情况适合资源管理，我们这里也作一定的分析，希望能够大家一些参考。

5.1. 现有资源和应用评估

如果一个用户服务器资源非常丰富，应用又非常简单，这时候再用资源管理就是多此一举，如果确实资源有限，并且在某些时候出现了资源瓶颈，这时候就要对资源进行管理，但也要根据资源管理的类型，认真评估下当前服务器在运行环境，做到有的放矢，可以简单的列一个表格进行分析。

项目	评估方法	ZLHIS一般情况
服务器资源瓶颈	通过AWR性能报告获取	根据服务器配置（内存、IO）
应用分类	业务分类	门诊、住院、备份、后勤
资源消耗大的操作	业务分析	统计、备份等
资源消耗大的时间段	通过AWR性能报告获取	上午、月末

当然这里只是进行了简单的列举，如果要真正、有效和合理的对资源进行控制，使其发挥最佳的效果，还要作更多的分析才行。

5.2. 典型的HIS资源管理思路

ZLHIS的应用对资源的消耗还是比较有规律，大部分属于OLTP操作，因此除非设计问题，单个操作对性能的瞬时消耗并不大，但是另一部分操作如查询、过滤等会根据条件的差异对性能的消耗有所需求，这部分就是我们重点关注，一般采用2种方式进行管理：

Ø 业务划分法：

这种方式就是我们前面案例采用的方式，根据业务对资源的消耗和需求进行分类，然后根据类别对资源进行管理。

Ø 时间划分法：

如果大家仔细观察数据库alert日志记录可以发现，其实11g开始，oracle默认就是启用了资源管理，采用调度的方式，在晚上启用了，如下日志记录的摘要：

这个自带的资源计划的目的是对后台的一些作业如：统计信息收集、SQL自动优化等资源消耗过大的操作进行管理，其实对于我们ZLHIS系统，道理是一样的，在业务高峰期对一些操作进行管理，避免其对正常业务的影响，这也是一种有效的资源管理方式。

当然创建资源管理计划以上两种方式都不是孤立的，我们需要有效的组合才能做到最佳的应用效果，下面就以一个典型案例来理解如何合理的构建符合用户需求的资源管理方案。

案例是这样去年某市级医院进行三甲资格评审，需要收集大量的信息，为此技术人员为用户订制了非常多的统计报表，这些报表都是大范围的数据统计，由于用户存储IO性能一般，在收集过程中，医院反馈HIS程序操作经常卡顿，通过性能报告发现出现大量IO等待，但是这些统计操作一段时间内又无法限制，为了不影响医院正常业务的使用，需要通过资源管理来限制业务高峰期这些资源消耗性统计操作。

第一步：明确目标

首先我们要明确我们本次资源管理所要达到的目标，控制资源消耗性报表统计在业务高峰期对HIS系统的影响，这点我们首先就要进行分类，HIS业务操作的优先级肯定是最高、其次我们这里只需要对资源消耗性报表统计这类业务进行控制，首先要明确使用者，然后明确控制的范围，才能使得资源管理真正起到效果，同时对其它业务不产生影响。

第二步：确定使用者

前面说了，我们要确定使用者的范围，范围越小，资源管理越有效，同时对其它业务的影响也越小，分析下这次要控制的操作，资源消耗性报表的统计，这些操作肯定只有某些特定用户或者角色才能使用，而且如果能够进一步控制，只有这些特定用户在一些特定的客户端的操作，才可能会执行资源消耗性报表，确定范围后就可以创建资源用户，然后在资源用户组和资源使用者组映射中进行设置。

资源消耗性统计使用者组	用户	角色	特定客户端
U00001 ~ U00002	Zl_评审报表	192.168.4.21 192.168.4.20

第三步：控制范围

这一步就是资源计划的范围，根据资源计划控制的范畴，确定如何对资源进行控制，也就是对资源消耗性报表的特点进行分析，确定阈值指标，同时在确定阈值的过程中确定控制的方式和时间。

时间范围	指标	控制方式
早上：8~12点	执行时间：30分钟（估算）	SQL取消
IO限制（MB）（物理读*块）
限制登录会话数：5 sessions
下午：12点~18点	执行时间：30分钟（估算）	切换到OTHER资源使用者组，只限制CPU的使用率
IO限制（MB）（物理读*块）
其它时间段	不限制	不限制

这里我们特别讲下时间范围:资源管理计划可以通过oracle的内部调度作业窗口进行控制，确定什么时间段激活，激活持续时间等，通过合理的设置调度，可以让资源管理计划按照设定的要求生效和持续时间，如下：

通过这样的设置，就可以按时间控制资源管理，使得管理维度更加精细，也更符合实际业务的应用，满足我们控制业务高峰期资源消耗性报表的使用。

6. 维护视图

资源创建后，肯定随着业务的应用和环境的变更，需要对资源管理计划进行维护和调整，大部分情况都是通过包和EM进行操作，也比较简单，我们这里就不再进行演示，这里介绍下一些常用的查看资源管理计划的视图，这些视图方便大家对资源管理进行管理。

视图	描述
DBA_RSRC_CONSUMER_GROUPS	列出存在在数据库中所有资源使用者组
DBA_RSRC_PLAN_DIRECTIVES	列出存在在数据库中所有资源计划指示。
DBA_RSRC_PLANS	列出存在在数据库中所有资源计划。
DBA_RSRC_GROUP_MAPPINGS	列出所有的会话的各种映射属性。
DBA_RSRC_MAPPING_PRIORITY	列出了每个属性的当前优先级映射.
V$PARALLEL_DEGREE_LIMIT_MTH	显示所有可用的并行度限制资源分配方法
V$RSRC_CONSUMER_GROUP_CPU_MTH	显示所有可用的CPU资源分配方法资源使用者组。
V$RSRC_SESSION_INFO	显示为每个会话数据资源情况，可用于调优和设置资源计划映射用
V$SESSION	列出每个当前会话的会话信息。具体来说,列出了每个当前会话的资源消费者团体的名称。

当然不止这些视图，还有一些不常用的视图如查看资源使用者组历史的V$RSRC_CONS_GROUP_HISTORY、资源计划历史的V$RSRC_PLAN_HISTORY等等，这些就需要各位在实际运用过程中去尝试理解。

7. 存在的不足

当然我们在看到在资源管理的优点的同时，在进行案例构建的时候，也看到了一些不足之处，主要表现在以下几点：

7.1. HIS程序提示窗口不明显

由于资源管理的限制，根据我们的控制方式（特别是SQL取消和会话终止），我们的ZLHIS程序在执行过程中肯定会异常终止，前台表现会弹出错误提示，如下对资源消耗性报表进行控制后，执行报表SQL会提示如下窗口：

这样的提示给操作端人员的感觉就是程序出现了未知错误，如果在管理之前没有进行必要的告知，势必会增加管理员的解释工作量。

7.2. 管理方式的局限

在实际应用过程中，还是会感受到资源管理的一些局限，特别是资源管理的方式上，除了CPU的分配方式外，大部分还是以简单的阈值限制为主，如最简单的IO操作，目前看只能达到阈值就取消操作或者切换到其它会话使用者组，无法保持会话IO在一定限制范围内持续执行，另外目前的分组只能通过会话区分，没有对具体的操作模式进行区分，应该进一步的对DDL操作进行划分，因此现在的资源管理方式对于精细化管理的需求还无法满足。

7.3. 额外的消耗

在启用了资源管理后，资源管理本身会有一定的消耗，如果设置不合理可能会导致额外的性能问题，这在AWR报告中会有显示如下：

可以看到，这些以resmgr：*开头的事件就是资源管理特有的等待事件，如果这些等待事件占据了TOP5，那就证明资源管理设置可能存在问题或者遇到BUG，这样势必导致额外的消耗。

不过综合来说，Oracle资源管理器如果合理的利用确实能够解决HIS业务的一些实际问题，特别是针对一些整体资源本身有限，有启用了大量应用模式的医院，其不失为一种解决问题的措施和方法。

1. 编写参考文献

官方文档：ManagingResource Allocation with Oracle Database Resource Manager

网络博客：http://czmmiao.diandian.com/post/2011-04-18/17026473