library cache
我上圖中，oracle去5號鏈上遍歷，會把5號鏈鎖住（Library Cache Latch），這樣的話如果咱們吧shared_pool設的很大，library cache中緩存的sql/執行計劃就會很多，鏈就會很長，那麼遍歷的時間就長，鎖住鏈的時間就會很長。
來~~~咱們捋一下sql執行的過程：
說明：我們說的鏈也可叫bucket
⑴ 一個sql來了，然後oracle一頓內部計算，得到了一個hash_value,然後根據這個值得出到parent cursor的位置（比如就是我上圖的5號鏈/bucket）然後獲得Library Cache Latch把這個鏈給鎖住，根據SQL的HASH_VALUE值遍歷child cursor，如果找到則爲軟解析，Server process獲得該SQL執行計劃，轉向第⑷步；如果找不到則執行硬解析，在硬解析的整個過程中，一直持有這個Library Cache Latch鎖住對應鏈。
⑵ 硬解析完成後釋放Library Cache Latch，獲得Shared Pool Latch，查找並鎖定整個free空間，然後找對應大小的chunk鏈（也叫bucket）找一個可用的chunk，把sql和執行計劃寫入到對應的chunk中去。
⑶ 釋放Shared Pool Latch，重新獲得Library Cache Lacth，將這個寫了sql和計劃的chunk插入到對應鏈（5號鏈）中。
⑷ 釋放Library Cache Latch，保持Null模式的Library Cache Pin/Lock。
⑸ 開始執行。
當數據庫中出現大量硬解析的時候，某一個sql無法得到library cache latch就會開始spin（自旋）,達到spin count後還沒得到，就會開始sleep,達到sleep時間後,醒來還再次試圖過的library cache latch得不到就再spin再得不到又sleep…依此類推
這樣就會造成鎖的爭用，導致出現latch free等待事件
所以說出現LATCH爭用的問題，想用加大shared pool的大小來解決是非常錯誤的~！！這樣不僅不能解決問題，還可能會是問題更加嚴重，因爲你這樣不僅沒有解決硬解析的問題，反而還會使遍歷library cache鏈的時間變得更長。。。
解決LATCH爭用的正確方法是減少sql的硬解析，而不是加大shared pool~！！！
參考：http://oracle.chinaitlab.com/exploiture/814152.html 、 http://www.xifenfei.com/3151.html