偶看新闻个人特长描述:Oracle资源管理1----资源用户组与CPU资源管理详解
来源：百度文库 编辑：偶看新闻 时间：2024/04/26 16:10:12
为什么要使用Oracle资源管理器
当数据库服务器资源由操作系统来分配时，你可能会遇到以下问题：
1、过多的资源开销 ： 当服务器进程数很多时，操作系统进程和数据库服务进程间的来回切换会导致CPU占用率或内存使用率高。
低效的调度 ：操作系统调度数据库服务时占用寄存器，这样做效率很低。
资源分配的不合理 ：操作系统平均分配系统资源给活动的进程（对数据库进程来说），不能判断它们的优先级高低。
不能管理数据库特有的资源 ，例如：并行执行的服务数和活动的会话数。
Oracle资源管理器简介
Oracle资源管理器（Oracle Database Resource Manager，以下简称DBRM）管理数据库资源，为不同的会话分配不同的数据库资源。资源管理器有三个部件组成：资源用户组（Resource consumer group ）、资源规划（Resource plan ）及资源计划指令(Resource plan directives) 。具体描述参见下表
元素
描述
资源使用组
根据会话的资源请求将它们分为一组。RDMB只能为资源用户组指定所能使用的资源， 不能按单个用户进行指定。
资源计划 资源计划包含资源计划系列指令，这些指令就决定了给每个组的资源分配配置。 要执行资源的分配，你只需执行相应的资源计划。
资源计划指令
资源计划指令指定了资源计划和组之间的映射关系，表示某种特定的资源在 用户之间如何分配 。 资源计划和指令间有着一对多的关系，资源计划中不能 包含两条相同的指令。
子资源计划
资源指令除了给组分配资源，还可以为其他资源计划分配资源，被分配资源的计划成为子计划。下图是一个包含子计划的资源计划的例子。
用户资源管理的内部程序包
用户资源管理涉及到的数据包主要有两个：DBMS_RESOURCE_MANAGER和DBMS_RESOURCE_MANAGER _PRIVS。其中包DBMS_RESOURCE_MANAGER主要是用于建立资源计划，建立资源用户组，建立资源分配方法等用户资源相关的管理；而DBMS_RESOURCE_MANAGER _PRIVS的主要用途是进行用户资源管理的权限控制。
对于一个简单的用户资源管理计划来说，仅仅使用DBMS_RESOURCE_MANAGER包就足够了，所以下面仅仅对DBMS_RESOURCE_MANAGER的使用进行详细的说明。
资源管理器的默认设置
默认的三个系统资源计划：internal_plan、internal_quiesce,system_plan。其中internal_plan、internal_quiesce只是一个空壳，里面没有任何资源计划，可以通过对这两个资源计划进行修改来满足我们的需求。而system_plan只对cpu进行了限制。
默认的三个用户组
sys_group：作为sys和system用户的默认用户组。
other_group：如果当前用户不属于当前资源计划中的任何用户组，则会被纳入other_group.任何资源计划都必须包含other_group。
low_group：表示该用户对资源的请求级别是最低的。默认没有用户进入该用户组。
任何一个数据库用户都必须纳入到一个用户组中，该用户组被叫做初始用户组(initial consumer group)。如果没有显示的指定初始用户组，那么该用户的初始用户组为default_consumer_group。
Oracle资源管理
创建资源用户组
其中Scheduling Policy表示在同一用户组中的用户之间如何分配CPU
Round Robin：在用户组成员之间平均分配CPU
Run to Completion：运行时间最长的用户优先获得CPU
进行初始化用户组的设置
用户组与资源的映射关系
资源管理器提供了6种映射资源用户的方法。这6种映射方法分别是，指定通过某个特定操作系统用户登录到数据库所产生的session属于某个用户组；指定某个特定的客户端计算机名称登录的数据库所产生的session属于某个用户组；指定某个应用程序登录到数据库所产生的session属于某个用户组。指定通过某个服务名登录到数据库所产生的session属于某个用户组；指定通过特定模块登录到数据库所产生的session属于某个用户组；指定通过特定模块并执行特定动作登录到数据库所产生的session属于某个用户组。
用户组与资源映射的优先级
由于我们可以设置登录操作系统的用户所对应的用户组（比如oracle用户对应OS_GRP），同时设置登录数据库的用户对应的用户组（比如用户HR属于OLTP_GRP）。因此，就存在一个问题：如果两者的设置矛盾怎么办？在资源管理器中通过指定映射关系的优先级来解决这个问题
创建资源计划
Active this plan：激活该资源计划。
我们也可以在sqlplus里激活该资源计划
SQL> alter system set resource_manager_plan='MY_DAY_PLAN';
System altered.
SQL> show parameter resource_manager_plan
NAME TYPE VALUE
------------------------------------ ----------------------------- ------------------------------
resource_manager_plan string MY_DAY_PLAN
Automatic Plan Switch Enabled：表示该计划激活后可以被其他的时间窗(window)激活其他计划。
在资源计划中我们一共可以设置8个CPU使用的优先级，级别1为最高，级别8为最低。注意，在不同级别中CPU的总额不能超过100%。同时，只有在CPU使用率达到100%的时候，这里指定的不同级别所使用的CPU百分值才会生效。也就是说，即使系统完全空闲时，那么other_group的用户登录系统一样也可以使用100%的CPU。而如果当other_group用户在执行操作过程中sys_group组用户登录数据库，造成系统CPU满负荷运转。那么Oracle会优先为sys_group组分配CPU，只有当sys_group执行完毕后才会为other_group组成员分配CPU。
拿上面的例子来说，假设OLTP_GRP和BATCH_GRP分别获得了系统的80%和20%的CPU资源，那么作为下一级LEVEL 3的OTHER_GROUPS将不会获得任何CPU的资源。当BATCH_GRP和OLTP_GRP分别获得了系统的40%和10%的CPU资源，那么作为下一级LEVEL 2的OTHER_GROUPS将会获得50%的CPU资源。
换句话说，LEVEL 3所能获得的全部资源就是LEVEL 2所未能使用的那部分资源。
优先级：LEVEL1 > LEVEL 2 > LEVEL 3……LEVEL N-1>LEVEL N
需要强调的一点是OTHER_GROUPS这个资源用户组。任何一个资源计划必须要包括这个OTHER_GROUPS用户组，如果你的资源计划没有包括这个用户组，那么将会得到一个ORA-07453的错误，要求你必须添加此用户组。这个用户组的作用就是作为一个候选项，当一个没有匹配到任何资源用户组的SESSION连接到数据库的时候会自动的匹配到OTHER_GROUPS下面，按照OTHER_GROUPS的资源限定执行SQL。
另外一个需要强调的是用户资源限定的生效条件。拿上面的例子来说，当系统的CPU使用率没有达到100%的时候，MY_DAY_PLAN这个资源计划并不会生效，各个资源用户也不会按照限定来分配CPU的使用。仅仅当CPU的使用率为100%的时候，资源计划才可以发挥功效，来限制各个资源用户组的CPU分配。这点是常常被大家忽略的，一定特别注意下。
使用DBMS_RESOURCE_MANAGER包创建的sql如下
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_plan( ' MY_DAY_PLAN ', '');
dbms_resource_manager.create_plan_directive(
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' SYS_GROUP ',COMMENT => ' ',CPU_P1 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' OLTP_GRP ',COMMENT => ' ',CPU_P1 => 0,CPU_P2=>80);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' BATCH_GRP ',COMMENT => ' ',CPU_P1 => 0,CPU_P2=>20);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' OTHER_GROUPS ',COMMENT => ' OTHER_GROUPS ',CPU_P1 => 0, CPU_P2 => 0,CPU_P3=>100);
dbms_resource_manager.submit_pending_area();
dbms_resource_manager.switch_plan( plan_name => ' MY_DAY_PLAN ', sid => 'orcl' );
END;
验证资源计划是否对CPU进行分配
思路，让BATCH_GRP和OLTP_GRP分别运行dead.sql脚本，该脚本为死循环的开方脚本，可消耗系统cpu而不是消耗系统内存。
dead.sql脚本如下
[oracle@dg1 ~]$ cat dead.sql
declare
i number;
j number;
begin
i:=0;
loop
j :=sqrt(i);
i :=i+1;
end loop;
end;
/
通过下列语句查看当前会话的资源用户组
SQL> conn hr/hr;
Connected.
SQL> select resource_consumer_group from v$session
2 where sid =(select sid from v$mystat where rownum=1);
RESOURCE_CONSUMER_GROUP
------------------------------------------------------------------------------------------------
OLTP_GRP
SQL> show user;
USER is "SCOTT"
SQL> select resource_consumer_group from v$session
2 where sid =(select sid from v$mystat where rownum=1);
RESOURCE_CONSUMER_GROUP
--------------------------------------------------------------------------------
BATCH_GRP
两个会话同时执行dead.sql
SQL> @/home/oracle/dead.sql
可以看到BATCH_GRP用户组消耗了1795.99秒的CPU时间，可以看到OLTP_GRP用户组消耗了7125.53秒的CPU时间，同时图饼也显示BATCH_GRP消耗20％的CPU资源，OLTP_GRP消耗80％的CPU资源。
当数据库服务器资源由操作系统来分配时，你可能会遇到以下问题：
1、过多的资源开销 ： 当服务器进程数很多时，操作系统进程和数据库服务进程间的来回切换会导致CPU占用率或内存使用率高。
低效的调度 ：操作系统调度数据库服务时占用寄存器，这样做效率很低。
资源分配的不合理 ：操作系统平均分配系统资源给活动的进程（对数据库进程来说），不能判断它们的优先级高低。
不能管理数据库特有的资源 ，例如：并行执行的服务数和活动的会话数。
Oracle资源管理器简介
Oracle资源管理器（Oracle Database Resource Manager，以下简称DBRM）管理数据库资源，为不同的会话分配不同的数据库资源。资源管理器有三个部件组成：资源用户组（Resource consumer group ）、资源规划（Resource plan ）及资源计划指令(Resource plan directives) 。具体描述参见下表
元素
描述
资源使用组
根据会话的资源请求将它们分为一组。RDMB只能为资源用户组指定所能使用的资源， 不能按单个用户进行指定。
资源计划 资源计划包含资源计划系列指令，这些指令就决定了给每个组的资源分配配置。 要执行资源的分配，你只需执行相应的资源计划。
资源计划指令
资源计划指令指定了资源计划和组之间的映射关系，表示某种特定的资源在 用户之间如何分配 。 资源计划和指令间有着一对多的关系，资源计划中不能 包含两条相同的指令。
子资源计划
资源指令除了给组分配资源，还可以为其他资源计划分配资源，被分配资源的计划成为子计划。下图是一个包含子计划的资源计划的例子。
用户资源管理的内部程序包
用户资源管理涉及到的数据包主要有两个：DBMS_RESOURCE_MANAGER和DBMS_RESOURCE_MANAGER _PRIVS。其中包DBMS_RESOURCE_MANAGER主要是用于建立资源计划，建立资源用户组，建立资源分配方法等用户资源相关的管理；而DBMS_RESOURCE_MANAGER _PRIVS的主要用途是进行用户资源管理的权限控制。
对于一个简单的用户资源管理计划来说，仅仅使用DBMS_RESOURCE_MANAGER包就足够了，所以下面仅仅对DBMS_RESOURCE_MANAGER的使用进行详细的说明。
资源管理器的默认设置
默认的三个系统资源计划：internal_plan、internal_quiesce,system_plan。其中internal_plan、internal_quiesce只是一个空壳，里面没有任何资源计划，可以通过对这两个资源计划进行修改来满足我们的需求。而system_plan只对cpu进行了限制。
默认的三个用户组
sys_group：作为sys和system用户的默认用户组。
other_group：如果当前用户不属于当前资源计划中的任何用户组，则会被纳入other_group.任何资源计划都必须包含other_group。
low_group：表示该用户对资源的请求级别是最低的。默认没有用户进入该用户组。
任何一个数据库用户都必须纳入到一个用户组中，该用户组被叫做初始用户组(initial consumer group)。如果没有显示的指定初始用户组，那么该用户的初始用户组为default_consumer_group。
Oracle资源管理
创建资源用户组
其中Scheduling Policy表示在同一用户组中的用户之间如何分配CPU
Round Robin：在用户组成员之间平均分配CPU
Run to Completion：运行时间最长的用户优先获得CPU
进行初始化用户组的设置
用户组与资源的映射关系
资源管理器提供了6种映射资源用户的方法。这6种映射方法分别是，指定通过某个特定操作系统用户登录到数据库所产生的session属于某个用户组；指定某个特定的客户端计算机名称登录的数据库所产生的session属于某个用户组；指定某个应用程序登录到数据库所产生的session属于某个用户组。指定通过某个服务名登录到数据库所产生的session属于某个用户组；指定通过特定模块登录到数据库所产生的session属于某个用户组；指定通过特定模块并执行特定动作登录到数据库所产生的session属于某个用户组。
用户组与资源映射的优先级
由于我们可以设置登录操作系统的用户所对应的用户组（比如oracle用户对应OS_GRP），同时设置登录数据库的用户对应的用户组（比如用户HR属于OLTP_GRP）。因此，就存在一个问题：如果两者的设置矛盾怎么办？在资源管理器中通过指定映射关系的优先级来解决这个问题
创建资源计划
Active this plan：激活该资源计划。
我们也可以在sqlplus里激活该资源计划
SQL> alter system set resource_manager_plan='MY_DAY_PLAN';
System altered.
SQL> show parameter resource_manager_plan
NAME TYPE VALUE
------------------------------------ ----------------------------- ------------------------------
resource_manager_plan string MY_DAY_PLAN
Automatic Plan Switch Enabled：表示该计划激活后可以被其他的时间窗(window)激活其他计划。
在资源计划中我们一共可以设置8个CPU使用的优先级，级别1为最高，级别8为最低。注意，在不同级别中CPU的总额不能超过100%。同时，只有在CPU使用率达到100%的时候，这里指定的不同级别所使用的CPU百分值才会生效。也就是说，即使系统完全空闲时，那么other_group的用户登录系统一样也可以使用100%的CPU。而如果当other_group用户在执行操作过程中sys_group组用户登录数据库，造成系统CPU满负荷运转。那么Oracle会优先为sys_group组分配CPU，只有当sys_group执行完毕后才会为other_group组成员分配CPU。
拿上面的例子来说，假设OLTP_GRP和BATCH_GRP分别获得了系统的80%和20%的CPU资源，那么作为下一级LEVEL 3的OTHER_GROUPS将不会获得任何CPU的资源。当BATCH_GRP和OLTP_GRP分别获得了系统的40%和10%的CPU资源，那么作为下一级LEVEL 2的OTHER_GROUPS将会获得50%的CPU资源。
换句话说，LEVEL 3所能获得的全部资源就是LEVEL 2所未能使用的那部分资源。
优先级：LEVEL1 > LEVEL 2 > LEVEL 3……LEVEL N-1>LEVEL N
需要强调的一点是OTHER_GROUPS这个资源用户组。任何一个资源计划必须要包括这个OTHER_GROUPS用户组，如果你的资源计划没有包括这个用户组，那么将会得到一个ORA-07453的错误，要求你必须添加此用户组。这个用户组的作用就是作为一个候选项，当一个没有匹配到任何资源用户组的SESSION连接到数据库的时候会自动的匹配到OTHER_GROUPS下面，按照OTHER_GROUPS的资源限定执行SQL。
另外一个需要强调的是用户资源限定的生效条件。拿上面的例子来说，当系统的CPU使用率没有达到100%的时候，MY_DAY_PLAN这个资源计划并不会生效，各个资源用户也不会按照限定来分配CPU的使用。仅仅当CPU的使用率为100%的时候，资源计划才可以发挥功效，来限制各个资源用户组的CPU分配。这点是常常被大家忽略的，一定特别注意下。
使用DBMS_RESOURCE_MANAGER包创建的sql如下
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_plan( ' MY_DAY_PLAN ', '');
dbms_resource_manager.create_plan_directive(
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' SYS_GROUP ',COMMENT => ' ',CPU_P1 => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' OLTP_GRP ',COMMENT => ' ',CPU_P1 => 0,CPU_P2=>80);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' BATCH_GRP ',COMMENT => ' ',CPU_P1 => 0,CPU_P2=>20);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(PLAN=>'MY_DAY_PLAN',GROUP_OR_SUBPLAN => ' OTHER_GROUPS ',COMMENT => ' OTHER_GROUPS ',CPU_P1 => 0, CPU_P2 => 0,CPU_P3=>100);
dbms_resource_manager.submit_pending_area();
dbms_resource_manager.switch_plan( plan_name => ' MY_DAY_PLAN ', sid => 'orcl' );
END;
验证资源计划是否对CPU进行分配
思路，让BATCH_GRP和OLTP_GRP分别运行dead.sql脚本，该脚本为死循环的开方脚本，可消耗系统cpu而不是消耗系统内存。
dead.sql脚本如下
[oracle@dg1 ~]$ cat dead.sql
declare
i number;
j number;
begin
i:=0;
loop
j :=sqrt(i);
i :=i+1;
end loop;
end;
/
通过下列语句查看当前会话的资源用户组
SQL> conn hr/hr;
Connected.
SQL> select resource_consumer_group from v$session
2 where sid =(select sid from v$mystat where rownum=1);
RESOURCE_CONSUMER_GROUP
------------------------------------------------------------------------------------------------
OLTP_GRP
SQL> show user;
USER is "SCOTT"
SQL> select resource_consumer_group from v$session
2 where sid =(select sid from v$mystat where rownum=1);
RESOURCE_CONSUMER_GROUP
--------------------------------------------------------------------------------
BATCH_GRP
两个会话同时执行dead.sql
SQL> @/home/oracle/dead.sql
可以看到BATCH_GRP用户组消耗了1795.99秒的CPU时间，可以看到OLTP_GRP用户组消耗了7125.53秒的CPU时间，同时图饼也显示BATCH_GRP消耗20％的CPU资源，OLTP_GRP消耗80％的CPU资源。