As far as I know (as a heavy user of resource manager) , there is no
correlation between CPU_COUNT and resource manager ?
If CPU_COUNT isn't being set dynamically by the instance, then it sounds
like someone set it manually to null (which I didn't think was possible).
So double check gv$parameter where name = 'cpu_count' to see if its set,
and has been modified. If it's set and is modified you can reset it to
default but I think will require a db bounce for it to autopopulate. You
can also set it manually as you would expect to to the number of cpus shown
by the OS , but don't set it higher than the number of CPUs shown by the OS.
As far as "resource_manager_plans" that's another parameter you can check
in gv$parameter to see what it's set to.
You can force a plan if you want using "FORCE:" key word such as:
alter system set resource_manager_plan="FORCE:<some plan name>" scope=both
sid='*' ;
That will prevent it from changing.
DBA_SCHEDULER_WINDOWS will automatically set the plan if the scheduler
window has:
a.) a resource plan specified AND
b.) the window has the allow_scheduler_plan_switches set to TRUE
Chris
On Tue, Apr 14, 2020 at 10:23 AM Lothar Flatz <l.flatz@xxxxxxxxxx> wrote:
Hi,
Resource Manager Plan is not Set. AWR reports
"SCHEDULER[0x32D9]:DEFAULT_MAINTENANCE_PLAN".
Parameter CPU_COUNT is not set.
My understanding is : Resource Manager is active during maintenance
windows only.
CPU_COUNT will be derived. It does not matter if it is set or not.
Would explicit setting CPU_COUNT activate Resource Manager outside of
maintenance windows?
Would setting CPU_COUNT to the default value (os cores * 2) make a
difference to not setting a value?
Regards
Lothar
--
--
//www.freelists.org/webpage/oracle-l
