Re: Scheduler Jobs are not distributed according to OS-load on RAC noes

From: <niall.litchfield_at_gmail.com>
Date: Tue, 11 Dec 2018 08:47:37 +0000
Message-ID: <CABe10sZwivaDP-YaBFt2bt_a_5jhb_WcFKAbHePzLwC3rbdOBw_at_mail.gmail.com>


Hi Martin

What are the load balancing properties of the service set to? On Tue, Dec 11, 2018 at 8:45 AM Martin Berger <martin.a.berger_at_gmail.com> wrote:
>
> Hi List,
>
> I have a strange situation with a 4-node RAC - 12.2 (July 2018) Oracle Linux 6.10:
>
> After some time, one (or several) instances stop executing jobs.
>
> Every hour we are scheduling a lot of one-time jobs to run a lot of data loads. The Jobs are scheduled by a master which takes care of dependencies - so a job is only scheduled, when all it dependencies are met and should run as soon as resources (job processes) are available. (No dependencies are defined in dbms-scheduler framework).
> The jobs use a JOB_CLASS which as a dedicated SERVICE - this SERVICE is available on all 4 instances. Stop&Start of the service on the "idle" instance does not help.
> NTP is fine according to cluvfy comp clocksync -n all .
> instance_stickiness is TRUE (the default) - but I don't think this will change anything as our jobs run one-time only.
>
> Does anyone know how to identify, why sometimes some instances refuse to run scheduled jobs?
> Who is doing this decision, and can it be traced somehow to identify based on which numbers the decision is done?
> Any other suggestions?
>
> A SR at MOs is open, but without any progress.
>
> related documents found so far:
>
> DBMS_SCHEDULER job doesn't fail-over across RAC instance ( Doc ID 2365434.1 )
> RAC Node X Is Seeing A Higher Session Load Than The Other Nodes For Scheduler Jobs ( Doc ID 1602581.1 )
> ENH 28592547 - REAL-TIME LOAD BALANCING FOR JOBS ACROSS RAC INSTANCES
>
> --
> Martin Berger Oracle ♠
> martin.a.berger_at_gmail.com @martinberx
> ^∆x http://berxblog.blogspot.com
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Dec 11 2018 - 09:47:37 CET

Original text of this message