For the Oracle RAC cluster database, it has never been clear about how to achieve load balancing in terms of high JOB. I have tested it over the past few days and come to the following conclusions. One
For the Oracle RAC cluster database, it has never been clear about how to achieve load balancing in terms of high JOB. I have tested it over the past few days and come to the following conclusions. One
For the Oracle RAC cluster database, it has never been clear about how to achieve load balancing in terms of high JOB. I have tested it over the past few days and come to the following conclusions.
At what level can a JOB be customized. If a job is defined at the db level, the job can run on any active instance and follow the job scheduling mechanism;
If the job is defined at the instance level, the job will run on the specified instance. If an instance for creating a job is created as a machine due to an exception, the job will run on a surviving instance.
1. Currently, our rac database uses the select job, instance, And what fromdba_jobs query statement to view instance = 0, which indicates that the job is db-level, it can run on any active instance. The scheduling mechanism of the job determines which instance to run. That is to say, RAC will schedule jobs to run in different node instances based on the running status of the two servers. a job can run on machine A and may run on machine B next time;
2. By specifying the instance parameter in scheduling, you can specify that the job runs only on A specific instance. However, if the instance's server fails, it is found that the job is no longer running on instance, it does not switch to other instances. If a job is not specified to run on an instance when it is created, after the current running instance of the job is turned off, it can be switched to another active instance.
3. Generally, do not specify that a JOB runs on a specific instance when creating a job. If you want to specify that a JOB is running only on a specific instance. We recommend that you delete the job first, then recreate the job, and then specify the instance where the job runs during reconstruction. For example, you can modify an instance running a job in the following way: SQL> exec dbms_job.instance ). After testing, it is difficult to run the SQL statement. After the SQL statement is executed, the job is no longer running and a waiting event occurs: enq: TX-row lock contention. The executed SQL statement is update sys. job $ setthis_date =: 1 where job =: 2, that is, updating sys. job $ table. Only the session can be killed to eliminate the waiting event.
4. Currently, no SQL statement is found to check which instance a JOB runs on. If all the queries are 0 (default), they may be executed on any node. The stupid way is to check the CPU performance by using the TOP statement in Linux to determine whether load balancing is performed.