10G的dbms_scheduler是可以运行external job的,象SH 文件,但是运行的条件还是比较多的,下面列出一些条件你必须要去检查的。
1. job_queue_processes may be too low.
SQL> select value from v$parameter where name=’ job_queue_processes’;
SQL> select count(0) from dba_scheduler_running_jobs;
SQL> select count(0) from dba_jobs_running;
2. max_job_slave_processes may be too low.
SQL> select value from dba_scheduler_global_attribute where attribute_name='MAX_JOB_SLAVE_PROCESSES';
SQL> select count(0) from dba_scheduler_running_jobs;
You can increase the number or just NULL it out using
SQL> exec dbms_scheduler.set_scheduler_attribute (‘MAX_JOB_SLAVE_PROCESSES’,NULL);
3. sessions may be two low
SQL> select value from v$parameter where name='sessions';
You can increase it.
4. Have you recently applied a timezone update patch or upgraded the database to a version with newer timezone information ?
If you skipped any steps when updating the timezone information, jobs may not run. To check whether this is the case try doing:
SQL> select * from sys.scheduler$_job; and make sure it finishes without errors.
If it throws a timezone warning, reapply the upgrade or timezone patch making sure to follow all the steps.
5. Is the database running in restricted mode?
If the database is running in restricted mode then no jobs will run (unless you are using 11g and use the ALLOW_RUNS_IN_RESTRICTED_MODE attribute). To check this use
SQL> select logins from v$instance;
If logins is restricted you can disable the restricted mode using
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
6. Has the Scheduler been disabled?
This is not a supported action but it is possible that someone has done it anyway. To check this do
SQL> select value from dba_scheduler_global_attribute where attribute_name='SCHEDULER_DISABLED’;
If this query returns TRUE then you can fix this using
SQL> exec dbms_scheduler. set_scheduler_attribute ('scheduler_disabled','false');
7. On UNIX systems, in releases including and after 10.2.0.2 there is a file $ORACLE_HOME/rdbms/admin/externaljob.ora, all external jobs not in the SYS schema and with no credential run as the user and group specified in this file. This should be nobody:nobody by default.
8. rdbms/admin/externaljob.ora file must must be owned by root:oraclegroup and be writable only by the owner i.e. 644 (rw-r--r--). It must contain at least two lines: one specifying the run-user and one specifying the run-group.
9. bin/extjob file must be also owned by root:oraclegroup but must be setuid i.e. 4750 (-rwsr-x---).
10. bin/extjobo should have normal 755 (rwxr-xr-x) permissions and be owned by oracle:oraclegroup.
11. The shell file which you want to run under SYS schema (I did at least), grant appropriate privilege to it. I grant it as following: # chown nobody:nobody test.sh # chmod +x test.sh
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/561895/viewspace-366429/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/561895/viewspace-366429/