今天用oracle的定時任務來實現定時檢測。于是goole了一把，在經歷了片刻迷茫后，還是實現了。故小作記錄，以備忘之：
1．確保Oracle的工作模式允許啟動任務隊列管理器
Oracle定時執行“Job Queue”的后臺程序是SNP進程，而要啟動SNP進程，首先要確保整個系統的模式是可以啟動SNP進程的，這需要以DBA的身份去執行如下命令：
svrmgrl> alter system enable restricted session;
或sql> alter system disenable restricted session;
利用如上命令更改系統的會話方式為disenable restricted，為SNP的啟動創造條件。
（我在設置該參數的時候，似乎并不能成功，提示“非法的alter system 選項”，于是就沒管）
2．確保Oracle的系統已經配置了任務隊列管理器的啟動參數
SNP的啟動參數位于Oracle的初始化文件中，該文件放在＄ORACLE_HOME/dbs路徑下，如果Oracle的SID是myora8的話，則初始化文件就是initmyora8.ora，在文件中對SNP啟動參數的描述部分如下：
job_queue_process=n
job_queue_interval=N
第一行定義SNP進程的啟動個數為n。系統缺省值為0，正常定義范圍為0～36，根據任務的多少，可以配置不同的數值。
第二行定義系統每隔N秒喚醒該進程一次。系統缺省值為60秒，正常范圍為1～3600秒。事實上，該進程執行完當前任務后，就進入睡眠狀態，睡眠一段時間后，由系統的總控負責將其喚醒。
如果該文件中沒有上面兩行，請按照如上配置添加。配置完成后，需要重新啟動數據庫，使其生效。注意：如果任務要求執行的間隔很短的話，N的配置也要相應地小一點。
（這里所說的正常范圍為1～3600秒，我不知道如果我設成1，即24小時）
3. 將任務加入到數據庫的任務隊列中
調用Oracle的dbms_job包中的存儲過程，將任務加入到任務隊列中：
dbms_job.submit( job out binary_integer,
what in archar2,
next_date in date，
interval in varchar2,
no_parse in boolean)
其中：
●job：輸出變量，是此任務在任務隊列中的編號；
●what：執行的任務的名稱及其輸入參數；
●next_date：任務執行的時間；
●interval：任務執行的時間間隔。
下面詳細討論一下dbms_job.submit中的參數interval。嚴格地講，interval是指上一次執行結束到下一次開始執行的時間間隔，當interval設置為null時，該job執行結束后，就被從隊列中刪除。假如我們需要該job周期性地執行，則要用‘sysdate＋m’表示。 這里的m是以（天）為單位的，即：24小時執行1次，m＝1;
將任務加入到任務隊列之前，要確定執行任務的數據庫用戶，若用戶是scott, 則需要確保該用戶擁有執行包dbms_job的權限；若沒有，需要以DBA的身份將權利授予scott用戶：
svrmgrl> grant execute on dbms_job to scott;
例如：
SQL> variable n number;
SQL> begin
2 dbms_job.submit(:n,'statchangetable;',sysdate,
3 'sysdate+1/360');
4 commit;
5 end;
6 /
添加后可以查看一下任務的信息：
SQL> select job,last_date,last_sec,next_date,next_sec,broken,failures from
2 dba_jobs;
JOB LAST_DATE LAST_SEC NEXT_DATE NEXT_SEC B FAILURES
---------- ---------- ---------------- ---------- ---------------- - ----------
1 22-8月 -06 16:26:57 22-8月 -06 16:30:57 N 13
2 22-8月 -06 16:27:17 22-8月 -06 16:31:17 N 5
3 22-8月 -06 16:27:02 22-8月 -06 16:31:02 N 0
經過測試，我的換表存儲過程終于自動工作了，換表于無形之中...
不過在查找資料的時候發現有位兄臺的遭遇值得記錄一下，就是oracle在9.2.0.6版本前，在Solaris平臺上有個bug：在運行到497天后會出現計時器溢出，從而導致停止執行任務。