問題一：哪個進程負責硬解析？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：執行次數]