某種情況下,我們會用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更改的機率很低。

創作者介紹

Jason Lin 的資料庫

jsdb 發表在 痞客邦 PIXNET 留言(0) 人氣()