某次資料庫效能監控中發現的問題

1.        總體執行情況

促銷活動期間，資料 庫主要業務落在節點1上，總體執行相對穩定，伺服器記憶體資源充足，節點1隨併發數增高持續有大約20分鐘出現CPU資源使用高峰問題，高峰期CPU使用峰值達97%，使用均值78.5%，此期間，出現大量行鎖等待以及資源管理排程引起CPU等待。

 

2.        現象及問題分析

1)        索引爭用等待和熱塊爭用等待

l  enq: TX - index contention和buffer busy waits::業務高峰期，對MSTB_ORDER_HEADER做INSERT及UPDATE時發生大量索引塊更新爭用等待和大量熱塊爭用等待，導致該事件是因為初步查詢了MSTB_ORDER_HEADER表的索引情況，發現建立了許多索引。建議：1）簡化索引，去掉不必要的重複索引。2）重建索引到不同的表空間下。3）部分索引是否可重建成反向索引。4）從業務上是否可減少插入或更新的次數？5）該表是否建立分割槽？

l  引起該等待事件SQL_ID為98jwpq3r5z47u和98jwpq3r5z47u等。

2)        資源管理計劃CPU等待

l  resmgr:cpu quantum:業務高峰期間，出現大量resmgr:cpu quantum等待事件的SQL，並且消耗了50%以上CPU, resmgr:cpu quantum等待事件是因為資源管理計劃的時間視窗被啟用才發生該事件。確認是否人為定義了資源管理計劃的時間視窗。亦可能ORACLE是預設開啟各種自動作業，因為而產生了該類等待事件。

l  建議：1）禁用資源管理、禁用預設的維護計劃，關閉一些不需要的維護任務（禁用資源管理計劃可能引起部分自動JOB無法使用），2）打上資源管理器相應的補丁。

l  引起該等待事件的SQL_ID為fm84pykjjn398、dnmf3y0hmtdcu和6zr00uskqa6d2等select語句。

 

3)        SQL問題

個別SQL語句消耗較多資源,其中fm84pykjjn398與cwzu5v87fhcpg、2u973xwdjwc16等進行配售業務的SQL基本相同，都是對MSTB_Quota及MSTB_Header進行關聯查詢，希望開發商儘量優化程式碼，避免同樣的sql在資料庫中進行多次硬解析。同時還發現fm84pykjjn398出現了多個執行計劃，且其消耗相差較大，建議檢視統計資訊情況，必要的話進行固定執行計劃。

 建議對7anrtd1pvz87y（AEC業務）看看是否可以進一步優化，調整相應的索引！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29863023/viewspace-1708150/，如需轉載，請註明出處，否則將追究法律責任。