問題一:哪個進程負責硬解析?shared pool設定不合理除了命中率低外還有哪些現象?
說到軟解析(soft prase)和硬解析(hard prase),就不能不說一下Oracle對sql的處理過程。當你發出一條sql語句交付Oracle,在執行和擷取結果前,Oracle對此sql將進行幾個步驟的處理過程:
1、語法檢查(syntax check)
檢查此sql的拼字是否文法。
2、語義檢查(semantic check)
諸如檢查sql語句中的訪問對象是否存在及該使用者是否具備相應的許可權。
3、對sql語句進行解析(prase)
利用內部演算法對sql進行解析,產生解析樹(parse tree)及執行計畫(execution plan)。
4、執行sql,返回結果(execute and return)
其中,軟、硬解析就發生在第三個過程裡。
Oracle利用內部的hash演算法來取得該sql的hash值,然後在library cache裡尋找是否存在該hash值;
假設存在,則將此sql與cache中的進行比較;
假設“相同”,就將利用已有的解析樹與執行計畫,而省略了最佳化器的相關工作。這也就是軟解析的過程。
誠然,如果上面的2個假設中任有一個不成立,那麼最佳化器都將進行建立解析樹、產生執行計畫的動作。這個過程就叫硬解析。
建立解析樹、產生執行計畫對於sql的執行來說是開銷昂貴的動作,所以,應當極力避免硬解析,盡量使用軟解析。
這就是在很多項目中,倡導開發設計人員對功能相同的代碼要努力保持代碼的一致性,以及要在程式中多使用綁定變數的原因。
/****************************************************/
問題二、大家都在說在Sql中使用了Bind Var(綁定變數)會提高不少效能,那他到底是如何提高效能的呢?
使用了Bind Var能提高效能主要是因為這樣做可以盡量避免不必要的硬分析(Hard Parse)而節約了時間,同時節約了大量的CPU資源。
當一個Client提交一條Sql給Oracle後,Oracle 首先會對其進行解析(Parse),然後將解析結果提交給最佳化器(Optimiser)來進行最佳化而取得Oracle認為的最優的Query Plan,然後再按照這個最優的Plan來執行這個Sql語句(當然在這之中如果只需要軟解析的話會少部分步驟)。
但是,當Oracle接到 Client提交的Sql後會首先在共用池(Shared Pool)裡面去尋找是否有之前已經解析好的與剛接到的這一個Sql完全相同的Sql(注意這裡說的是完全相同,既要求語句上的字元層級的完全相同,又要求涉及的對象也必須完全相同)。當發現有相同的以後解析器就不再對新的Sql在此解析而直接用之前解析好的結果了。這裡就節約瞭解析時間以及解析時候消耗的CPU資源。尤其是在OLTP中運行著的大量的短小Sql,效果就會比較明顯了。因為一條兩條Sql的時間可能不會有多少感覺,但是當量大了以後就會有比較明顯的感覺了。
上面說到了硬解析(Hard Parse),那這個Hard Parse到底是個啥呢?
Parse主要分為三種:
1、Hard Parse (硬解析)
2、Soft Parse (軟解析)
3、Soft Soft Parse(好像有些資料中並沒有將這個算在其中)
Hard Parse就是上面提到的對提交的Sql完全重新從頭進行解析(當在Shared Pool中找不到時候將會進行此操作),總共有一下5個執行步驟:
1:文法分析
2:許可權與對象檢查
3:在共用池中檢查是否有完全相同的之前完全解析好的—如果存在,直接跳過4和5,運行Sql(此時算soft parse)
4:選擇執行計畫
5:產生執行計畫
Soft Parse就如果是在Shared Pool中找到了與之完全相同的Sql解析好的結果後會跳過Hard Parse中的後面的兩個步驟。
Soft Soft Parse實際上是當設定了session_cursor_cache這個參數之後,Cursor被直接Cache在當前Session的PGA中的,在解析的時候只需要對其文法分析、權限物件分析之後就可以轉到PGA中尋找了,如果發現完全相同的Cursor,就可以直接去取結果了,也就就是實現了 Soft Soft Parse.
不過在計算解析次數的時候是只計算Hard Parse和Soft Parse的(其實Soft Soft Parse好像也並不能算是做了Parse ):Soft Parse百分比計算:Round(100*(1-:hprs/:prse),2) [hprs:硬解析次數;prse:解析次數] Parse比率計算: Round(100*(1-prse/exec) ,2) [exec:執行次數]