3 Replies Latest reply: Sep 4, 2013 1:54 AM by spajdy RSS

    DBMS_SCHEDULAR JOB STICKINESS ON PARTICULAR NODE IN RAC

    6f6b9a5c-9090-4d3a-a654-18e8a6f23b44

      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

          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

            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

              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.