全面學習ORACLE Scheduler特性(2)管理jobs

同上

1.2  管理Jobs

1.2.1  啟用Jobs

　　前面建立JOB時，由於未顯式的指定ENABLED引數，因此即使指定了START_DATE，不過預設情況下JOB不會自動執行。對於這種情況，DBMS_SCHEDULER包中提供了一個過程ENABLE，可以用來修改JOB的啟用狀態，呼叫方式非常簡單，例如：

1.2.2  禁用Jobs

　　DBMS_SCHEDULER.ENABLE 僅用來將JOB(其實不僅僅對JOB有效，對於CHAIN、PROGRAM等也有效)的啟用狀態置為TRUE。如果想將其啟用狀態置為FALSE？簡單，還有一個與該功能對應的過程：DBMS_SCHEDULER.DISABLE，例如：

　　這兩個過程僅用來重置物件的狀態，因此均可以無限次執行，即使執行時物件已經被置為要指定的狀態。

1.2.3  修改Jobs

　　由於JOB的屬性眾多，難免時不時的可能會遇到需要修改的情況，比如說前面建立JOB時不小心，指定要執行的過程名輸入錯誤(完全有可能，CREATE_JOB在建立時不會自動檢查指定的過程是否有效，從這方面考慮，SCHEDULER不如普通JOB嚴謹哪)，這種情況下就必然涉及到對JOB的修改(或者說重定義)，沒問題，DBMS_SCHEDULER包中專門提供了一個過程SET_ATTRIBUTE，可以用來修改任務的屬性值。

　　例如，修改剛剛建立的JOB：INSERT_TEST_TBL執行的過程，執行語句如下：

　　當然啦，我們這裡執行的這條語句，執行跟沒執行沒有區別，此處僅做示例，大家表深究。

　　SET_ATTRIBUTE 過程雖然僅有三個引數，不過能夠修改的屬性值可是不少，以下列舉幾個較常用到的：

• LOGGING_LEVEL ：指定對jobs執行情況記錄的日誌資訊級別。

SCHEDULER 管理的JOB對任務的執行情況專門進行了記錄，同時使用者還可以選擇日誌中記錄資訊的級別，有下列三種選擇：

• DBMS_SCHEDULER.LOGGING_OFF ：關閉日誌記錄功能；
• DBMS_SCHEDULER.LOGGING_RUNS ：對任務的執行資訊進行記錄；
• DBMS_SCHEDULER.LOGGING_FULL ：記錄任務所有相關資訊，不僅有任務的執行情況，甚至連任務的建立、修改等也均將記入日誌。

提示：檢視SCHEDULER管理的JOB，可以透過USER_SCHEDULER_JOB_LOG和USER_SCHEDULER_JOB_RUN_DETAILS兩個檢視中查詢

• RESTARTABLE ：指定jobs執行出錯後，是否能夠適時重啟

建立任務時如未明確指定，本引數預設情況下設定為FALSE，如果設定為TRUE，就表示當任務執行時出錯，下次執行時間點到達時仍會啟動，並且如果執行仍然出錯，會繼續重新執行，不過如果連線出錯達到6次，該job就會停止。

• MAX_FAILURES ：指定jobs最大連續出錯次數

該引數值可指定的範圍從1-1000000，預設情況下該引數設定為NULL，表示無限制。達到指定出錯次數後，該job會被自動disable。

• MAX_RUNS ：指定jobs最大執行次數

該引數值可指定的範圍從1-1000000，預設情況下該引數設定為NULL，表示無限制(只是執行次數無限制，實際job會否繼續執行，仍受制於end_date以及max_failures等引數的設定)。達到指定執行次數後，該job也將被自動disable，並且狀態會被置為COMPLETED。

• JOB_TYPE ：指定job執行的任務的型別

有四個可選值：¨PLSQL_BLOCK¨, ¨STORED_PROCEDURE¨, ¨EXECUTABLE¨, and ¨CHAIN¨。

• JOB_ACTION ：指定job執行的任務

這一引數所指定的值依賴於JOB_TYPE引數中的值，比如說JOB_TYPE設定為¨STORED_PROCEDURE¨，那麼本引數值中指定的一定是ORACLE中的過程名。

• START_DATE ：指定job初次啟動的時間
• END_DATE ：指定job停止執行的時間

　　本引數又與AUTO_DROP相關聯，如果AUTO_DROP設定為TRUE的話，那麼一旦job到達停止執行的時間，該job就會被自動刪除，否則的話job任何存在，不過狀態被修改為COMPLETED。

　　除此之外，其它還包括MAX_RUN_DURATION，JOB_WEIGHT，INSTANCE_STICKINESS，STOP_ON_WINDOW_CLOSE，JOB_PRIORITY，SCHEDULE_LIMIT，PROGRAM_NAME，NUMBER_OF_ARGUMENTS，SCHEDULE_NAME，REPEAT_INTERVAL，JOB_CLASS，COMMENTS，AUTO_DROP，EVENT_SPEC，RAISE_EVENTS等等，這些引數所代表的意義此處不一一詳述，感興趣的朋友可以查閱相關官方文件，或者等待本系列文章的外傳，黑黑。

　　僅從這些可設定屬性就可以看出，Scheduler管理的job確實非常靈活，上述提到了這些引數，均可以使用DBMS_SCHEDULER.SET_ATTRIBUTE過程進行設定。

　　另外需要注意一點，除了使用者手動建立的jobs之外，資料庫在執行過程中也有可能自動建立jobs。對於這類jobs除非必要，否則不建議進行修改。至於如何區分jobs是使用者建立，還是資料庫自動建立，可以透過*_SCHEDULER_JOBS檢視的SYSTEM列來確定，如果該列顯示為TRUE，則表示由系統建立

1.2.4  執行Jobs

　　雖然說jobs大多都應該是自動執行，不過經過前面的示例，大家想必也認識到了，並不是說建立了jobs它就會自動執行，是否能夠真正自動執行並不是由你的主觀意願就能直接決定，而是由jobs自身的多個相關屬性決定。

　　關於jobs自動執行的話題相信看完前面的內容後，應該都知道如何設定，下面主要演示，如何手動呼叫jobs並執行，這其中，當然少不了DBMS_SCHEDULER包。例如，手動執行前面剛剛建立的job:INSERT_TEST_TBL：

　　Jobs 每執行一次，無論成功或失敗，均會在*_SCHEDULER_JOB_LOG中生成一條對應的記錄(前提是LOGGING_LEVEL屬性值未設定為DBMS_SCHEDULER.LOGGING_OFF)，同時，使用者也可以透過*_SCHEDULER_JOB_RUN_DETAILS檢視查詢job執行的詳細資訊。

1.2.5  停止Jobs

　　停止job可以使用DMBS_SCHEDULER.STOP_JOB過程，例如：

　　注意，STOP_JOB過程不僅僅是更新job的狀態，而是停止當前正在執行的任務，如果你處理的任務當前未在執行的話，那麼執行STOP_JOB過程，會觸發ORA-27366錯誤。

　　停止Jobs也會觸發一條任務的日誌資訊，對於執行停止操作的job，其*_SCHEDULER_JOB_LOG檢視的OPERATION會記錄為¨STOPPED¨，ADDITIONAL_INFO列中記錄的資訊類似¨REASON="Stop job called by user: username"¨。

1.2.6  刪除Jobs

　　刪除建立的job就比較簡單了，直接執行DBMS_SCHEDULER.DROP_JOB過程即可，例如：

　　刪除jobs並不是修改該job中某個欄位的標記值，而是直接刪除其在資料字典中的字義，因此被刪除的job如果未來發現仍然需要，只能重建，而無法透過其它方式快速恢復。不過，刪除jobs的操作，並不會級聯刪除這些job曾經執行過的日誌資訊。