Re: Resource Manager

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Tue, 14 Apr 2020 12:56:32 -0400
Message-ID: <CAP79kiQr8v+BukQcxFuamKSS_gS-rO=W8=yHGBmPLOP9MNiNCw_at_mail.gmail.com>



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_at_bluewin.ch> 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
>
>
>
> --
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Apr 14 2020 - 18:56:32 CEST

Original text of this message