通過top命令抓取cpu高消耗的sql (44天)
top命令在linux環境維護中很實用,雖然功能缺失不夠sar那麼全面。今天和大家分享一個通過top命令來抓取效能sql的案例。 通過top命令抓取了如下的資訊。
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.
然後來trace一把。看看執行的情況。 可以看到,確實走了全表掃描,沒有走索引。可以看到filter部分,對於ext_account_number它是在解析的時候做了型別轉換的,從varchar2轉為number。 一致性讀有12704.
這樣問題的根源就很清晰了。再換一個,試試走索引的情況。可以看到,效率有了極大的提升。剩下的問題就是協調來解決了。