cpu quantumio等待占用cpu事件怎么解决
点击联系发帖人
时间：2017-04-22 08:12
Oracle等待事件: resmgr:cpu quantum引发CPU冲高 - Oracle Life - 云和恩墨，成就所托！
Oracle等待事件: resmgr:cpu quantum引发CPU冲高
在中,有一位朋友问到一个关于: resmgr:cpu quantum 的问题.这个问题由来已久,也遇到过2次,第一次遇到这个问题,凭直觉就找到了一个隐含参数,通过设置该参数屏蔽了这个问题,未进行进一步研究.现在再次遇到有人提出,就索性翻翻文档,记录一下.这个问题显然是和资源管理相关的,如果启用资源管理计划,就可能遇到这个问题.所以常规的解决方案是禁用资源管理,禁用缺省的维护计划(DEFAULT_MAINTENANCE_PLAN Metalink:)alter system set resource_manager_plan='';execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN',''); andexecute dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');execute dbms_scheduler.set_attribute('&window name&','RESOURCE_PLAN','');以上是针对Oracle 11g的一种解决方案.从以下的Event Class中也可以看到Scheduler的属性:Top User EventsEventEvent Class% ActivityAvg Active Sessionsresmgr:cpu quantumScheduler34.692.90CPU + Wait for CPUCPU26.622.23latch: library cacheConcurrency25.912.17latch: shared poolConcurrency5.050.42latch freeOther4.150.35Top Event P1/P2/P3 ValuesEvent% EventP1 Value, P2 Value, P3 Value% ActivityParameter 1Parameter 2Parameter 3resmgr:cpu quantum34.69"2","0","0"27.34location&&&&"1","0","0"3.95&&&&&"3","0","0"3.40&&&latch: library cache26.16"","214","0"4.83addressnumbertries&&"","214","0"4.43&&&&&"","214","0"3.45&&&latch: shared pool5.20"","213","0"2.72addressnumbertries&&"","213","0"2.31&&&latch free4.20"","238","0"1.34addressnumbertries&&"","205","0"1.26&&&&&"","127","0"1.03&&&但是很多用户会发现禁用资源计划很多时候没有作用.我第一次遇到这个问题时,第一反应就是直接去寻找是否有隐含参数可以禁用Oracle缺省启用的资源调度,最后通过以下参数设置解决问题:_resource_manager_always_on = false在那个案例中,相关的等待事件是: resmgr:active threads,通过隐含参数可以将始终打开的资源计划关闭.当然还有几个BUG会导致类似的问题,以下是MOS上的相关问题解决方案,提供供参考:
WAITS FOR "RESMGR CPU QUANTUM"
One-off patches available
- RESOURCE MANAGER IS OVER THROTTLING Fixed in 11g Release2 and planned to be included in patchset 10.2.0.5
HIGH WAIT EVENTS ON "RESMGR CPU QUANTUM" WHEN RESOURCE MANAGER IS ENABLED&& Fixed in patchset 10.2.0.4Workaround by setting the parameters : _enable_NUMA_optimization=FALSE _db_block_numa=1 - Poor performance with Resource Manager when RMAN is runningFixed in 11g Release2 and planned to be included in patchset 10.2.0.5 and 11.1.0.7Workaround:&&&&
Disable Resource Manager.One-off patches available See also
Resource Manager Plan Changes Settings Every Weekwhich might be causing higher waits on 'RESMGR:& ' events due to the changed Resource Plan.
历史上的今天...
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
By eygle on
CopyRight ©
, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话：400-600-8755 业务咨询：010-0 or 7037 业务合作:问题处理,最全面的问题处理文章 - 电子工程世界网
在电子工程世界为您找到如下关于“问题处理”的新闻
问题处理资料下载
Allegro这之间处理所花的时间远比之前用Third Party 方式超过太多(太慢) 而新版Capture 又无提供旧方式的生方式害我只能将旧版的Allegro.dll Copy 到Capture\netsform 下才能用旧的方式生NetList为什新版的问题那多而且又不Friendly... Why...
10. 4. 1 小波变换及基小波波形
10. 4. 2 小波变换技术在信号处理中的应用
10. 4. 3 小波问题的程序界面
10. 5 粗糙集理论与应用
10. 5. 1 粗糙集理论介绍
10. 5. 2 粗糙集数据处理问题的MATLAB求解
10. 6 分数阶微积分学及其应用
10. 6. 1 分数阶微积分的定义
10. 6. 2 分数阶微积分的计算
完美清晰书签版PDF电子书,互联网原创首发
本书全面而又系统地介绍了基于fpga实现数字信号处理的原理及方法。全书包括12章和11个实验，主要内容包括数字信号处理设计导论、fpga的硬件结构及运算功能、信号及其处理理论概述、cordic算法原理及实现、fir滤波器和iir滤波器的设计、其他常用数字滤波器的设计、重定时信号流图、数字通信信号处理原理及实现、自适应信号处理理论基础...
14.1.1 UDF调用顺序& 14.1.2 参数处理 14.1.3 返回值和出错处理 14.1.4 编译并安装用户定义函数 14.2 增加一个新的原生(native)函数 15 为MySQL增加新过程 15.1 analyse过程 15.2 编写一个过程 16 MySQL对 ODBC 支持 16.1 MyODBC 支持的操作系统 16.2 怎样报告 MyODBC的问题 16.3 已知...
技术打下良好的基础。第7章介绍离散时间信号经幅度量化后带来的有限字长效应，该章提出用状态???量法分析溢出振荡、数字系统的运算量化噪声、系统的动态范围等问题，便于用计算处理这些问题，为工程设计中的计算机仿真提供有力的理论依据和方法。多采样率信号处理是信号处理???域中又一重要的研究和应用课题，第8章介绍了多采样率概念、频谱变换、多采样率系统结构以及多采样率应用实例，为读者在不同领域中用多采样率处理...
该部分确实有一定的深度和难度.《GSM 原理及其网络优化》最后较为详细地阐述了有关网络优化实践操作的相关知识,包括常用参数的优化调整、网络优化应注意的部分问题以及网络故障的处理,这一部分是GSM网络优化理论的应用与实践,通过大量实例的列举可以使读者对各种疑难的网络故障处理找到入手之处.《GSM 原理及其网络优化》较侧重于实用性,对于广大从事GSM网络优化、维护以及研究和管理人员具有很强的可读性...
Secure Sockets Layer的Web节点19.4.5 建立一个虚拟私有网络19.4.6 数据流介质19.4.7 单服务器故障恢复支持19.5 客户请求的缺省处理19.6 wlbs display命令19.7 在注册表中改变网络负载平衡资源限制19.8 其他资源第20章 集群日志的解释20.1 集群日志基础20.1.1 集群日志条目的剖析20.1.2 跟踪资源问题的技术20.2 集群排列和...
第1章 RIP故障处理&1-11.1 RIP故障处理综述&1-11.1.1 RIP配置的常见问题&1-11.1.2 RIP性能问题&1-31.1.3 其他相关问题&1-41.1.4 RIP故障处理的一般步骤：&1-41.2 与RIP故障相关的display、debugging命令介绍&1-61.2.1 display...
问题？ 指由于人类活动作用于我们周围的环境所引起的“公害”问题，是一个世界性的社会问题。 4. 环境问题经历了哪几个发展阶段？ 原始捕猎阶段、农牧业阶段、工业革命阶段、工业发展阶段、现代工业阶段。 5. 什么是环境容量？ 指在不影响环境的正常功能或用途的情况下，承受污染物的最大允许量或能力。或者说是指在维持生态平衡和不超过人体健康阀值的情况下环境所能承受的污染物的总量。 6. 什么是环境自净？ 在...
阐述了医学图像处理技术的发展动态，介绍了目前国内在三维医学图像的可视化和基于PACS的医学图像压缩在医学图像处理方面的进展。在比较各种技术在相关领域中应用的基础上，提出了医学图像处理技术发展所面临的相关问题及其发展方向。 关 键 词 医学图像处理; 可视化; 图像分割; 图像匹配; 图像融合; 图像存档通信系统 近20多年来，医学影像已成为医学技术中发展最快的领域之一，其结果使临床医生对人体内部...
问题处理相关帖子
数字麦克风阵列输入，双ISP像素处理能力高达800MPix/s，支持双路摄像头数据同时输入，支持3D、深度信息提取等高阶处理，支持HDMI_IN高清输入，HDMI_OUT高清输出并可同时工作，可外接UART*3,RS458*1接口，内置PCI-e4G接口，集成双USB3.0 Type-C接口，传输速度是USB2.0的10倍，使用WIFi蓝牙AP6335芯片传输距离可达25米，超快的开机速度可达10秒...
防水气凝结方面的低劣性能，注定不会得到大量使用，并逐渐被淘汰。国内一些份仿制品由于材料性能问题导致箱体在防水气凝结和抗冲击两项性能上与引进德国的KRONE有较大差异，另外由于密封胶条抗老化性能较差，在防水、防尘两项性能上表现也一般。当然在光缆交接箱安装位置的外环境比较好时，降低性能要求，减少投资也是可以接受的。容量光缆交接箱的容量是指光缆交接箱最大能成端纤芯的数目。容量的大小与箱体的体积、整体造价...
日沪宁高速南京马群公安检查站，一名男子冒用弟弟驾驶证被交警发现后，觉得自己长相与弟弟“神似”而心存侥幸万般抵赖，但“人脸识别系统”最终还是令其现出原形。自2015年12月在该检查站投运以来，该系统已先后查获几十起问题人员，其中在逃人员5名。
报道中的“人证合一”人脸识别核验系统来自国家级高新科技企业——南京安智易达智能科技有限公司，该系统基于深度学习理论，采用归一化像素...
PCB电路设计与生产中的一些问题
作者：pcbask
避免过孔via紧挨着SMT焊盘
如果未盖油塞孔的via，我们在layout时将过孔打的过于靠近SMT器件的焊盘，将会造成SMT器件在过回流焊时，流动的焊锡通过该过孔流到PCB的另一面，造成SMT焊料不足而虚焊等问题。通常建议，via过孔的边缘距离 SMT 焊盘边缘距离在 25mil以上，并且via过孔做盖油处理。
请勿将比...
将以人工智能（AI）为核心，推出智能音箱设备，构建下一代智能终端生态。这标志着一场人工智能设备的较量骤然升温——硬件厂商与服务商正力图成为消费者在工作场所、居家环境和外出途中的&智能中枢&。
智能设备生态发展需解决体验碎片化问题
智能设备生态体系的构建仍有诸多问题亟待解决。由于大众消费者必须分别与各个智能设备交互，智能设备体验始终呈现碎片化状态。各种智能设备的人机界面...
(连0.1倍都不到)。
你的采样电阻两端电压， ...[/quote]
听师傅这么说，运放放大倍数仅仅和反馈电阻与反向端电阻比值有关系，和添加的什么偏置电压没关系，偏置电压就是为了抬高输出电位，方便电路后期处理是吧？ [quote][size=2][url=forum.php?mod=redirect&goto=findpost&pid=2215152&ptid=552748][color...
自动识别硬件的缺失。仓储管理系统中的软件指的是支持整个系统运作的软件部分，包括收货处理、上架管理、拣货作业、月台管理、补货管理、库内作业、越库操作、循环盘点、RF操作、加工管理、矩阵式收费等。仓储管理系统中的硬件指的是用于打破传统数据采集和上传的瓶颈问题，利用自动识别技术和无线传输提高数据的精度和传输的速度。管理经验指的是开发商根据其开发经验中客户的管理方式和理念整合的一套管理理念和流程，为企业做到...
这类的问题再出现前就要把这种问题消灭，在用料前严格执行对物料的检查程序，避免晶点问题的发生。厚度不一厚薄度不一有几点问题是值得注意的，各种材料在产生的过程中是有结状的，当出现放置错的情况时，呈现会发生厚度不一的状态。和材料的关系是在生产过程中材料没有把握好，温度没有控制好，才会发生这种恶劣的情况。温度的调控也是有关系的，并要根据温度的变化做好相应的控制工作，否则就会出现厚度不一的情况。处理办法是在...
款式和风格，经过客户同意，进行相应的设计，然后设计出品，最后成品。在磨具处理上，要先用石膏做出磨具，等磨具完全干化，把磨具进行处理，然后在上面弄上很多小孔，方面抽出空气。在做好磨具以后，要把石膏放到铁板上，根据其规格固定好，然后加热软化，等到冷却，作出磨具，最后一道工序就是整理，整理好方可售卖。拉线问题吸塑包装需在生产出产品以后可能会出现一条不规则的线路，会影响这个产品的质量和做工。出现这种情况不要...
处理客户咨询时，因为对发货及PCB工厂业务不够熟悉，很多问题需要向仓储部门辗转打听再行回复，客户体验不够好，于是提出了去仓库参观学习的想法，这个提议很快得到其他部门的积极响应。初识PCB打样上午9点准时集合，一行人驱车前往第一站，位于龙岗的嘉立创PCB样板厂，一个半小时的车程在大家的唱歌比赛游戏中倏忽而过。走进PCB样板厂，首先看到的是开料工序，各种厚度（从0.4mm到2.0mm）的铜板在这里被...
问题处理视频
你可能感兴趣的标签
热门资源推荐Phone: 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务
Categories
Tag Cloud 3D
WP Cumulus Flash tag cloud by
9 or better.
最新评论国内圈子
oracle security
本站文章除注明转载外，均为本站原创： 转载自
本文链接地址:
昨天给某客户升级的系统，经过TDE加密以后，今天上午出现严重的性能问题，表现的现象如下：
从top可以看到，cpu消耗非常之高，基本上在90~95%左右，奇怪的是user消耗只有30~40%左右，
大部分是sys消耗，断定db出问题了，通过QQ远程客户，进行了如下处理：
SQL& select event,count(*) from v$se
之后, 发现有70个左右的 resmgr:cpu quantum 等待，另外还有2~5个 asynch descriptor resize。
12345678910
昨天给某客户升级的系统，经过TDE加密以后，今天上午出现严重的性能问题，表现的现象如下：&从top可以看到，cpu消耗非常之高，基本上在90~95%左右，奇怪的是user消耗只有30~40%左右，大部分是sys消耗，断定db出问题了，通过QQ远程客户，进行了如下处理：&通过&SQL& select event,count(*) from v$session group by event;&之后, 发现有70个左右的 resmgr:cpu quantum 等待，另外还有2~5个 asynch descriptor resize。
但从等待事件来看，都没遇到过，查询mos发现了相关的资料：
High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource Manager Is Disabled [ID ]
11g: Scheduler Maintenance Tasks or Autotasks [ID ]
Large Waits With The Wait Event "Resmgr:Cpu Quantum" [ID ]
于是做出了如下调整：
但从等待事件来看，都没遇到过，查询mos发现了相关的资料：&High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource Manager Is Disabled [ID ]11g: Scheduler Maintenance Tasks or Autotasks [ID ]Large Waits With The Wait Event "Resmgr:Cpu Quantum" [ID ]&于是做出了如下调整：
alter system set resource_manager_plan='';
execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEEKEND_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','');
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
DBMS_AUTO_TASK_ADMIN.DISABLE(client_name =& 'sql tuning advisor',
operation =& NULL,
window_name =& NULL);
1234567891011121314151617
alter system set resource_manager_plan='';execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');execute dbms_scheduler.set_attribute('WEEKEND_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','');execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');&BEGIN&&DBMS_AUTO_TASK_ADMIN.DISABLE(client_name =& 'sql tuning advisor',&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& operation =& NULL,&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& window_name =& NULL);END;/
另外关于event asynch descriptor resize，从字面上理解就知道跟异步IO有关，当时通过top中cpu消耗较高的
几个进程，我关联v$process, v$session查询发现有几个进程所持有的event竟然是asynch descriptor resize，
于是做了如下调整：
另外关于event asynch descriptor resize，从字面上理解就知道跟异步IO有关，当时通过top中cpu消耗较高的几个进程，我关联v$process, v$session查询发现有几个进程所持有的event竟然是asynch descriptor resize，于是做了如下调整：
alter system set disk_async_io=false scope=
alter system filesystemio_options=none scope=
alter system set disk_async_io=false scope=alter system filesystemio_options=none scope=
然后跟开发商沟通了一下，重启了一下db，重启后观察主机资源情况，发现基本上正常了。
为了安抚客户，还是打车去了趟现场，到现场以后，还做了如下调整：
1. OPTIMIZER_INDEX_COST_ADJ 调整为默认值100。
2. 隐含参数_ASH_SIZE调整为16m(默认是8m), 当时查看alert日志发现有如下告警：
然后跟开发商沟通了一下，重启了一下db，重启后观察主机资源情况，发现基本上正常了。&为了安抚客户，还是打车去了趟现场，到现场以后，还做了如下调整：&1. OPTIMIZER_INDEX_COST_ADJ 调整为默认值100。2. 隐含参数_ASH_SIZE调整为16m(默认是8m), 当时查看alert日志发现有如下告警：
Mon Nov 21 14:42:24 2011
Archived Log entry 38536 added for thread 1 sequence 38650 ID 0x18c941ba dest 1:
Mon Nov 21 14:46:51 2011
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized.
If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the
value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 8388608 bytes. Both ASH
size and the total number of emergency flushes since instance startup can be monitored by running
the following query:
select total_size,awr_flush_emergency_count from v$ash_
Mon Nov 21 14:42:24 2011Archived Log entry 38536 added for thread 1 sequence 38650 ID 0x18c941ba dest 1:Mon Nov 21 14:46:51 2011Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 8388608 bytes. Both ASHsize and the total number of emergency flushes since instance startup can be monitored by runningthe following query:select total_size,awr_flush_emergency_count from v$ash_info;
3. 对于消耗逻辑度最为严重的3个sql语句，通过查询v$sql发现其有多个child number，看其执行计划也存在
多个执行计划，其中几个执行计划明显有问题，一会儿是index full scan一会儿是index skip scan。
于是为该几个sql创建了outline，如下：
3. 对于消耗逻辑度最为严重的3个sql语句，通过查询v$sql发现其有多个child number，看其执行计划也存在多个执行计划，其中几个执行计划明显有问题，一会儿是index full scan一会儿是index skip scan。于是为该几个sql创建了outline，如下：
SQL& alter session set create_stored_outlines=
Session altered.
SQL& exec dbms_outln.create_outline(,0);
PL/SQL procedure successfully completed.
-- 其他两个省略。
SQL& alter session set create_stored_outlines=true;&Session altered.&SQL& exec dbms_outln.create_outline(,0);&PL/SQL procedure successfully completed.&SQL&&&-- 其他两个省略。
晚上回家，查询mos发现，关于 asynch descriptor resize 果然存在bug，而且处理方式就是调整disk_type_io参数，如下：
晚上回家，查询mos发现，关于 asynch descriptor resize 果然存在bug，而且处理方式就是调整disk_type_io参数，如下：
Bug 9829397 – Excessive CPU and many “asynch descriptor resize” waits for SQL using Async IO [ID ]
07-SEP-2011
类型 PATCH
状态 PUBLISHED
Bug 9829397
Excessive CPU and many “asynch descriptor resize” waits for SQL using Async IO
This note gives a brief overview of bug 9829397.
The content was last updated on: 07-SEP-2011
details of each of the sections below.
Product (Component)
Oracle Server (Rdbms)
Range of versions believed to be affected
Versions &= 11.2 but BELOW 12.1
Versions confirmed as being affected
Platforms affected
Generic (all / most platforms affected)
believed to be a
in default behaviour thus:
Regression introduced in
This issue is fixed in
Related To:
Waits for “asynch descriptor resize”
Description
Some queries in 11.2 may exhibit higher CPU usage than earlier
releases with many "asynch descriptor resize" waits occurring
compared to the same SQL in earlier releases.
Rediscovery Notes:
Async IO is in use.
The total time waiting for "asynch descriptor resize" is
typically very small but with very high counts. The high
wait count indicates many resizes of the number of AIO
descriptors unnecessarily wasting CPU.
&strong&&span style="text-decoration:"&Workaround&/span&&/strong&
Disable async IO.
eg: Set DISK_ASYNCH_IO = false
1234567891011121314
Some queries in 11.2 may exhibit higher CPU usage than earlierreleases with many "asynch descriptor resize" waits occurringcompared to the same SQL in earlier releases. &Rediscovery Notes: Async IO is in use. The total time waiting for "asynch descriptor resize" is typically very small but with very high counts. The high wait count indicates many resizes of the number of AIO descriptors unnecessarily wasting CPU.&&strong&&span style="text-decoration:"&Workaround&/span&&/strong& Disable async IO. eg: Set DISK_ASYNCH_IO = false
最后调整以后系统基本正常了，单纯就系统资源来说，cpu idle维持在50~80%。
最后调整以后系统基本正常了，单纯就系统资源来说，cpu idle维持在50~80%。
No related posts.
on 十一月 21, 2011数据库技术（473）
Oracle Study之--resmgr:cpu quantum等待事件
在AWR Report中出现“resmgr:cpu quantum”等待事件：
“resmgr:cpu quantum”等待事件：
参考metalink的解决方案，是oracle资源管理方面的问题，原文如下：
High waits on&event 'resmgr:cpu quantum' might be noticed even when resource manager is disabled.&&&& You already have confirmed parameter RESOURCE_MANAGER_PLAN is set to null but still noticing the above wait events.
Top 5 Timed Foreground Events:
Avg wait(ms) % DB time Wait Class
------------------------ ------- -------- ------------ -------------- ---------- -----------
resmgr:cpu quantum
89.19 Scheduler
db file scattered read
3.81 User I/O
log file sync
2.78 Commit
db file sequential read
1.69 User I/O
This could be due to DEFAULT_MAINTENANCE_PLAN. From 11g onwards every weekday window has a pre-defined Resource
Plan called DEFAULT_MAINTENANCE_PLAN, which will become active once the related window opens.
Following entries can also be noted in alert log at the time of issue.
Wed Sep 16 02:00:00 2009
Clearing Resource Manager plan via parameter：
Wed Sep 16 22:00:00 2009
Setting Resource Manager plan SCHEDULER[0x2C55]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Wed Sep 16 22:00:05 2009
Begin automatic SQL Tuning Advisor run for special tuning task &SYS_AUTO_SQL_TUNING_TASK&
To disable the DEFAULT_MAINTENANCE_PLAN you can use the below steps as suggested in
1. Set the current resource manager plan to null (or another plan that is not restrictive):
alter system set resource_manager_plan='';
2. Change the active windows to use the null resource manager plan (or other nonrestrictive plan)
using:3. Then, for each window_name (WINDOW_NAME from DBA_SCHEDULER_WINDOWS), run:
execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN',''); execute dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');
3. Then, for each window_name (WINDOW_NAME from DBA_SCHEDULER_WINDOWS), run:
execute dbms_scheduler.set_attribute('&window name&','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('&window name&','RESOURCE_PLAN','');
References
Database Hangs. Sessions wait for 'resmgr:cpu quantum'
11g: Scheduler Maintenance Tasks or Autotasks
Resource Manager and Sql Tunning Advisory DEFAULT_MAINTENANCE_PLAN
Large Waits With The Wait Event &Resmgr:Cpu Quantum&
但是很多用户会发现禁用资源计划很多时候没有作用.可以禁用Oracle缺省启用的资源调度,最后通过以下参数设置解决问题:
_resource_manager_always_on = false
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：427874次
积分：5533
积分：5533
排名：第4752名
原创：511篇
转载：87篇
(1)(2)(1)(5)(3)(4)(1)(5)(3)(1)(1)(8)(14)(4)(3)(11)(6)(7)(9)(12)(19)(14)(6)(6)(422)(3)(28)}
Oracle等待事件: resmgr:cpu quantum引发CPU冲高
在中,有一位朋友问到一个关于: resmgr:cpu quantum 的问题.这个问题由来已久,也遇到过2次,第一次遇到这个问题,凭直觉就找到了一个隐含参数,通过设置该参数屏蔽了这个问题,未进行进一步研究.现在再次遇到有人提出,就索性翻翻文档,记录一下.这个问题显然是和资源管理相关的,如果启用资源管理计划,就可能遇到这个问题.所以常规的解决方案是禁用资源管理,禁用缺省的维护计划(DEFAULT_MAINTENANCE_PLAN Metalink:)alter system set resource_manager_plan='';execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN',''); andexecute dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');execute dbms_scheduler.set_attribute('&window name&','RESOURCE_PLAN','');以上是针对Oracle 11g的一种解决方案.从以下的Event Class中也可以看到Scheduler的属性:Top User EventsEventEvent Class% ActivityAvg Active Sessionsresmgr:cpu quantumScheduler34.692.90CPU + Wait for CPUCPU26.622.23latch: library cacheConcurrency25.912.17latch: shared poolConcurrency5.050.42latch freeOther4.150.35Top Event P1/P2/P3 ValuesEvent% EventP1 Value, P2 Value, P3 Value% ActivityParameter 1Parameter 2Parameter 3resmgr:cpu quantum34.69"2","0","0"27.34location&&&&"1","0","0"3.95&&&&&"3","0","0"3.40&&&latch: library cache26.16"","214","0"4.83addressnumbertries&&"","214","0"4.43&&&&&"","214","0"3.45&&&latch: shared pool5.20"","213","0"2.72addressnumbertries&&"","213","0"2.31&&&latch free4.20"","238","0"1.34addressnumbertries&&"","205","0"1.26&&&&&"","127","0"1.03&&&但是很多用户会发现禁用资源计划很多时候没有作用.我第一次遇到这个问题时,第一反应就是直接去寻找是否有隐含参数可以禁用Oracle缺省启用的资源调度,最后通过以下参数设置解决问题:_resource_manager_always_on = false在那个案例中,相关的等待事件是: resmgr:active threads,通过隐含参数可以将始终打开的资源计划关闭.当然还有几个BUG会导致类似的问题,以下是MOS上的相关问题解决方案,提供供参考:
WAITS FOR "RESMGR CPU QUANTUM"
One-off patches available
- RESOURCE MANAGER IS OVER THROTTLING Fixed in 11g Release2 and planned to be included in patchset 10.2.0.5
HIGH WAIT EVENTS ON "RESMGR CPU QUANTUM" WHEN RESOURCE MANAGER IS ENABLED&& Fixed in patchset 10.2.0.4Workaround by setting the parameters : _enable_NUMA_optimization=FALSE _db_block_numa=1 - Poor performance with Resource Manager when RMAN is runningFixed in 11g Release2 and planned to be included in patchset 10.2.0.5 and 11.1.0.7Workaround:&&&&
Disable Resource Manager.One-off patches available See also
Resource Manager Plan Changes Settings Every Weekwhich might be causing higher waits on 'RESMGR:& ' events due to the changed Resource Plan.
历史上的今天...
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
&&&&&&&&&&&
By eygle on
CopyRight ©
, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话：400-600-8755 业务咨询：010-0 or 7037 业务合作:问题处理,最全面的问题处理文章 - 电子工程世界网
在电子工程世界为您找到如下关于“问题处理”的新闻
问题处理资料下载
Allegro这之间处理所花的时间远比之前用Third Party 方式超过太多(太慢) 而新版Capture 又无提供旧方式的生方式害我只能将旧版的Allegro.dll Copy 到Capture\netsform 下才能用旧的方式生NetList为什新版的问题那多而且又不Friendly... Why...
10. 4. 1 小波变换及基小波波形
10. 4. 2 小波变换技术在信号处理中的应用
10. 4. 3 小波问题的程序界面
10. 5 粗糙集理论与应用
10. 5. 1 粗糙集理论介绍
10. 5. 2 粗糙集数据处理问题的MATLAB求解
10. 6 分数阶微积分学及其应用
10. 6. 1 分数阶微积分的定义
10. 6. 2 分数阶微积分的计算
完美清晰书签版PDF电子书,互联网原创首发
本书全面而又系统地介绍了基于fpga实现数字信号处理的原理及方法。全书包括12章和11个实验，主要内容包括数字信号处理设计导论、fpga的硬件结构及运算功能、信号及其处理理论概述、cordic算法原理及实现、fir滤波器和iir滤波器的设计、其他常用数字滤波器的设计、重定时信号流图、数字通信信号处理原理及实现、自适应信号处理理论基础...
14.1.1 UDF调用顺序& 14.1.2 参数处理 14.1.3 返回值和出错处理 14.1.4 编译并安装用户定义函数 14.2 增加一个新的原生(native)函数 15 为MySQL增加新过程 15.1 analyse过程 15.2 编写一个过程 16 MySQL对 ODBC 支持 16.1 MyODBC 支持的操作系统 16.2 怎样报告 MyODBC的问题 16.3 已知...
技术打下良好的基础。第7章介绍离散时间信号经幅度量化后带来的有限字长效应，该章提出用状态???量法分析溢出振荡、数字系统的运算量化噪声、系统的动态范围等问题，便于用计算处理这些问题，为工程设计中的计算机仿真提供有力的理论依据和方法。多采样率信号处理是信号处理???域中又一重要的研究和应用课题，第8章介绍了多采样率概念、频谱变换、多采样率系统结构以及多采样率应用实例，为读者在不同领域中用多采样率处理...
该部分确实有一定的深度和难度.《GSM 原理及其网络优化》最后较为详细地阐述了有关网络优化实践操作的相关知识,包括常用参数的优化调整、网络优化应注意的部分问题以及网络故障的处理,这一部分是GSM网络优化理论的应用与实践,通过大量实例的列举可以使读者对各种疑难的网络故障处理找到入手之处.《GSM 原理及其网络优化》较侧重于实用性,对于广大从事GSM网络优化、维护以及研究和管理人员具有很强的可读性...
Secure Sockets Layer的Web节点19.4.5 建立一个虚拟私有网络19.4.6 数据流介质19.4.7 单服务器故障恢复支持19.5 客户请求的缺省处理19.6 wlbs display命令19.7 在注册表中改变网络负载平衡资源限制19.8 其他资源第20章 集群日志的解释20.1 集群日志基础20.1.1 集群日志条目的剖析20.1.2 跟踪资源问题的技术20.2 集群排列和...
第1章 RIP故障处理&1-11.1 RIP故障处理综述&1-11.1.1 RIP配置的常见问题&1-11.1.2 RIP性能问题&1-31.1.3 其他相关问题&1-41.1.4 RIP故障处理的一般步骤：&1-41.2 与RIP故障相关的display、debugging命令介绍&1-61.2.1 display...
问题？ 指由于人类活动作用于我们周围的环境所引起的“公害”问题，是一个世界性的社会问题。 4. 环境问题经历了哪几个发展阶段？ 原始捕猎阶段、农牧业阶段、工业革命阶段、工业发展阶段、现代工业阶段。 5. 什么是环境容量？ 指在不影响环境的正常功能或用途的情况下，承受污染物的最大允许量或能力。或者说是指在维持生态平衡和不超过人体健康阀值的情况下环境所能承受的污染物的总量。 6. 什么是环境自净？ 在...
阐述了医学图像处理技术的发展动态，介绍了目前国内在三维医学图像的可视化和基于PACS的医学图像压缩在医学图像处理方面的进展。在比较各种技术在相关领域中应用的基础上，提出了医学图像处理技术发展所面临的相关问题及其发展方向。 关 键 词 医学图像处理; 可视化; 图像分割; 图像匹配; 图像融合; 图像存档通信系统 近20多年来，医学影像已成为医学技术中发展最快的领域之一，其结果使临床医生对人体内部...
问题处理相关帖子
数字麦克风阵列输入，双ISP像素处理能力高达800MPix/s，支持双路摄像头数据同时输入，支持3D、深度信息提取等高阶处理，支持HDMI_IN高清输入，HDMI_OUT高清输出并可同时工作，可外接UART*3,RS458*1接口，内置PCI-e4G接口，集成双USB3.0 Type-C接口，传输速度是USB2.0的10倍，使用WIFi蓝牙AP6335芯片传输距离可达25米，超快的开机速度可达10秒...
防水气凝结方面的低劣性能，注定不会得到大量使用，并逐渐被淘汰。国内一些份仿制品由于材料性能问题导致箱体在防水气凝结和抗冲击两项性能上与引进德国的KRONE有较大差异，另外由于密封胶条抗老化性能较差，在防水、防尘两项性能上表现也一般。当然在光缆交接箱安装位置的外环境比较好时，降低性能要求，减少投资也是可以接受的。容量光缆交接箱的容量是指光缆交接箱最大能成端纤芯的数目。容量的大小与箱体的体积、整体造价...
日沪宁高速南京马群公安检查站，一名男子冒用弟弟驾驶证被交警发现后，觉得自己长相与弟弟“神似”而心存侥幸万般抵赖，但“人脸识别系统”最终还是令其现出原形。自2015年12月在该检查站投运以来，该系统已先后查获几十起问题人员，其中在逃人员5名。
报道中的“人证合一”人脸识别核验系统来自国家级高新科技企业——南京安智易达智能科技有限公司，该系统基于深度学习理论，采用归一化像素...
PCB电路设计与生产中的一些问题
作者：pcbask
避免过孔via紧挨着SMT焊盘
如果未盖油塞孔的via，我们在layout时将过孔打的过于靠近SMT器件的焊盘，将会造成SMT器件在过回流焊时，流动的焊锡通过该过孔流到PCB的另一面，造成SMT焊料不足而虚焊等问题。通常建议，via过孔的边缘距离 SMT 焊盘边缘距离在 25mil以上，并且via过孔做盖油处理。
请勿将比...
将以人工智能（AI）为核心，推出智能音箱设备，构建下一代智能终端生态。这标志着一场人工智能设备的较量骤然升温——硬件厂商与服务商正力图成为消费者在工作场所、居家环境和外出途中的&智能中枢&。
智能设备生态发展需解决体验碎片化问题
智能设备生态体系的构建仍有诸多问题亟待解决。由于大众消费者必须分别与各个智能设备交互，智能设备体验始终呈现碎片化状态。各种智能设备的人机界面...
(连0.1倍都不到)。
你的采样电阻两端电压， ...[/quote]
听师傅这么说，运放放大倍数仅仅和反馈电阻与反向端电阻比值有关系，和添加的什么偏置电压没关系，偏置电压就是为了抬高输出电位，方便电路后期处理是吧？ [quote][size=2][url=forum.php?mod=redirect&goto=findpost&pid=2215152&ptid=552748][color...
自动识别硬件的缺失。仓储管理系统中的软件指的是支持整个系统运作的软件部分，包括收货处理、上架管理、拣货作业、月台管理、补货管理、库内作业、越库操作、循环盘点、RF操作、加工管理、矩阵式收费等。仓储管理系统中的硬件指的是用于打破传统数据采集和上传的瓶颈问题，利用自动识别技术和无线传输提高数据的精度和传输的速度。管理经验指的是开发商根据其开发经验中客户的管理方式和理念整合的一套管理理念和流程，为企业做到...
这类的问题再出现前就要把这种问题消灭，在用料前严格执行对物料的检查程序，避免晶点问题的发生。厚度不一厚薄度不一有几点问题是值得注意的，各种材料在产生的过程中是有结状的，当出现放置错的情况时，呈现会发生厚度不一的状态。和材料的关系是在生产过程中材料没有把握好，温度没有控制好，才会发生这种恶劣的情况。温度的调控也是有关系的，并要根据温度的变化做好相应的控制工作，否则就会出现厚度不一的情况。处理办法是在...
款式和风格，经过客户同意，进行相应的设计，然后设计出品，最后成品。在磨具处理上，要先用石膏做出磨具，等磨具完全干化，把磨具进行处理，然后在上面弄上很多小孔，方面抽出空气。在做好磨具以后，要把石膏放到铁板上，根据其规格固定好，然后加热软化，等到冷却，作出磨具，最后一道工序就是整理，整理好方可售卖。拉线问题吸塑包装需在生产出产品以后可能会出现一条不规则的线路，会影响这个产品的质量和做工。出现这种情况不要...
处理客户咨询时，因为对发货及PCB工厂业务不够熟悉，很多问题需要向仓储部门辗转打听再行回复，客户体验不够好，于是提出了去仓库参观学习的想法，这个提议很快得到其他部门的积极响应。初识PCB打样上午9点准时集合，一行人驱车前往第一站，位于龙岗的嘉立创PCB样板厂，一个半小时的车程在大家的唱歌比赛游戏中倏忽而过。走进PCB样板厂，首先看到的是开料工序，各种厚度（从0.4mm到2.0mm）的铜板在这里被...
问题处理视频
你可能感兴趣的标签
热门资源推荐Phone: 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务
Categories
Tag Cloud 3D
WP Cumulus Flash tag cloud by
9 or better.
最新评论国内圈子
oracle security
本站文章除注明转载外，均为本站原创： 转载自
本文链接地址:
昨天给某客户升级的系统，经过TDE加密以后，今天上午出现严重的性能问题，表现的现象如下：
从top可以看到，cpu消耗非常之高，基本上在90~95%左右，奇怪的是user消耗只有30~40%左右，
大部分是sys消耗，断定db出问题了，通过QQ远程客户，进行了如下处理：
SQL& select event,count(*) from v$se
之后, 发现有70个左右的 resmgr:cpu quantum 等待，另外还有2~5个 asynch descriptor resize。
12345678910
昨天给某客户升级的系统，经过TDE加密以后，今天上午出现严重的性能问题，表现的现象如下：&从top可以看到，cpu消耗非常之高，基本上在90~95%左右，奇怪的是user消耗只有30~40%左右，大部分是sys消耗，断定db出问题了，通过QQ远程客户，进行了如下处理：&通过&SQL& select event,count(*) from v$session group by event;&之后, 发现有70个左右的 resmgr:cpu quantum 等待，另外还有2~5个 asynch descriptor resize。
但从等待事件来看，都没遇到过，查询mos发现了相关的资料：
High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource Manager Is Disabled [ID ]
11g: Scheduler Maintenance Tasks or Autotasks [ID ]
Large Waits With The Wait Event "Resmgr:Cpu Quantum" [ID ]
于是做出了如下调整：
但从等待事件来看，都没遇到过，查询mos发现了相关的资料：&High "Resmgr:Cpu Quantum" Wait Events In 11g Even When Resource Manager Is Disabled [ID ]11g: Scheduler Maintenance Tasks or Autotasks [ID ]Large Waits With The Wait Event "Resmgr:Cpu Quantum" [ID ]&于是做出了如下调整：
alter system set resource_manager_plan='';
execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('WEEKEND_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','');
execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
DBMS_AUTO_TASK_ADMIN.DISABLE(client_name =& 'sql tuning advisor',
operation =& NULL,
window_name =& NULL);
1234567891011121314151617
alter system set resource_manager_plan='';execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');execute dbms_scheduler.set_attribute('WEEKEND_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','');execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');&BEGIN&&DBMS_AUTO_TASK_ADMIN.DISABLE(client_name =& 'sql tuning advisor',&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& operation =& NULL,&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& window_name =& NULL);END;/
另外关于event asynch descriptor resize，从字面上理解就知道跟异步IO有关，当时通过top中cpu消耗较高的
几个进程，我关联v$process, v$session查询发现有几个进程所持有的event竟然是asynch descriptor resize，
于是做了如下调整：
另外关于event asynch descriptor resize，从字面上理解就知道跟异步IO有关，当时通过top中cpu消耗较高的几个进程，我关联v$process, v$session查询发现有几个进程所持有的event竟然是asynch descriptor resize，于是做了如下调整：
alter system set disk_async_io=false scope=
alter system filesystemio_options=none scope=
alter system set disk_async_io=false scope=alter system filesystemio_options=none scope=
然后跟开发商沟通了一下，重启了一下db，重启后观察主机资源情况，发现基本上正常了。
为了安抚客户，还是打车去了趟现场，到现场以后，还做了如下调整：
1. OPTIMIZER_INDEX_COST_ADJ 调整为默认值100。
2. 隐含参数_ASH_SIZE调整为16m(默认是8m), 当时查看alert日志发现有如下告警：
然后跟开发商沟通了一下，重启了一下db，重启后观察主机资源情况，发现基本上正常了。&为了安抚客户，还是打车去了趟现场，到现场以后，还做了如下调整：&1. OPTIMIZER_INDEX_COST_ADJ 调整为默认值100。2. 隐含参数_ASH_SIZE调整为16m(默认是8m), 当时查看alert日志发现有如下告警：
Mon Nov 21 14:42:24 2011
Archived Log entry 38536 added for thread 1 sequence 38650 ID 0x18c941ba dest 1:
Mon Nov 21 14:46:51 2011
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized.
If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the
value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 8388608 bytes. Both ASH
size and the total number of emergency flushes since instance startup can be monitored by running
the following query:
select total_size,awr_flush_emergency_count from v$ash_
Mon Nov 21 14:42:24 2011Archived Log entry 38536 added for thread 1 sequence 38650 ID 0x18c941ba dest 1:Mon Nov 21 14:46:51 2011Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 8388608 bytes. Both ASHsize and the total number of emergency flushes since instance startup can be monitored by runningthe following query:select total_size,awr_flush_emergency_count from v$ash_info;
3. 对于消耗逻辑度最为严重的3个sql语句，通过查询v$sql发现其有多个child number，看其执行计划也存在
多个执行计划，其中几个执行计划明显有问题，一会儿是index full scan一会儿是index skip scan。
于是为该几个sql创建了outline，如下：
3. 对于消耗逻辑度最为严重的3个sql语句，通过查询v$sql发现其有多个child number，看其执行计划也存在多个执行计划，其中几个执行计划明显有问题，一会儿是index full scan一会儿是index skip scan。于是为该几个sql创建了outline，如下：
SQL& alter session set create_stored_outlines=
Session altered.
SQL& exec dbms_outln.create_outline(,0);
PL/SQL procedure successfully completed.
-- 其他两个省略。
SQL& alter session set create_stored_outlines=true;&Session altered.&SQL& exec dbms_outln.create_outline(,0);&PL/SQL procedure successfully completed.&SQL&&&-- 其他两个省略。
晚上回家，查询mos发现，关于 asynch descriptor resize 果然存在bug，而且处理方式就是调整disk_type_io参数，如下：
晚上回家，查询mos发现，关于 asynch descriptor resize 果然存在bug，而且处理方式就是调整disk_type_io参数，如下：
Bug 9829397 – Excessive CPU and many “asynch descriptor resize” waits for SQL using Async IO [ID ]
07-SEP-2011
类型 PATCH
状态 PUBLISHED
Bug 9829397
Excessive CPU and many “asynch descriptor resize” waits for SQL using Async IO
This note gives a brief overview of bug 9829397.
The content was last updated on: 07-SEP-2011
details of each of the sections below.
Product (Component)
Oracle Server (Rdbms)
Range of versions believed to be affected
Versions &= 11.2 but BELOW 12.1
Versions confirmed as being affected
Platforms affected
Generic (all / most platforms affected)
believed to be a
in default behaviour thus:
Regression introduced in
This issue is fixed in
Related To:
Waits for “asynch descriptor resize”
Description
Some queries in 11.2 may exhibit higher CPU usage than earlier
releases with many "asynch descriptor resize" waits occurring
compared to the same SQL in earlier releases.
Rediscovery Notes:
Async IO is in use.
The total time waiting for "asynch descriptor resize" is
typically very small but with very high counts. The high
wait count indicates many resizes of the number of AIO
descriptors unnecessarily wasting CPU.
&strong&&span style="text-decoration:"&Workaround&/span&&/strong&
Disable async IO.
eg: Set DISK_ASYNCH_IO = false
1234567891011121314
Some queries in 11.2 may exhibit higher CPU usage than earlierreleases with many "asynch descriptor resize" waits occurringcompared to the same SQL in earlier releases. &Rediscovery Notes: Async IO is in use. The total time waiting for "asynch descriptor resize" is typically very small but with very high counts. The high wait count indicates many resizes of the number of AIO descriptors unnecessarily wasting CPU.&&strong&&span style="text-decoration:"&Workaround&/span&&/strong& Disable async IO. eg: Set DISK_ASYNCH_IO = false
最后调整以后系统基本正常了，单纯就系统资源来说，cpu idle维持在50~80%。
最后调整以后系统基本正常了，单纯就系统资源来说，cpu idle维持在50~80%。
No related posts.
on 十一月 21, 2011数据库技术（473）
Oracle Study之--resmgr:cpu quantum等待事件
在AWR Report中出现“resmgr:cpu quantum”等待事件：
“resmgr:cpu quantum”等待事件：
参考metalink的解决方案，是oracle资源管理方面的问题，原文如下：
High waits on&event 'resmgr:cpu quantum' might be noticed even when resource manager is disabled.&&&& You already have confirmed parameter RESOURCE_MANAGER_PLAN is set to null but still noticing the above wait events.
Top 5 Timed Foreground Events:
Avg wait(ms) % DB time Wait Class
------------------------ ------- -------- ------------ -------------- ---------- -----------
resmgr:cpu quantum
89.19 Scheduler
db file scattered read
3.81 User I/O
log file sync
2.78 Commit
db file sequential read
1.69 User I/O
This could be due to DEFAULT_MAINTENANCE_PLAN. From 11g onwards every weekday window has a pre-defined Resource
Plan called DEFAULT_MAINTENANCE_PLAN, which will become active once the related window opens.
Following entries can also be noted in alert log at the time of issue.
Wed Sep 16 02:00:00 2009
Clearing Resource Manager plan via parameter：
Wed Sep 16 22:00:00 2009
Setting Resource Manager plan SCHEDULER[0x2C55]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Wed Sep 16 22:00:05 2009
Begin automatic SQL Tuning Advisor run for special tuning task &SYS_AUTO_SQL_TUNING_TASK&
To disable the DEFAULT_MAINTENANCE_PLAN you can use the below steps as suggested in
1. Set the current resource manager plan to null (or another plan that is not restrictive):
alter system set resource_manager_plan='';
2. Change the active windows to use the null resource manager plan (or other nonrestrictive plan)
using:3. Then, for each window_name (WINDOW_NAME from DBA_SCHEDULER_WINDOWS), run:
execute dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN',''); execute dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');
3. Then, for each window_name (WINDOW_NAME from DBA_SCHEDULER_WINDOWS), run:
execute dbms_scheduler.set_attribute('&window name&','RESOURCE_PLAN','');
execute dbms_scheduler.set_attribute('&window name&','RESOURCE_PLAN','');
References
Database Hangs. Sessions wait for 'resmgr:cpu quantum'
11g: Scheduler Maintenance Tasks or Autotasks
Resource Manager and Sql Tunning Advisory DEFAULT_MAINTENANCE_PLAN
Large Waits With The Wait Event &Resmgr:Cpu Quantum&
但是很多用户会发现禁用资源计划很多时候没有作用.可以禁用Oracle缺省启用的资源调度,最后通过以下参数设置解决问题:
_resource_manager_always_on = false
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：427874次
积分：5533
积分：5533
排名：第4752名
原创：511篇
转载：87篇
(1)(2)(1)(5)(3)(4)(1)(5)(3)(1)(1)(8)(14)(4)(3)(11)(6)(7)(9)(12)(19)(14)(6)(6)(422)(3)(28)}
我要回帖
更多关于 cpu等待io时间比率高 的文章
更多推荐
- ·江北区中学排名中学在重庆市排名怎样？
- ·这是什是怎么画的？
- ·宝宝孙子周岁送什么礼物好礼物
- ·最适合人体健康的空气室内人体适宜的湿度是多少少?医学
- ·坐在学霸的棍棍上如何背单词词对吗？
- ·眼睛里布满了红血丝布满红血丝，头晕是什么症状
- ·恶性卵巢囊肿的症状是良性还是恶性用什么检查来判
- ·崴脚一年了筋还疼以后很长时间了还是疼是怎么
- ·做小孩做心脏手术查血能查出癌症吗乙肝吗专家
- ·直肠手术肛门管子拔了一直拉肚子怎么治肛门直肠脓肿回事
- ·一上火眼睛发红，前列腺炎平时注意什么些什么
- ·冠心病中药有哪些什么中药治疗好
- ·50天的宝宝37.8度算发烧吗37度9，到底该怎么处理
- ·如何评价索尼供应链评价的 Life Space UX
- ·如何检测手机ufs还是ufs2.0对比emmc5.1
- ·iphone里可以用移动手机卡吗
- ·找回被覆盖的微信号一个手机号重新注册微信找回原来两微信弟一个怎么样能找回
- ·vivox7插上vivox7充电器参数就一直响提示音，充不进去，换别的vivox7充电器参数也充不进去，摸后盖还有一种麻麻的感觉，
- ·想买一个手机oppr9s和vivox9哪个好,官网的是2799,同学说认识手机店的人,2400给我,靠谱吗
- ·cpu quantumio等待占用cpu事件怎么解决
- ·华为官网购买手机mates手机怎么样
- ·百度知道 十分钟内有问必答 立即下载 手机支付宝借呗突然无额度突然用不了，怎么回事
- ·这个小米发布会直播直播怎么回事？不给面子的。刚才显示的怎么突然就不显示。小米发布会直播手机桌面自动消失。这又是怎么回事
- ·刚刚下的使命召唤13cpu满载啦，现在一打开CPU100%使用然后直接70°怎么办？
- ·华为p7后盖怎么打开怎么换后盖呀
- ·雷电os抢红包神器怎么用 雷电os下载自动抢红包神器插件使用流程
- ·这个能自动解除异常状态理由安全模式吗，扣扣显示的是IP异常，几天能解除异常状态理由，在线等
- ·用另一部手机登微信蚂蚁借呗提示账号风险存在风险
- ·求张多多卡卡号密码大全号和密码，先私聊，后采纳
- ·卡包丹拿音箱特点有什么特点？在家里唱K可以使用卡包丹拿音箱特点吗？
- ·韩国节目评论小米手机主持人一谈小米是什么节目
- ·联想小新笔记本air pro13.3笔记本那个闪电熊标签可以撕掉吗
- ·我苹果5s还原密码忘记了了 怎么办
- ·手机一直都在正在准备genaralu盘是坏账准备转回什么意思思
