oracle job使用詳解及job不運行的檢查方法

天天1點執行的oracle JOB樣例

DECLARE X NUMBER; BEGIN SYS.DBMS_JOB.SUBMIT ( job => X, what => 'ETL_RUN_D_Date;', next_date => to_date('2009-08-26 01:00:00','yyyy-mm-dd hh24:mi:ss'), interval => 'trunc(sysdate)+1+1/24', no_parse => FALSE ); SYS.DBMS_OUTPUT.PUT_LINE('Job Number is: ' || to_char(x)); COMMIT; END; / 以上是明確指定天天的1點執行此job,若是指定是天天中午12點執行interval須要指定爲'trunc(sysdate)+1+12/24',若是僅僅指定interval爲一天,這樣當你手工用dbms_job.run(job)去運行一次時,job天天的執行時間是會改變的,若是你想job天天在固定時間執行,能夠參考上面的例子.

初始化相關參數job_queue_processes alter system set job_queue_processes=39 scope=spfile;//最大值不能超過1000 ;job_queue_interval = 10 //調度做業刷新頻率秒爲單位

job_queue_process 表示oracle可以併發的job的數量，能夠經過語句　　

show parameter job_queue_process;

來查看oracle中job_queue_process的值。當job_queue_process值爲0時表示所有中止oracle的job，能夠經過語句

ALTER SYSTEM SET job_queue_processes = 10;

來調整啓動oracle的job。

相關視圖： dba_jobs all_jobs user_jobs dba_jobs_running 包含正在運行job相關信息

－－－－－－－－－－－－－－－－－－－－－－－－－

提交job語法：

begin sys.dbms_job.submit(job => :job, what => 'P_CLEAR_PACKBAL;', next_date => to_date('04-08-2008 05:44:09', 'dd-mm-yyyy hh24:mi:ss'), interval => 'sysdate+ 1/360'); commit; end; /

－－－－－－－－－－－－－－－－－－－－－－－－－ 建立JOB variable jobno number; begin dbms_job.submit(:jobno, 'P_CRED_PLAN;',SYSDATE,'SYSDATE+1/2880',TRUE); commit;

運行JOB SQL> begin dbms_job.run(:job1); end; /

刪除JOB SQL> begin dbms_job.remove(:job1); end; /

DBA_JOBS ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 字段（列） 類型 描述 JOB NUMBER 任務的惟一標示號 LOG_USER VARCHAR2(30) 提交任務的用戶 PRIV_USER VARCHAR2(30) 賦予任務權限的用戶 SCHEMA_USER VARCHAR2(30) 對任務做語法分析的用戶模式 LAST_DATE DATE 最後一次成功運行任務的時間 LAST_SEC VARCHAR2(8) 如HH24:MM:SS格式的last_date日期的小時，分鐘和秒 THIS_DATE DATE 正在運行任務的開始時間，若是沒有運行任務則爲null THIS_SEC VARCHAR2(8) 如HH24:MM:SS格式的this_date日期的小時，分鐘和秒 NEXT_DATE DATE 下一次定時運行任務的時間 NEXT_SEC VARCHAR2(8) 如HH24:MM:SS格式的next_date日期的小時，分鐘和秒 TOTAL_TIME NUMBER 該任務運行所須要的總時間，單位爲秒 BROKEN VARCHAR2(1) 標誌參數，Y標示任務中斷，之後不會運行 INTERVAL VARCHAR2(200) 用於計算下一運行時間的表達式 FAILURES NUMBER 任務運行連續沒有成功的次數 WHAT VARCHAR2(2000) 執行任務的PL/SQL塊 CURRENT_SESSION_LABEL RAW MLSLABEL 該任務的信任Oracle會話符 CLEARANCE_HI RAW MLSLABEL 該任務可信任的Oracle最大間隙 CLEARANCE_LO RAW MLSLABEL 該任務可信任的Oracle最小間隙 NLS_ENV VARCHAR2(2000) 任務運行的NLS會話設置 MISC_ENV RAW(32) 任務運行的其餘一些會話參數

－－－－－－－－－－－－－－－－－－－－－－－－－－ 描述 INTERVAL參數值 天天午夜12點 'TRUNC(SYSDATE + 1)' 天天早上8點30分 'TRUNC(SYSDATE + 1) + （860+30）/(2460)' 每星期二中午12點 'NEXT_DAY(TRUNC(SYSDATE ), ''TUESDAY'' ) + 12/24' 每月第一天的午夜12點 'TRUNC(LAST_DAY(SYSDATE ) + 1)' 每一個季度最後一天的晚上11點 'TRUNC(ADD_MONTHS(SYSDATE + 2/24, 3 ), 'Q' ) -1/24' 每星期六和日早上6點10分 'TRUNC(LEAST(NEXT_DAY(SYSDATE, ''SATURDAY"), NEXT_DAY(SYSDATE, "SUNDAY"))) + （6×60+10）/（24×60）'

－－－－－－－－－－－－－－－－－－－－－－－－－－

1:每分鐘執行

Interval => TRUNC(sysdate,'mi') + 1/ (24*60)

或

Interval => sysdate+1/1440

2:天天定時執行

例如：天天的凌晨1點執行

Interval => TRUNC(sysdate) + 1 +1/ (24)

3:每週定時執行

例如：每週一凌晨1點執行

Interval => TRUNC(next_day(sysdate,'星期一'))+1/24

4:每個月定時執行

例如：每個月1日凌晨1點執行

Interval =>TRUNC(LAST_DAY(SYSDATE))+1+1/24

5:每季度定時執行

例如每季度的第一天凌晨1點執行

Interval => TRUNC(ADD_MONTHS(SYSDATE,3),'Q') + 1/24

6:每半年定時執行

例如：每一年7月1日和1月1日凌晨1點

Interval => ADD_MONTHS(trunc(sysdate,'yyyy'),6)+1/24

7:每一年定時執行

例如：每一年1月1日凌晨1點執行

Interval =>ADD_MONTHS(trunc(sysdate,'yyyy'),12)+1/24

JOB不運行的檢查步驟：

ORACLE有一種定時調度機制，用dbms_job包來管理。

　　設置的JOB就是不運行，搞得的鬱悶，

　　最好執行了這個才搞定 exec dbms_ijob.set_enabled(true);

　　下面提供一個checklist用於檢查job異常的緣由：

　　1) Instance in RESTRICTED SESSIONS mode?

　　Check if the instance is in restricted sessions mode:

　　select instance_name,logins from v$instance;

　　If logins=RESTRICTED, then:

　　alter system disable restricted session;

　　^– Checked!

　　2) JOB_QUEUE_PROCESSES=0

　　Make sure that job_queue_processes is > 0

　　show parameter job_queue_processes

　　^– Checked!

　　3) _SYSTEM_TRIG_ENABLED=FALSE

　　Check if _system_enabled_trigger=false

　col parameter format a25

　　col value format a15

　　select a.ksppinm parameter,b.ksppstvl value from x$ksppi a,x$ksppcv b

　　where a.indx=b.indx and ksppinm=’_system_trig_enabled’;

　　If _system_trig_enabled=false, then

　　alter system set 「_system_trig_enabled」=TRUE scope=both;

　　^– Checked!

　　4) Is the job BROKEN?

　　select job,broken from dba_jobs where job=<job_number>;

　　If broken, then check the alert log and trace files to diagnose the issue.

　　^– Checked! The job is not broken.

　　5) Is the job COMMITted?

　　Make sure a commit is issued after submitting the job:

BEGIN

　　SYS.DBMS_JOB.SUBMIT

　　(

　　job => X

　　,what => ‘dbms_utility.analyze_schema

　　(」SCOTT」,」COMPUTE」,NULL,NULL,NULL);’

　　,next_date => to_date(’08/06/2005 09:35:00′,’dd/mm/yyyy hh24:mi:ss’)

　　,no_parse => FALSE

　　);

　　COMMIT;

　　END;

　　/

　　If the job executes fine if forced (i.e., exec dbms_jobs.run(<job_no>);), then likely a commit

　　is missing.

　　^– Checked! The job is committed after submission.

　　6) UPTIME > 497 days

　　Check if the server (machine) has been up for more than 497 days:

　　For SUN, use ‘uptime’ OS command.

　　If uptime>497 and the jobs do not execute automatically, then you are hitting unpublished bug 3427424

　　(Jobs may stop running after 497 days uptime) which is fixed in 9206 and A102

　　^– Checked! The server in this case has been up 126 days only

　　7) DBA_JOBS_RUNNING

　　Check dba_jobs_running to see if the job is still running:

　　select * from dba_jobs_running;

　　^– Checked! The job is not running.

　　LAST_DATE and NEXT_DATE

　　Check if the last_date and next_date for the job are proper:

　　select Job,Next_date,Last_date from dba_jobs where job=<job_number>;

^– NEXT_DATE is porper, however LAST_DATE is null since the job never executes automatically.

9. NEXT_DATE and INTERVAL

　　Check if the Next_date is changing properly as per the interval set in dba_jobs:

　　select Job,Interval,Next_date,Last_date from dba_jobs where job=<job_number>;

　　^– This is not possible since the job never gets executed automatically.

　　10) Toggle value for JOB_QUEUE_PROCESSES

　　Stop and restart CJQ process(es)

　　alter system set job_queue_processes=0 ;

　　–<Wait for some time to ensure CJQ process stopped>

　　alter system set job_queue_processes=4 ;

　　Ref: Bug 2649244 (fixed by: 9015, 9203, 10201)

　　^– Done but did not help

　　11) DBMS_IJOB(Non-documented):

　　Last ditch effort.

　　Either restart the database or try the following:

　　exec dbms_ijob.set_enabled(true);

　　Ref: Bug 3505718 (Closed, Not a Bug)

　　Done but did not help

　　These are the most common causes for this behavior.

　　Solution

　　The solution ended up to be the server (machine) uptime.

　　Even though it was up for only 126 days, after the server was rebooted all jobs were able to execute automatically.

　　To implement the solution, please execute the following steps:

　　1. Shutdown all applications, including databases.

　　2. Shutdown the server (machine)

　　3. Restart all applications, including databases.

　　4. Check that jobs are executing automatically.

　　from metalink docs ： 313102.1