此文已由作者赵欣授权网易云社区发布。
欢迎访问网易云社区,了解更多网易技术产品运营经验。
从Oracle8i开始oracle提供了一个叫Oracle Databae Resource Manager的新特性,以让Oracle定义数据库资源的使用以及监控数据库各Users的资源利用情况;并且该特性仅在企业版中才被支持。
Oracle数据库资源管理器是一个数据库资源管理机制来控制系统资源如何被分配到数据库,这使管理员能够更多控制以及干涉资源管理决策。
如果数据库的资源分配由操作系统决定,会遇到如下问题:
(1) Excessive overhead过度的开销
(2) Inefficient scheduling低效率的调度
(3) Inappropriate allocation of resources不适当的资源分配
(4) Inability to manager database-specific resources,such as parallel execution servers and active sessions没有办法管理特殊的数据库资源,比如并行服务执行等
Resource manager可以在每个工作负载的基础上管理多个方面的会话行为,可以做到如下:
(1) 保护某个session分配到最小的CPU资源,而不管系统的压力和用户的数量。
(2) 针对不同的用户和应用分配不同比例的CPU时间。
(3) 限制用户组成员任何操作的并行深度。
(4) 管理并行队列中并行的执行顺序,紧急应用的并行可以优先于其他低优先级的并行。
(5) 限制group中用户可以使用并行的数量,这样可以确保所有可用的并行资源不会被分配到某一个group用户。
(6) 创建active session pool。Active session pool由同一个group中用户session被允许并发active的最大数量组成。附加的session可以超过这个限制执行,当job队列中断后,可以指定超时时间。
(7) 通过如下方法管理和调用runaway session
Ø 修改group可以消耗CPU资源的比率值。
Ø 检测session或者call是否超过了指定CPU或者I/O的限制。然后自动的中断session或call,或切换其小于consumer group中指定的CPU资源数。
(8) 阻止优化器估算其运行时间超过指定限制的操作。
(9) 限制session可以被空闲的时间。
(10) 指定一个组中用户可以使用的最大undo空间
(11) 根据工作量的改变允许数据库使用不同的resource plan。可以动态的修改这些resource plan。也可以在Scheduler中使用resource plan。
从8I开始提供第一个resource manager的功能开始,到11G,期间所有的版本都有不同程度的更新变化。从下表我们可以看出历代版本的dbrm功能进化:
8i |
|
9i |
|
10G |
|
11G |
以上功能的相关解释如下:
Parallel_degree_limit:并行度限制
CPU Time:cpu的运算时间
Active Session Pool:允许一个资源使用组限制最大的活动会话,一旦达到这个数值后面的请求就会排队等待现有会话结束在激活。使用的是先进先出算法以及计数周期机制。
Maximum Estimated Execution Time:一个事务初始化时资源管理器会估计该事务执行结束需要的时间,一旦超过该时间相关事务会被终止。
Automatic Consumer Group Switching:从9i开始oracle允许会话超过一个特殊的门限值时自动切换到低优先级的资源使用组 。
UNDO_POOL: 用来指定资源使用组能够使用的最大undo值。
Resource Plan Directive Interactions:如果一个多重资源计划指令和一个单独的资源使用组联系在一起,最终结果依照如下规则
l The minimum parallel degree limit of the incoming values will be used
l The sum of the incoming active session pools will be used.
l The minimum incoming active session pool timout will be used.
l The smallest incoming switch time.
l The value TRUE overrides FALSE for the switch estimate.
l Resource manager chooses between multiple switch groups.
l If a session is switched to a new consumer group it executes regardless of the status of the active session pool in the new group.
l The most restrictive incoming maximum estimated execution time is used.
Modified Views:部分8i中的视图在9I中被修改,比如
l CURRENT_QUEUE_DURATION字段被加到VSESSIONandVMYSESSION视图中用来显示被排队的会话秒数或者0
l QUEUE_LENGTH 和 CURRENT_UNDO_CONSUMPTION被加到V$RSRC_CONSUMER_GROUP用于显示及时队列长度以及UNDO消耗
Setting Consumer Group Switch Times Per Call:在10G中新增加用来解决一个客户端使用的资源不会影响同一个会话中新的客户端。
CANCEL_SQL and KILL_SESSION:用于增强自动切换资源组的功能,一旦超过了SWITCH_TIME 限制,将会取消sql杀掉会话。
Setting Consumer Group Idle Timeouts:The MAX_IDLE_TIME 用于定义该资源使用组中会话可以保持idle状态的最大时间; MAX_IDLE_BLOCKER_TIME用于定义该资源使用组中某个会话阻塞了其他会话资源后可以保持idle状态的最大时间。每分钟pmon进程会检测一次该值是否到达门限。
Automatically Assigning Resource Consumer Groups to Sessions:从10G开始的一种映射会话到资源组的方法,以使得资源组的利用更简单灵活。
I/O Calibration :通过执行一个I / O密集型只读工作负载来评估数据库服务器存储系统的I / O性能。这只能运行在非高峰期,确保校准不影响生产工作负载,以及生产工作负载不影响该结果的校准。该功能只能在异步IO被激活的时候才能生效。
Per Session I/O Limits:从11G开始oracle允许基于IO阀值来实现资源使用组自动切换
Built-In Resource Plans:通过嵌入式的资源计划来提供基于批量操作的OLTP优先级
本文后续数据库研究和参考均以11G R2版本为参考
Dbrm由Resource consumer group、Resource plan和Resource plan directive组成。
Resource plan:资源计划包含一系列指令,这些指令就决定了给每个组的资源分配配置。要执行资源的分配,只需执行相应的资源计划。resource plan 是预先定义好的,可以创建任意个resourceplan,但是在同一时刻只有一个resource plan 是激活的。当resource plan 是激活时,它的每个子resource plan 指令控制每个资源分配到不同的consumer group。 每个plan 必须包含一个指令,其分配资源到OTHER_GROUPS 的consumer group。 OTHER_GROUPS 适用于所有的session,即使不是当前激活的plan。
Resource plan directive:资源计划指令指定了资源计划和用户组之间的映射关系,Resource Manager根据当前active resource plan的Resource Plan Directive设置分配资源到consumer groups。Resource Plan和Resource Plan Directive是父子关系,每个Resource Plan Directive只对应一个consumer group。
Resource consumer group:根据会话的资源请求将它们分为不同的资源使用组。DBRM按组管理会话的资源分配,而不是按单个的会话。资源使用组由许多用户会话组成,这些会话有相同的资源使用请求。新创建一个会话时,RDMB会根据你的设定自动把它分配到某个组。数据库管理员还可以手动的调整某个会话所属的组。有三类特别的组是系统组(SYS_GROUP、DEFAULT_CONSUMER_GROUP、OTHER_GROUP),它们不能被修改或删除。
Oracle database resource manager整个的结构图如下:
大致工作流程如下
1. 定义资源计划
2. 根据激活生效的资源,通过资源计划指令对应资源使用组的资源分配控制
3. 用户会话根据相关规则对应到资源使用组,从而受到资源计划的资源分配控制
从结构图和工作流程我们可以看出,资源计划的设置是整个DBRM的核心。
官方文档有介绍两个资源计划的例子:
Ø 一个简单的资源计划
这是一个在白天运行的资源分配计划,它包含OLTP(online transaction processing)应用和报表系统。其中OLTP应用分配75%的CPU时间,报表系统分配15%的CPU时间,剩下10%为OTHER_GROUPS分配。
Ø 子资源计划
资源指令除了给组分配资源,还可以为其他资源计划分配资源,被分配资源的计划成为子计划。
GREAT_BREAD 计划按照如下分配资源:
l 20%的CPU资源用于MARKET用户组
l 60%的CPU 资源给子计划SALES_TEAM,而SALES_TEAM子计划在WHOLESALE和RETAIL用户组之间公平的分配划分它的资源
l 20%的CPU资源分配给子计划DEVELOP_TEAM,而DEVELOP_TEAMDEVELOP_TEAM子计划在BREAD和MUFFIN用户组之间公平的分配它的资源
Dbrm以下几种资源类型:
1. CPU
为了管理CPU 资源,Resource Manager 在consumer groups和未分配的受限的CPU资源中进行资源分配,也可以设定特定的CPU 资源来分配给某个特定的用户组。
Resource Manager 提供了如下两种resourceplan directive 属性来控制CPU 资源的分配:
ManagementAttributes,管理属性可以用来指定分配给consumer groups 和 subplans的CPU 资源. 最多提供8个级别的CPU 资源分配策略。consumer groups 和subplans 可以在level2级别获取level 1未分配或者在level 1级别未完全使用的资源。在level 3的资源用户可以获取level 1和level 2 级别未分配的资源。管理的属性是MGMT_Pn,这里的n是1到8的整数,用来指定CPU资源分配的级别。
Consumer Group |
Level 1 CPU Allocation |
Level 2 CPU Allocation |
Level 3 CPU Allocation |
HIGH_GROUP |
60% |
|
|
LOW_GROUP |
|
50% |
|
MAINT_SUBPLAN |
|
50% |
|
OTHER_GROUPS |
|
|
100% |
上图的例子中level1的high_group使用了60%,剩余的40%cpu资源被平均分配给low_group和maint_subplan,如果在level2 cpu仍未被用完,那么剩余的cpu资源将全部给level3的other_groups使用。需要注意的是在某个特定的级别上,CPU分配并不固定,如果消耗完CPU资源,那么剩余的CPU 将被分配到剩下的consumer groups和subplans。
MaximumUtilization Limit,MAX_UTILIZATION_LIMIT可以限制resource group上CPU 资源的最大值,是可选的选项,如果没有设置这个属性,那么默认没有限制,即可以使用100%的的CPU 资源,也可以单独使用MAX_UTILIZATION_LIMIT,不指定level。
Consumer Group |
Level 1 CPU Allocation |
Level 2 CPU Allocation |
Level 3 CPU Allocation |
Maximum Utilization Limit |
HIGH_GROUP |
60% |
|
|
|
LOW_GROUP |
|
50% |
|
75% |
MAINT_SUBPLAN |
|
50% |
|
50% |
OTHER_GROUPS |
|
|
100% |
75% |
上图的例子中,假设HIGH_GROUP使用了10%,那么在level2 上LOW_GROUP和MAINT_SUBPLAN 可以使用90%,如果LOW_GROUP 使用了20%,那么MAINT_SUBPLAN就有70%可用,但是因为MAX_UTILIZATION_LIMIT设置为50%,所以即使有更多的可用资源,也只能使用50%。
2. Degree of Parallelism Limit
可以限制同一个consumer group中最大的并行数,degree of parallelism是同一个操作的并行执行的数量,使用 PARALLEL_DEGREE_LIMIT_P1 指令来指定consumergroup的并行限制。degree of parallelism limit 仅对consumer group中的一个操作限制,其不限制同一个consumer group中所有操作的并行度。但可以通过PARALLEL_DEGREE_LIMIT_P1和PARALLEL_TARGET_PERCENTAGE指令属性来实现该功能。
这个功能仅从oracle 11gR2开始使用。如果一个consumer group使用了所有的并行,那么当其他consumer group的高优先级的并行就没有parallel server来分配,可以通过限制特定consumer group的并行数来避免这个问题。使用PARALLEL_TARGET_PERCENTAGE指令属性可以指定consumer group可以使用最大parallel server pool的比率。例如,假设总共的parallel server是32,在初始化参数里设置MY_GROUP consumer group的PARALLEL_SERVERS_TARGET为50%,那么该组group最大就只能使用16个parallel servers。在RAC 环境里,target number 的并行数是所有节点(PARALLEL_TARGET_PERCENTAGE *PARALLEL_SERVERS_TARGET /100)的总和。在RAC下,如果consumer group没有并行语句运行,那么第一个并行语句运行超过 PARALLEL_TARGET_PERCENTAGE指定的参数。在RAC 环境下,PARALLEL_TARGET_PERCENTAGE 应用于整个集群,而不是一个单实例。
ManagingParallel Statement Queuing Using Parallel Target Percentage,Oracle为每个用户组维护一个独立的并行队列。
Parallel Queue Timeout
这个功能从Oracle 11gR2以后才有。当使用并行队列时,如果数据库没有足够的资源来执行并行,那么并行就会进入队列,直到有资源时才变成可用。但是存在一种情况,就是并行等待了很长的时间才执行,可以设置并行在队列中的最长等待时间来避免这种问题。
4. Active Session Pool with Queuing
active session pool可以控制单个用户组中最大并发的active会话数量。(active会话是活动的事务或者SQL 语句进程,一个active session 是一个事务或一个打开的游标,且游标没有空闲超过5秒。即使会话是被阻塞的,也可以认为是active会话。如等待I/O)。 当active session pool 满了之后,session 就会尝试存放到队列里,当有一个active session 完成,队列中的第一个session 就会移除队列并执行,可以指定队列中session的超时时间,如果超过时间就会抛出错误。在OLTP环境下,建议不设置active sessin 的限制。
5. Automatic Consumer Group Switching
自动用户组切换允许一个用户会话在运行了指定的时间后自动切换到不同的用户组。会话所切换到的组称为切换组,时间限制称为切换时间。自动用户组切换发生在以下两种情况:
Ø 一个会话属性被更改,导致新的mapping规则生效时
Ø 一个会话超过所在用户组的CPU或者I/O的资源消耗限制
6. CancelingSQL and Terminating Sessions
通过使用cancel_sql 或kill_session作为切换组,可以指示取消或中止长时间运行的sql语句,甚至是取消或终止完整的会话。
7. Execution Time Limit
用于指定操作最大的执行时间,如果超过这个时间,操作将终止。
8. Undo Pool
用于为每个用户组指定undo pool,undo pool控制一个用户组总的undo数量。当该用户组总的undo生成量超过了这个限制,那么当前的事务操作生成的undo会被中断。用户组内的所有成员都无法执行数据操作,只有undo pool空间足够时,才能继续。
9. IdleTime Limit
用于指定会话空闲时间,当超过这个时间时,会话被中断。还可以指定仅终止阻塞其他会话的空闲会话。
免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐
更多网易技术、产品、运营经验分享请点击。