ORACLE job作業BROKEN狀態無法改變與ORA-12005&ORA-06550

        近日，一客戶遇到一oracle job的broken狀態無法改變。

        一、現象描述

        根據客戶描述，其維護的oracle資料庫內有兩個Job作業被停止了，但是Job的BROKEN狀態一直是yes狀態，使用

Toad客戶端工具修改成no之後，重新登陸Toad客戶端檢視被修改的job作業BROKEN狀態屬性依然是yes狀態。

        二、問題分析

        接到問題之後，遠端上去，客戶演示了一遍問題發生的過程。站在DBA的角度，我不信任Toad第三方工具，於是讓

客戶登陸shell連線到資料庫伺服器端，使用sql命令EXEC DBMS_JOB.BROKEN(23,FALSE); commit;直接 修改，由於使

用的是sys使用者並非job作業的宿主，提示ORA-23421錯誤。於是，切換至job作業宿主執行job的broken狀態更改，命令

執行很順利但是使用如下sql語句再次檢視job狀態時，發現job的broken屬性還是yes，揉揉眼定睛再看依舊是yes。

SELECT JOB,NEXT_DATE,NEXT_SEC,FAILURES,BROKEN FROM DBA_JOBS where JOB=23;

        到這裡，個人覺得很奇怪，資料庫應該給異常提示才對，於是檢視下資料庫的告警日誌，果然有 發現：

透過資料庫的告警日誌發現執行 EXEC DBMS_JOB.BROKEN(23,FALSE); commit;時，有ORA-12005告警提示，根據提示

的資訊猜測相關job作業的interval屬性設定有問題。於是，檢視job的interval配置資訊，配置資訊如下圖：

根據job作業的interval設定trunc(sysdate,'MM')+14+1/24，詢問客戶設定的意圖為每個月14號自動執行該job作業。

但是，job作業的interval設定就有問題了，一旦過了當前月份的14號相當於job作業執行完了最後一次不迴圈執行，

所以，11月16日interval時間變成11月14日，當手工再次執行 EXEC DBMS_JOB.BROKEN(23,FALSE); commit;修改作

業自動執行broken狀態時提示 ORA-12005。

       三、問題處理

        客戶的目的，需要設定的job作業interval為Interval =>TRUNC(LAST_DAY(SYSDATE))+14+1/24，意思是當月

14日執行完該job作業後，job的下次執行計劃安排在下個月的14日，job作業的broken狀態就不會自動變為yes且無法

修改為no。

        小插曲：客戶在按提示修改job作業interval屬性時，誤將 Interval =>TRUNC(LAST_DAY(SYSDATE))+14+1/24整

體填進toad客戶端interval屬性框，提交修改時提示ORA-06550如下圖，其實問題很簡單，只需將日期運算公式

TRUNC(LAST_DAY(SYSDATE))+14+1/24填進toad客戶端的interval即可。其實，個人建議Toad應該在第一次修改job作

業broken狀態時提示錯誤ORA-12005，這樣就能第一時間發現問題。

        根據提示，客戶最終成功完成了job作業的重置：

        四、問題總結

        客戶端工具使用過程中相比伺服器端有差距，不利於問題的第一時間發現；程式編制過程中，最好做測試，避免類似

作業異常排查發現這種日期類邏輯錯誤問題；熟悉客戶端的使用方法，避免類似ORA-06550低階錯誤。