This discussion is archived
3 Replies Latest reply: Sep 3, 2013 11:54 PM by spajdy RSS

DBMS_SCHEDULAR JOB STICKINESS ON PARTICULAR NODE IN RAC

6f6b9a5c-9090-4d3a-a654-18e8a6f23b44 Newbie
Currently Being Moderated

Hi All,

 

I am using 10g rac . We have scheduled gather stats on node 1 from OEM with instance stickiness is False.

but it is  running on node2  sometimes  . When it runs on node 2 , node 1 is up and running with lightest load.

I am confused why it is running on  node 2?

Please help me out what are the possibilities for this issue.

 

Thanks,

Roopesh

  • 1. Re: DBMS_SCHEDULAR JOB STICKINESS ON PARTICULAR NODE IN RAC
    spajdy Pro
    Currently Being Moderated

    You could set instance ID to where job have to run using

    begin
      dbms_scheduler.set_attribute(name => '<job_owner>.<job_name>' ,attribute=>'INSTANCE_ID', value=> <instance_id>);
    end;
    /

     

    replace symbolic names in <> by your real values.

    When no instance_id is set then RAC load balance choose on node to run the job.

  • 2. Re: DBMS_SCHEDULAR JOB STICKINESS ON PARTICULAR NODE IN RAC
    6f6b9a5c-9090-4d3a-a654-18e8a6f23b44 Newbie
    Currently Being Moderated

    Hi,

     

    Thanks for your reply. Our DB version is 10.2.0.5 .  I have seen that Instance_id attribute is 11g .

     

    we set instance stickiness to false so it has to pick up the first available node means it has to go for node 1 to run the job.

     

    But why it is fluctuating nodes?


    what is the use of stickiness to false value?

     

    Please guide me. .

     

    Thanks,

    Roopesh.

  • 3. Re: DBMS_SCHEDULAR JOB STICKINESS ON PARTICULAR NODE IN RAC
    spajdy Pro
    Currently Being Moderated

    Doc for 10g say about instance_stickiness this:

    instance_stickinessThis attribute should only be used for a database running in RAC mode. By default, it is set to TRUE. If you set instance_stickiness to TRUE, jobs start running on the instance with the lightest load and the Scheduler thereafter attempts to run on the instance that it last ran on. If that instance is either down or so overloaded that it will not start new jobs for a significant period of time, another instance will run the job. If the interval between runs is large, instance_stickiness will be ignored an the job will be handled as if it were a non-sticky job.

    If instance_stickiness is set to FALSE, each instance of the job runs on the first instance available.

    For non-RAC environments, this attribute is not useful because there is only one instance.

    So check you job repeat_interval.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points