个人建议：
如果平时不高，突然激增的话，
1、看下连接数数量是否异常；
2、看报告SQL order by CPUtime排名靠前的两个SQL语句占CPU最高，看看是否可以优化。是否有绑定变量。
3、看报告SQL order by Version Counter，这些insert语句是否相似，是否绑定变量。

SQL order by cpu time中就是2个insert语句消耗的大，一直没有执行完。
SQL语句都是这样的，select个数可能不一样：
insert into T(col1,col2,…) select :var1,:var2,… from dual union all select :var1,:var2,… from dual union all select :var1,:var2,… from dual;

我看SQL order by Version Counter中version count 大于200的都没执行完，低于200的执行完了

TOP EVENT 53%resmgr :cpu quantum
参考https://www.eygle.com/archives/2011/07/events_resmgr_cpu_quantum.html
http://www.oracleplus.net/arch/1315.html
https://blog.csdn.net/u014346634/article/details/84961607
High “Resmgr:Cpu Quantum” Wait Events In 11g Even When Resource Manager Is Disabled (Doc ID 949033.1)
Resource Manager and SQL Tuning Advisory DEFAULT_MAINTENANCE_PLAN (Doc ID 786346.1)
等待事件 ‘resmgr:cpu quantum’ 是资源管理器用来控制 CPU 分配给进程的标准事件。当会话等待 ‘resmgr:cpu quantum’ 时，会话正在等待分配一个CPU时间额度 。

思路：1.对CPU的限制调整加大；
2.禁用资源调整，一般都是建议关闭资源调整
参考：禁用资源调整：
1.在线修改；
如果resource_manager_plan null可以无需重复设置
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’,’’);

2.如果上述操作没有生效，或者能够重启的情况下执行
alter system set “_resource_manager_always_on” = false scope=spfile;

对于这个AWR报告来说
DBTIME总时间占比 53%resmgr :cpu quantum
36% SQL

观察sql执行计划有无异常，SQL执行效率有无优化空间。

CPU冲高可能是结果 可以查看DBA_HIST_ACTIVE_SESS_HISTORY确认异常开始时间点 关注insert语句执行过程中等待事件和堵塞源头