基于MES系統業務邏輯的性能優化

楊久莉，石國玲，段季芳

（合肥京東方光電科技有限公司 自動化技術部，合肥 233100）

基于MES系統業務邏輯的性能優化

楊久莉，石國玲，段季芳

（合肥京東方光電科技有限公司 自動化技術部，合肥 233100）

MES是面向制造企業車間執行層的生產信息化管理系統，在系統初期由于數據量小、系統壓力輕，其系統的缺點不易暴露出來。隨著時間的推移，各種問題都會出現。在性能調優的方法中最常用的方法是SQL調優，但是有的SQL已經是最優，只能通過修改業務邏輯來實現調優的目的。本文列舉幾個比較經典的案例，以期為MES系統開發和維護人員提供幫助。

MES系統；業務邏輯；性能；優化

MES系統的性能直接關系到工廠一線的生產，性能低下的系統功能會直接影響到工廠的生產進度，從而間接影響到產能。因此，高效的業務執行在MES系統中至關重要，在生產總數據量龐大、單位時間內業務處理量高的繁忙系統中更加明顯。本文將結合生產制造行業的MES系統特征，以實際業務系統中出現的業務查詢和更新時性能問題作為出發點，結合業務邏輯，有效地實現了業務處理性能的改善。

1　SimpleJdbcCall——增加對參數類型賦值，避免調用元數據

應用的SQL性能一般通過AWR報告來分析，出現報告中Top SQL上的語句一般需要進行性能分析。通過觀察AWR發現有兩條查詢占用33.7%的DB Time，其SQL是用來查詢系統表的數據，且使用者是用戶。

經分析，這兩條SQL是應用使用SimpleJdbcCall調用存儲過程或者函數產生的。SimpleJdbcCall是一個多線程、可重用，用來調用存儲過程或者函數的工具，它通過提供元數據的處理方式來簡化對基本存儲過程和函數的訪問。在執行存儲過程或者函數時，只需要提供執行存儲過程或函數的名字和用Map表示的相應的參數，這些參數的名字將會與創建存儲過程或者函數時定義的參數名進行匹配。

這種方式為應用程序開發者簡化了代碼，但是對于存儲過程或者函數使用較多的系統，則會出現資源爭用的情況。SimpleJdbcCall提供的addDeclaredParameter方法來指定每個變量的類型，就可以避免SimpleJdbcCall在執行存儲過程或者函數時先調用元數據的過程。因此，將應用上所有的函數中增加了addDeclaredParameter這個方法，完成優化后不但提高業務的處理速度，也降低對DB資源的爭用情況，兩個查詢從Top SQL中消失。

2　索引列使用默認值代替NULL值

筆者觀察AWR發現有一條SQL，它的平均執行時間為0.2s，占了接近1.73%的DB Time，但是對應表是一個20M的小表，這樣的查詢出現在Top SQL中絕對是有問題的。分析其執行計劃，CBO選擇IDX_01，Cost數值為653。

對數據及查詢結果進行分析，此表總數據約為24萬條，此查詢的結果返回13條基準信息。IDX_01索引列名為（FACTORYNAME），而整張表中此列值相同，沒有任何選擇度；其次，此表還有一個基于（SUPERAREANAME）列的索引IDX_02，而要查詢出來的數據所對應的SUPERAREANAME為NULL值。即使在Where條件上SUPERAREANAME的篩選條件，基于以上數據分布和Oracle的特性，該CBO不會選擇IDX_02。綜合業務分析，最終將這13條數據的SUPERAREANAME列填寫具有區分度的數據，并將此列加到Where條件中。再次分析執行計劃，Cost數值由652降低為2。再次查看AWR，此條SQL從Top SQL中消失了。

以上案例可以看到，對單表進行查詢優化時，先對數據和現有的Index進行分析，有時候不需要建立額外的Index，而是對數據稍作變動，就能解決問題。由于B*Tree索引不存儲Null值，所以查詢NULL值數據時，Oracle會因為Null值的存在而放棄索引。為了此種情況發生，使用默認值代替NULL值，或者在建立index時使用聯合索引而非獨立索引。

3　大量查詢——小表替換大表

用戶一直反映某個查詢較慢，經常因為查詢時間較長而收到超時錯誤。分析此查詢的SQL語句，語句并不復雜，當前使用的索引也是最優的。通過tkprof工具對Trace文件進行分析，發現SQL執行的主要時間是花費在數據獲?。╢etch）上，total數據為：disk （51163）、query（76985）、current（0）、rows（1764），平均每行所需的block數=（query+current）/rows，此查詢平均讀取每行需要的Block數約為44塊。正常情況，訪問一條數據的速度由索引的高度和回表查詢的IO決定，一般索引高度都在3層以下，正常查詢一條數據，IO在4個以內。即訪問一條數據需要訪問的數據塊的個數不超過4個，本案例中達到44塊，說明索引的掃描效率太低，或者說該索引不合適該查詢。經過數據分析發現，需要查詢的數據只占整個表的小部分，總共73 639行數據，且分布在67 041個數據塊中，因此考慮根據數據狀態，將大表拆分，如果再建立合適的索引，查詢效率就會非常的高。

此表由一個工廠和庫房共用，數據量為61Gb、數據為79 934 965行，數量巨大。如果直接在原表中建立一個十列信息的聯合索引，則會占用12G左右的空間。如果將工廠和庫房的數據分開，則需要停線。經過綜合分析考慮，將此表中車間數據放到一張單獨的表中，并在上面建立全部數據的Index。

更改后，再次分析Trace中的執行計劃，得到total數據為：disk （0）、query（1757）、current（0）、rows（1784）從磁盤上的數據文件中物理讀取的塊的數量由51 163個降低為0個，平均讀取每行需要的Block數也降低到1塊，實際執行時間也由將查詢速度由原來首次執行的2分32秒減少到781毫秒。

4　批處理操作——異步替代同步

發貨在FGMS中一直是比較慢的操作，由于需要處理的數據比較多，處理速度一直很慢。SQL已經是最優，應用處理方式由API改為存儲過程，更新方式也改為最快的BULK處理方式，但是在遇到數據量大的發貨單，仍然需要很長時間。發貨數量超過30W的發貨單，由于處理時間超過TimeOut（20分鐘）的時間，應用直接報錯。每到月底發貨量大的時候，用戶體驗更差。在AWR的TOP SQL中，此業務在15分鐘內執行11次，平均時間約81 s，占整個DB Time的5.43%。

此存儲過程里設計的查詢語句及更新方式都是最佳方式，業務的邏輯處理方式也經過了很多次的優化。除了提高硬件性能外，如果保持現有邏輯已經沒有其他提高處理速度的方法。發貨時，用戶只關注發貨單及Pallet的信息變化情況，不會觀察Panel的信息情況，故采用了異步處理的方式，先更新Pallet數據及發貨單信息并將結果反饋給用戶，在用另一個進程更新Panel信息。

此方法只適用于對部分數據更新實時性要求不高、且異步執行部分都保證更新成功的情況，否則會造成數據不一致，影響后續業務的處理。

5　結 語

一個系統要穩定地、高效地運行，離不開持之以恒的系統調優。調優的方法中SQL優化是最直接、最方便，見效最顯著的，但并非所有的問題都是能通過SQL調優來解決的。當SQL已經沒有優化空間時，不妨對業務邏輯或者業務數據進行變動，來達到系統優化的目的。從傳統的“供給”改為“供需”，節約資源，降低投入。

主要參考文獻

［1］陳冠星.企業應用開發中Oracle的SQL優化［J］.軟件導刊，2014（12）.

［2］羅時飛.精通Spring——深入Java EE開發核心技術［M］.北京：電子工業出版社，2008.

［3］陳雍，謝旭升，魏根芽.Oracle B*樹索引內部機制及其應用的研究［J］.計算機與現代化，2008（10）.

［4］譚懷遠.讓Oracle跑得更快——Oracle 10g性能分析與優化思路［M］.北京：電子工業出版社，2010.

10.3969/j.issn.1673 - 0194.2016.16.039

TP311.52

A

1673-0194（2016）16-0059-02

2016-07-08