最新博客
最新资源下载
ORACLE DBRM探讨（4）
勿忘初心2018-11-28 09:50此文已由作者赵欣授权网易云社区发布。
欢迎访问网易云社区，了解更多网易技术产品运营经验。
第六章 单instance数据库使用DBRM实例
6.1 限制CPU最大使用率
创建未决区SQL> EXECUTE dbms_resource_manager.create_pending_area;
创建用户组
SQL> EXECUTE dbms_resource_manager.create_consumer_group (consumer_group => 'g2', comment => 'g2');
创建资源计划
SQL> EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN=> 'g2test',CPU_MTH => 'EMPHASIS',COMMENT => ' g2 plan');
创建资源计划指令
SQL> BEGIN
dbms_resource_manager.create_plan_directive
(plan => 'g2test',
group_or_subplan => 'G2',
comment => 'Limit cpu time',
MAX_UTILIZATION_LIMIT => 30);
dbms_resource_manager.create_plan_directive
(plan => 'g2test',
group_or_subplan => 'OTHER_GROUPS',
comment => 'other time'
);
End;
/这里需要记住每个plan中都必须有other_groups用户组，并且用命令指定时需要有COMMENT行
验证未决区SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
提交未决区SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
指派用户
SQL> EXECUTE dbms_resource_manager_privs.grant_switch_consumer_group('G2','G2', true);
SQL> EXECUTE dbms_resource_manager.set_initial_consumer_group ('G2','G2');
启动资源计划SQL> ALTER SYSTEM SET resource_manager_plan='g2test';
模拟方式 |
未限制cpu情况 |
限制cpu最高可用值 |
模拟oracle单纯cpu高使用率 |
50% |
控制在30% |
手工模拟CBC latch情况下cpu高使用率 |
85% |
30%以下 |
使用测试软件发起多个session的oltp情况下cpu高使用率 |
wai特别高 |
无效果 |
从上述情况可以看出一旦磁盘子系统的IO出现瓶颈，假设会话本身仅消耗5%的cpu，而实际等待io的cpu消耗可能会有30%以上，而dbrm是无法控制限制等待IO所消耗的cpu。
6.2 限制MAX_IDLE_BLOCKER_TIME
EXECUTE dbms_resource_manager.create_pending_area;
EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN=> 'g2test2',CPU_MTH => 'EMPHASIS',COMMENT => ' g2 plan2');
SQL> BEGIN
dbms_resource_manager.create_plan_directive
(plan => 'g2test2',
group_or_subplan => 'G2',
comment => 'blocker time',
max_idle_blocker_time => 3);
dbms_resource_manager.create_plan_directive
(plan => 'g2test2',
group_or_subplan => 'OTHER_GROUPS',
comment => 'other time'
);
End;
/SQL> EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
SQL> EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
SQL> EXECUTE dbms_resource_manager_privs.grant_switch_consumer_group('G2','G2', true);
SQL> EXECUTE dbms_resource_manager.set_initial_consumer_group ('G2','G2');
启动资源计划SQL> ALTER SYSTEM SET resource_manager_plan='g2test2';
模拟两个会话同时更改一个字段值，造成一个会话被另一个阻塞
很明显14将140 blocked了
3秒后14会话被自动disconnected，通过select sid from v$mystat where rownum=1尝试查看该会话sid报错：
6.3 限制资源用户组内活动会话同时打开的最大数量
使用更新资源计划指令的方式来实现限制用户组内活动会话的最大数量为3
BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.update_plan_directive
(plan => 'g2test5',
group_or_subplan => 'G2',
new_comment => 'sess pool',
new_ACTIVE_SESS_POOL_P1 => 3);
dbms_resource_manager.validate_pending_area();
dbms_resource_manager.submit_pending_area();
dbms_resource_manager_privs.grant_switch_consumer_group('G2','G2', true);
dbms_resource_manager.set_initial_consumer_group ('G2','G2');
END;
/
启动资源计划SQL> ALTER SYSTEM SET resource_manager_plan='g2test2';
首先发起三个连续做cpu运算的会话，然后打开第四个g2用户会话会发现进不去sqlplus
select name,active_sessions,cpu_wait_time, consumed_cpu_time,current_undo_consumption
FROM v$rsrc_consumer_group; 发现仅有3个G2用户会话是active
使用select username,status from v$session where USERNAME ='G2';有4个G2用户会话active
再启动一个g2用户会话，同样会hang住进不去sqlplu
但是查找资源组的active会话仍然为3个
说明整个oracle的dbrm是通过在内部资源组来控制显示active的实际情况，通过普通的v$session视图显示的并不准确
6.4 限制并行度
BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_plan(plan=>'g2test4',cpu_mth=>'emphasis',comment=>'g2plan4');
dbms_resource_manager.create_plan_directive
(plan => 'g2test4',
group_or_subplan => 'G2',
comment => 'parallel limit',
PARALLEL_DEGREE_LIMIT_P1 => 2);
dbms_resource_manager.create_plan_directive
(plan => 'g2test4',
group_or_subplan => 'OTHER_GROUPS',
comment => 'other time');
dbms_resource_manager.validate_pending_area();
dbms_resource_manager.submit_pending_area();
dbms_resource_manager_privs.grant_switch_consumer_group('G2','G2', true);
dbms_resource_manager.set_initial_consumer_group ('G2','G2');
END;
/首先创建一个 1350万行的表dbrmtable
对该表做并行查询select /*+ parallel(dbrmtable,5) */ * from dbrmtable;
同时检查并行执行的进程情况发现
select * from v$px_session
可以看出协调进程号为6，共有两个并行子进程，说明语句里的5个并行度被资源管理器控制为2
6.5 限制undo
经过验证我们可以知道在G2用户下使用如下命令创建一个新表会产生的undo量为7K多点：
create table t as select * from user_objects;
那么我们限制g2用户组总的undo使用量为5K，切记下面的undo_pool限制的是总undo量
EXECUTE dbms_resource_manager.clear_pending_area;
EXECUTE dbms_resource_manager.create_pending_area;
EXECUTE DBMS_RESOURCE_MANAGER.CREATE_PLAN(PLAN=> 'g2test5',CPU_MTH => 'EMPHASIS',COMMENT => ' g2 plan5');
SQL> BEGIN
dbms_resource_manager.create_plan_directive
(plan => 'g2test5',
group_or_subplan => 'G2',
comment => 'blocker time',
UNDO_POOL => 5);
dbms_resource_manager.create_plan_directive
(plan => 'g2test5',
group_or_subplan => 'OTHER_GROUPS',
comment => 'other time'
);
End;
/
SQL>EXEC DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
EXEC DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
EXECUTE dbms_resource_manager_privs.grant_switch_consumer_group('G2','G2', true);
EXECUTE dbms_resource_manager.set_initial_consumer_group ('G2','G2');启动资源计划SQL> ALTER SYSTEM SET resource_manager_plan='g2test5';
尝试创建相关表
使用alter system set resource_manager_plan='’;取消资源管理计划以后重复上诉动作
可以正常执行
6.6 使用时间窗口来调度不同的资源计划
这里我们用OEM来配置
途中的窗口选项卡来配置，点击窗口进入如下画面
点击创建
通过创建窗口可以带动相关的资源计划，窗口结束后该计划也会消失。
上面的时间窗口是每天的21点18分开始启动
可以看到21点18分后相关资源计划随着时间窗口一起生效。
免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐
更多网易技术、产品、运营经验分享请点击。
