某客戶的操作人員反應很慢不能操作，管理人員登入小機系統後發現cpu使用到了95%以上。而且這種情況持續了幾個月。小機是ibm的p520,配置是2顆4核的cpu,記憶體是48g,oracle是10.2.0.5。topas與生成的awr報告如下:
從上面的load profile部分可以看到每秒執行的sql與事務數并不高，因為是周末并沒有太多人使用系統。
從上面的top 等待事件來看主要是cpu time。檢視這個時間段生成的addm報告:
從上面的資訊addm報告與top sql部分可以看到在快照26245到26246之間database time為16644秒。而找到的一條sql消耗了76%的cpu時間。如果對這兩條sql執行優化應該可以将cpu消耗顯著降低。而該sql雖然每執行一次的時間是0.93秒，消耗的cpu時間隻有0.76秒，但在周末的時間内一個小時都執行了16,029次，消耗的cpu時間是12249秒而且小機的cpu數量隻有2顆(6核)，那麼每秒該sql的執行次數就是=16029/3600=4.5次，是以大部分的cpu被該sql所消耗了。這還是周末，如果上班時間該sql執行的次數會以倍數增加，那麼cpu的消耗就會更高。
sql語句如下:
其執行計劃如下:
從執行計劃來看該sql的cost也不高(執行時間是0.93秒，cpu時間是0.76秒)，從sql的執行計劃來看見兩個表是使用的嵌套循環，而驅動表t_lk_email_emailgroup的資料量是1w多行，t_lk_email_detail表的數量是20w行左右。而表t_lk_email_emailgroup執行全表掃描後滿足查詢條件的記錄有4條，是以就得對表t_lk_email_detail中的記錄周遊4次來找到與驅動表相比對的記錄,雖然每次執行時間不長，但是在并發執行次數高，而實體cpu數量不足的情況下還是會引發性能問題。而這兩個表有等值連接配接條件f_email_group_id，而且在驅動表中f_email_group_id列建立了索引，是以這裡選擇在表t_lk_email_detail表的f_email_group_id列上建立索引之後執行計劃如下所示:
sql執行計劃的cost顯示增加了，但sql執行時間隻有0.1s提高了10倍。在對該sql優化之後，業務系統恢複正常，cpu使用率也維持在20%左右。
是以在優化時，不能簡單的根據sql執行時間來判斷該sql是否會引發性能問題，要具體問題具體分析。