11g中高‘Resmgr:Cpu Quantum’等待事件(即使你已经禁用了resource manager)造成数据库hang住的解决办法
来源:互联网 发布:13458淘宝信用查询 编辑:程序博客网 时间:2024/06/05 23:46
‘Resmgr:Cpu Quantum’是resource manager用来控制分配CPU给processes的标准事件,当sessions无论什么原因使用了大量的CPU的时候,你有可能会看到一个‘hang’住的场景。这个事件发生在resource manager被启用,并用来节省CPU消耗的时候,但在11g中你即便已经禁用了resource manager,你仍旧会发现有高的‘Resmgr:Cpu Quantum’等待事件出现,亦或者出现‘sqlplus / as sysdba’被hang在那里的情况,你确定了参数‘RESOURCE_MANAGER_PLAN’是被设置为空的,但你依旧会看到高的‘Resmgr:Cpu Quantum’等待事件占据Top 5 Event:
Top 5 Timed Foreground Events:
Event Waits Time(s) Avg wait(ms) % DB time Wait Class
------------------------ ------- -------- ------------ -------------- ---------- -----------
resmgr:cpu quantum 1,596 346,281 216968 89.19 Scheduler
db file scattered read 171,071 14,778 86 3.81 User I/O
log file sync 28,575 10,810 378 2.78 Commit
db file sequential read 943,457 6,569 7 1.69 User I/O
DB CPU 2,133 0.55
这是由于从11g开始每个weekday window有一个预定义的Resource Plan叫做DEFAULT_MAINTENANCE_PLAN,当相关的window被打开的时候它就会被激活。
当它被激活的时候你会在alert log里看到以下条目信息:
Thu Sep 26 02:00:00 2013
Clearing Resource Manager plan via parameter
:
Thu Sep 26 22:00:00 2013
Setting Resource Manager plan SCHEDULER[0x2C55]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Thu Sep 26 22:00:05 2013
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
解决办法:
较好的解决办法是将维护窗口移动到一个较空闲的时候,能有足够有效的CPU资源去运行和完成这个任务。
禁用DEFAULT_MAINTENANCE_PLAN应该只能作为最后的选项来解决这个问题,因为如果Oracle没有足够的维护窗口去收集新的优化器状态、为昂贵的SQL找到更好的执行计划、清空AWR等的话,这种做法可能导致在长期运行中的一些其他问题。
1. 设置当前的resource manager plan为空
alter system set resource_manager_plan='' scope=both;
2. 改变激活的window为使用空的resource manager plan
execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');
11g开始有更多的维护窗口,同样需要修改它们
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('FRIDAY_WINDOW','RESOURCE_PLAN','');
3. 对其他的自定义的window也同样设置
execute dbms_scheduler.set_attribute('<window name>','RESOURCE_PLAN','');
Top 5 Timed Foreground Events:
Event Waits Time(s) Avg wait(ms) % DB time Wait Class
------------------------ ------- -------- ------------ -------------- ---------- -----------
resmgr:cpu quantum 1,596 346,281 216968 89.19 Scheduler
db file scattered read 171,071 14,778 86 3.81 User I/O
log file sync 28,575 10,810 378 2.78 Commit
db file sequential read 943,457 6,569 7 1.69 User I/O
DB CPU 2,133 0.55
这是由于从11g开始每个weekday window有一个预定义的Resource Plan叫做DEFAULT_MAINTENANCE_PLAN,当相关的window被打开的时候它就会被激活。
当它被激活的时候你会在alert log里看到以下条目信息:
Thu Sep 26 02:00:00 2013
Clearing Resource Manager plan via parameter
:
Thu Sep 26 22:00:00 2013
Setting Resource Manager plan SCHEDULER[0x2C55]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Thu Sep 26 22:00:05 2013
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
解决办法:
较好的解决办法是将维护窗口移动到一个较空闲的时候,能有足够有效的CPU资源去运行和完成这个任务。
禁用DEFAULT_MAINTENANCE_PLAN应该只能作为最后的选项来解决这个问题,因为如果Oracle没有足够的维护窗口去收集新的优化器状态、为昂贵的SQL找到更好的执行计划、清空AWR等的话,这种做法可能导致在长期运行中的一些其他问题。
1. 设置当前的resource manager plan为空
alter system set resource_manager_plan='' scope=both;
2. 改变激活的window为使用空的resource manager plan
execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');
11g开始有更多的维护窗口,同样需要修改它们
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('FRIDAY_WINDOW','RESOURCE_PLAN','');
3. 对其他的自定义的window也同样设置
execute dbms_scheduler.set_attribute('<window name>','RESOURCE_PLAN','');
阅读全文
0 0
- 11g中高‘Resmgr:Cpu Quantum’等待事件(即使你已经禁用了resource manager)造成数据库hang住的解决办法
- Resmgr:Cpu Quantum 等待事件
- resmgr:cpu quantum 等待事件问题处理
- High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource Manager Is Disabled (文档 ID 949033.1)
- 异常等待事件Resmgr:Cpu Quantum导致CPU利用率高
- Oracle Study之--resmgr:cpu quantum等待事件
- resmgr:cpu quantum导致的性能问题
- Oracle等待事件: resmgr:cpu quant…
- resmgr:cpu quantum Top Event Issues Solved
- 一次数据库hang,大量enqueue等待事件的问题
- resmgr: become active等待事件
- oracle 数据库hang住了
- 彻底禁用resource manager
- Oracle 11g 新特性 – HM(Hang Manager)简介
- oracle关闭数据库被hang住的解决办法
- oracle 11g中 Resource Manager的组成元素
- ARCH wait on ATTACH等待事件引起的切换归档hang住
- 查询dba_jobs视图hang住,等待事件enq: TX contention
- web项目直接在浏览器上访问不需要带.jsp,直接ip地址加项目名 在web.xml里配置,<welcome-file-list><welcome-file> /view/login.jsp <
- Inside the C++ Object Model 第一讲: 关于对象
- 详解HttpURLConnection(注意末尾的部分)
- 一步一步理解GB、GBDT、xgboost
- Html5--本地文本文件读取与保存
- 11g中高‘Resmgr:Cpu Quantum’等待事件(即使你已经禁用了resource manager)造成数据库hang住的解决办法
- Redis常见的集群方案(转)
- React 实践项目 (一)
- 09/07/2017
- 归并排序算法心得
- POJ 3004 Subway planning 笔记
- Mysql学习历程基本语法(4)--数据操作
- Java8新增的DateTimeFormatter与SimpleDateFormat的区别
- Coprime Sequence HDU