resmgr:cpu quantum 等待事件 top 1

早上看昨天现场的报告,发现晚上七八点,resmgr:cpu quantum 等待事件排在i第一位,如下:

该事件是和资源管理相关的,如果启用资源管理计划,就可能遇到这个问题. 所以常规的解决方案是禁用资源管理。经查证是因为一个 bug 10326338  引起的。

解决方法如下:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = ‘FORCE:‘ scope=both;

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‘,‘‘);

原文地址:https://www.cnblogs.com/zhjh256/p/10043222.html

时间: 2024-10-14 14:39:23

resmgr:cpu quantum 等待事件 top 1的相关文章

Oracle Study之--resmgr:cpu quantum等待事件

Oracle Study之--resmgr:cpu quantum等待事件 在AWR Report中出现"resmgr:cpu quantum"等待事件: "resmgr:cpu quantum"等待事件: 参考metalink的解决方案,是oracle资源管理方面的问题,原文如下: Symptoms High waits on event 'resmgr:cpu quantum' might be noticed even when resource manage

使用DATABASE Log off收集oracle 等待事件信息

实例级别的监控,一直开启并且低开销: 建立基础表: create table sys.sesstat_history tablespace EOL as SELECT c.username,        c.osuser,        a.sid,        c.serial#,        c.paddr,        c.process,        c.logon_time,        a.statistic#,        b.name,        a.value

AWR报告中Top 10 Foreground Events存在”reliable message”等待事件的处理办法

操作系统版本:HP-UNIX B.11.31 数据库版本:11.2.0.4 RAC (一) 问题概要 (1)在AWR报告的Top 10 Foreground Events中发现reliable message占用了较高的DB Time,如下: Top 10 Foreground Events by Total Wait Time~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                               Total      

oracle9i statspack 报告 分析 direct path read 等待事件

DB Name         DB Id    Instance     Inst Num Release     Cluster Host ------------ ----------- ------------ -------- ----------- ------- ------------ LIXORA          1409317108 LIXORA                1 9.2.0.1.0   NO      lixora-DATA Snap Id     Sna

Oracle之 等待事件log file sync + log file parallel write (awr优化)

这是3月份某客户的情况,原因是server硬件故障后进行更换之后,业务翻译偶尔出现提交缓慢的情况.我们先来看下awr的情况. 我们能够看到,该系统的load profile信息事实上并不高,每秒才21个transaction.先来看看top5events: 从top 5event,我们能够发现,log file sync的avg wait很之高,高达124ms.大家应该知道,对于绝大多数情况 下,log file sync的平均等待时间是小于5ms的,这个值有点高的离谱. 我们知道,产生log

oracle之 等待事件LOG FILE SYNC (awr)优化

log file sycn是ORACLE里最普遍的等待事件之一,一般log file sycn的等待时间都非常短 1-5ms,不会有什么问题,但是一旦出问题,往往都比较难解决.什么时候会产生log file sync等待?常见有以下几种:1)commit操作2)rollback操作3)DDL操作(DDL操作实施前都会首先进行一次commit)4)DDL操作导致的数据字典修改所产生的commit5)某些能递归修改数据字典的操作:比如查询SEQ的next值,可能会导致修改数据字典.一个典型的情况是,

Oracle Study之--Oracle等待事件(8)

Oracle Study之--Oracle等待事件(8)      库缓存中的对象在库缓存中被切割成多个内存块,另有一个对象句柄记录了各个内存块的地址和其他的一些信息.当你要修改句柄中的信息时,需要在句柄上加独占锁,而如果另一个进程恰好在这时要求读.写句柄中的信息,它就必须等待.此时的等待就被Oracle记入Library cache lock事件.而读.写对象内存块也是无法同时进行的,有人如果正在写,你的读操作就必须等待,读写内存块的等待事件就是Library cache pin.如果这两个等

Oracle等待事件db file parallel read

SQL> select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = 'db file parallel read'; EVENT# NAME PARAMETER1 PARAMETER2 PARAMETER3 ---------- ------------------------------ --------------- --------------- --------------- 12

【翻译自mos文章】找到'cursor: pin S wait on X' 等待事件的阻塞者session(即:持有者session)

找到'cursor: pin S wait on X' 等待事件的阻塞者session(即:持有者session) 来源于: How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (Doc ID 786507.1) 适用于: Oracle Database - Enterprise Edition - Version 10.2.0.1 to 11.2.0.3 [Release 10.2 to 11.2