一個新上線資料庫的調優記錄

背景說明：一個供應鏈協同系統上線後的幾天後，陸陸續續有使用者反饋系統有些慢，這個時候專案的老大第一反映就是讓DBA看下系統的瓶頸。一般情況系統上線前期都會有壓力測試，但是壓力測試並不能模擬出複雜的業務場景，經過了壓力測試也並不代表在實際的執行中不會出現問題。

順便跑題一下：系統上線前期如果系統有問題，那麼正是DBA大展身手的機會，因為只有DBA才知道系統"為什麼慢、慢在哪裡、怎麼調",這個時候你的價值就體現出來了，如果碰到一個不厚道的領導，還可以忽悠他一下，因為我遇到的領導很不錯，所以我也是兢兢業業的。

 

以下是整個問題的解決過程：

1、當使用者反饋很卡的時候，進入檢查三部曲：cpu、記憶體、歸檔空間、鎖等待資訊，經過一番檢查發現資料庫的整體壓力並不高，也沒有發現鎖等待資訊；

2、檢視資料庫的awr報告，自從稍微看懂了awr報告後，為整個資料庫的管理增加了不少便利。

 

2.1 以下是問題時間段的awr報告截圖：

在top5的等待事件中發現了cursor：pin S wait on X的等待事件，這個等待事件跟資料庫Library有關係，根據經驗這個等待事件一般跟以下幾個有關係：

• sga自動管理,sga的頻繁擴充套件和收縮；
• 過渡硬解析,造成library cache中的cursor object被頻繁的reload；
• bug；

2.2 針對這個記憶體的問題，檢查awr報告的記憶體大小，buffer cache和shared pool並未發生變化，所以可以排除sga的擴充套件和收縮導致的問題；

 

2.3 檢查資料庫的硬解析情況  

Time Model Statistics DB/Inst: SCMPRD/scmprd Snaps: 2045-2046

-> Total time in database user-calls (DB Time): 1576.1s

-> Statistics including the word "background" measure background process

time, and so do not contribute to the DB time statistic

-> Ordered by % or DB time desc, Statistic name

   

Statistic Name Time (s) % of DB Time

------------------------------------------ ------------------ ------------

DB CPU 1,426.7 90.5

sql execute elapsed time 1,404.8 89.1

parse time elapsed 717.7 45.5

hard parse elapsed time 645.2 40.9

hard parse (sharing criteria) elapsed time 480.5 30.5

PL/SQL execution elapsed time 52.8 3.3

sequence load elapsed time 2.3 .1

hard parse (bind mismatch) elapsed time 1.3 .1

connection management call elapsed time 0.8 .0

PL/SQL compilation elapsed time 0.1 .0

repeated bind elapsed time 0.1 .0

failed parse elapsed time 0.0 .0

DB time 1,576.1

background elapsed time 106.2

background cpu time 86.9

從上面的時間統計看出，資料庫的硬解析佔用了很大的一個佔比，一般來說資料庫硬解析產生的原因是由於未使用繫結變數導致的。（http://blog.itpub.net/12679300/viewspace-1217976/）

 

2.4 為了保險起見繼續看AWR報告的其他部分

既然硬解析是由於SQL語句引起的，所以就很有必要看下這段時間裡執行次數最多的語句，並針對這些語句和業務人員溝通；

 

2.5 解決方法，經過以上的分析，以短時間內保障系統的效能為目的，做了以下調整；

• 查詢資料庫top5的未使用繫結變數的語句，進行調優；
• 修改資料庫的引數CURSOR_SHARING設定為SIMILAR；
• 一些後臺會產生大量併發SQL語句的JOB轉移到系統空閒期執行；

新系統上線前期一般會有一些的效能上的問題，但是這些問題往往並不是DBA調整幾個引數就能解決的，見過好幾個自開發的系統，應用層面都沒有使用繫結變數的習慣，雖然可以透過CURSOR_SHARING引數暫時解決問題；便捷和穩定總是衝突的，雖然這樣可以暫時的解決問題，但是從長期系統的穩定性來說還是有一定的風險的。

*********************************************************************************************************************

本文作者：JOHN QQ：1916066696 （請備註資料庫）

ORACLE技術部落格：ORACLE 獵人筆記 http://blog.itpub.net/12679300/

******************************************************************************************************