Oracle一些引數的理解 cursor_sharing

引數session_cached_cursors解釋
------------------------------------------------
自己一直感覺對oracle的記憶體這一塊兒理解不夠深刻。
今天看到關於session_cached_cursors引數的解釋。翻譯一下。同時也加入一點自己的理解
oracle有一個概念，那就是session cursor cache,中文描述就是有一塊記憶體區域，用來儲存關閉了的cursor。當一個cursor關閉之後，oracle會檢查這個cursor的request次數是否超過3次，如果超過了三次，就會放入session cursor cache，這樣在下次parse的時候，就可以從session cursor cache中找到這個statement->Alan：其實這裡就是把cursor快取在了PGA裡面(private sql area)。session cursor cache的管理也是使用LRU。session_cached_cursors這個引數是控制session cursor cache的大小的。session_cached_cursors定義了session cursor cache中儲存的cursor的個數。這個值越大，則會消耗的記憶體越多
另外檢查這個引數是否設定的合理，可以從兩個statistic來檢查
session cursor cache hits 和parse count（total）就是總的parse次數中，在session cursor cache中找到的次數，所佔比例越高，效能越好。如果比例比較低，並且有剩餘記憶體的話，可以考慮加大該引數。

引數shared_pool_reserved_size的解釋
--------------------------------------------------------
這個引數設定的目的是為了保證大物件在記憶體中的裝載.Alan：因為shared_pool中的chunk都是以4k為基準的，使用於小的記憶體塊，同時也是基於LRU的管理
對於shared pool，oracle是以chunk的方式來分配記憶體的。當請求一個大記憶體的時候，oracle可以將這個請求分成幾個小的chunk，來裝載這個大物件。但是還是有一些記憶體請求操作，比如編譯plsql 過程或者函式的時候，需要大的記憶體，但是這時候shared pool中沒有了空閒的記憶體可以使用，這時候就會使用shared_pool_reserved_size
當有大物件需要裝載到記憶體時，oracle查詢位置的方式是首先在unreserved shared pool中查詢，如果有記憶體可以使用，就在unreserved pool中分配，如果unreserved 中沒有足夠的記憶體，就是使用reserved shared pool來裝載這個大物件。
當unreserved shared pool和reserved shared pool都不能滿足的時候，oracle就會free 記憶體，就是釋放記憶體，在釋放記憶體後，oracle再按照上面的順序區查詢。
一般情況下，shared_pool_reserved_size是不需要調整的。尤其是現在記憶體配置如此高的情況下，只要合理的配置shared_pool_size就可以了

有一個檢視v$shared_pool_reserved是一個紀錄請求reserved shared pool的檢視，shared pool調優，目標是調整到這個檢視中的request_misses為零，如果這個做不到的話，是要儘量避免request_failures的值持續增大的

引數cursor_sharing的解釋
--------------------------------------
這個引數的設定，oracle是為了滿足一些以前開發的程式，裡面有大量的similar statement，但是重寫有不現實的情況下使用的一個引數。
並且oracle也不建議使用這個引數。

什麼時候需要修改這個引數呢？需要滿足以下的條件。
一個是由於大量的shared pool hit miss影響了使用者的響應時間（就是當前的shared pool無法滿足共享sql語句儲存的需要,Alan:當前libary cache中沒有我們所需要重用的explain和sql），如果沒有這個問題，那麼設定這個引數，可能會造成更糟糕的效能。這個引數只會減少parse的時間。
另外一個就是在現有程式中有大量的similar statement，可以通過設定這個引數來獲得比較好的效能。
cursor_sharing這個引數有三個值可選，exact、similar、force。當值為exact時為預設值，也是oracle的預設處理方式。就是當一個statement parse的時候，首先到shared pool區檢視是否有exact statement存在（就是看是否在shared pool中有和當前要解析的statement完全一樣的語句存在），如果不存在，就執行hard parse
如果該引數設定為similar，那麼如果在shared pool中無法找到exact statement的存在的時候，就會在shared pool進行一次新的查詢，就是查詢和當前要解析的語句是否是similar statement的語句。這裡需要對similar statement進行解釋，similar statement就是除了value of some literal不同的語句，別的地方都相同的語句。比如下面：

select * from a where a=1;
select * from a where a=2;

當cursor_sharing設定為similar時，如果在shared pool中查詢到這樣的語句，就會做下一步的檢查，看shared pool中快取的這個語句的execution plan是否適合當前解析的語句，如果適合，就會使用shared pool的語句，而不去做hard parse。如果cursor_sharing設定為force的時候，當在shared pool中發現了similar statement之後，就不會再去檢查執行計劃了，而直接使用在shared pool的這個語句了。
將cursor_sharing設定為force實際上是危險的。這會可能形成suboptimal的執行計劃。比如對於一個範圍查詢的語句，比如
select * from a where a>10 and a<20這樣型別的語句，快取中的語句的執行計劃可能對於正在解析的語句就是不適合的，不是最優的執行計劃。
這樣看起來是減少了parse惡的時間，但是大大增大了execution的時間。

對於新開發的application，最後是不要設定這個引數，而是針對可以共享的語句使用幫定變數，而對於不適合共享的語句，就不使用幫定變數。將cursor_sharing保持預設值，也就是exact。

調整cursor_sharing的關鍵一定是要看調整cursor_sharing的條件是否存在。
就是是否有比較大的shared pool hitmis，如果這個條件沒有，那就沒有必要調整這個引數。cursor_sharing的目的是減少parse time，但是在整個db time中，可能parse time只佔很小的一部分。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/730796/viewspace-607395/，如需轉載，請註明出處，否則將追究法律責任。