通過top命令抓取cpu高消耗的sql

pid是3585的程式對應的sql 之前已經確定是效能問題導致的了，所以先放過，可以看看pid是8879的這個程式，出現的不是很“穩定”。
可能通過ash,awr不一定能夠及時的抓住這些資訊，但是通過及時的分析，可能有時候會得到一想不到的收穫。
可以通過v$session,v$process,v$sql來結合查詢process對應的sql.
可以看到這個程式是屬於一個遠端的session(LOCAL=NO),是通過一個batch的伺服器上發起的請求。
執行的sql很簡單。就是一個簡單的查詢。初步懷疑就是因為查詢走了全表掃描而且那個欄位可能沒有索引。

為了確認，檢視錶的結構來看看。可以結合user_tab_cols,user_ind_columns來檢視錶的屬性和索引的資訊。這些都是用準備好的指令碼來生成的，過濾了一些不必要的資訊。
可以看到,索引是存在的，在ext_account_number上，而且是唯一性索引。如果那樣的話走全表掃描就有些不合常理了。

如果觀察的再仔細些，可以看到ext_account_number那個欄位是varchar2(12)的。
為了驗證表肯定走了全表掃描，我抓了一個awrsqrpt的報告。內容如下，可以看到的確走了全表掃描。而且buffer gets還挺大，cpu消耗比較高。

到此為止，如果還不沒明白的話，我做個簡單的測試。

我從表裡隨機抓取10條記錄。
SQL> SELECT balance ,EXT_ACCOUNT_NUMBER from ACCOUNT WHERE rownum<=10;   
                                                                         
BALANCE EXT_ACCOUNT_NUMBER
---------- ------------                                                  
         0 10257832                                                      
    772.81 10260829                                                      
    584.22 10259790                                                      
    329.03 10258781                                                      
      -.39 10263317                                                      
      -.14 10260830                                                      
    496.79 10258782                                                      
         0 10258783                                                      
      -.83 10258785                                                      
      -.91 10259791                                                      
                                                                         
10 rows selected.                                                        

這樣問題的根源就很清晰了。再換一個,試試走索引的情況。可以看到，效率有了極大的提升。剩下的問題就是協調來解決了。