某種情況下，我們會用table接收前端系統的資料，並在那之後進行一些後製處理。
問題是我們無法得知資料何時會被更新。
有些人會把這些後製工作寫在table trigger裡。
這方法很簡單，但缺點是前端系統的session要等trigger裡的工作做完才能結束，
而且當trigger觸發任何exception，所有動作都可能被rollback。
某些人會在特定時間起job來做這些後製工作，並再稍後另起一個job來監控前面這個job是否完成。
這方法不能妥善處理可能的錯誤。
我四年前剛應徵到這個工作的時候，做了一個改善方法。
起一個job來監控table資料變動並在發現資料變動後進行後製處理。
這個方法需要做出能夠判斷資料變動的程式邏輯，以及間隔時間極短的job才能快速反應資料變動。
這是個複雜的實做方法，有許多方法可提昇效能以進行監控、檢查、資料處理。
而這些效能改善是必須的，以免資料庫整體效能受拖累。
改善這個機制後，我不需要在這個例行程式投入太多時間。
我就能把時間運用在更重要的事情上，例如改善舊系統、開發新系統。
今天DBA要我減少這種頻繁啟動的job，這並不容易。
目標：
1. 維持快速反應資料變動 (2分鐘內)
2. 與前端系統程式無關聯 (不在trigger內執行)
3. 等所有前端資料來源都完成才進行後製處理 (現在是兩個前端資料來源程式個別執行)
4. job執行頻率低
所幸我早已實做了很好的資料變動檢查機制。
每個前端資料來源執行完後會把自己的名字和當下時間塞入簽到table。
現行的機制是每分鐘檢查這個簽到table，當發現所有前端資料來源在時間範圍內都簽到後就執行後製工作。
花了幾分鐘，我就想到了新作法。
我在簽到table加trigger，只有一行指令'dbms_job.next_date(1, SYSDATE + 1/1440);'
1就是現在的job no。
既然現行機制0.5秒就能檢查資料變動。
資料到齊前後製程序不會被執行，而且job正在執行時next date再被trigger更改的機率很低。
留言列表
