? Buffer cache 和 share pool 是sga中最重要最復(fù)雜的部分。

?

一.Buffer Cache

? ? 通常數(shù)據(jù)的讀取、修改都是通過buffer cache 來完成的。buffer cache 中的數(shù)據(jù) ，oracle是通過LRU 和dirty list 這樣的鏈表來管理的。

除了這2個(gè)，還有 hash bucket 和 cache buffer chain

?hash bucket：查找方法類似老式圖書館查書

?

二.Shared Pool

? ? ?1.shared pool 是oracle sga中重要的一部分，它主要作用是 sql共享、減少代碼硬解析等

? ? ? ? shared_pool_size設(shè)置：oracle9以后，設(shè)置成200-300M是比較合適的

?

? ? ?2.ora-04031問題

? ? ? ? 當(dāng)嘗試在共享內(nèi)存分配大的連續(xù)內(nèi)存失敗后，oracle會清空沒用的對象，嘗試合并內(nèi)存；如果仍然沒有足夠大的內(nèi)存空間，就提供ora-04031.

? ? ? ? 如果shared_pool_size 設(shè)置的夠大，也不存在系統(tǒng)bug；那么大部分引起該問題的原因：共享池中大量的sql引起過多的內(nèi)存碎片導(dǎo)致

? ? ? ? 1）sql沒有足夠的共享空間

? ? ? ? 2）大量不必要的解析

? ? ? ? 3）sql沒有使用綁定變量

? ? ? ??

? ? ? ? 另外，雖然可以通過強(qiáng)制刷新系統(tǒng)共享內(nèi)存以達(dá)到共享內(nèi)存碎片合并目的，但該操作是不推薦的。

? ? ? ? alter system flush shared_pool。

?

? ? ? ? 實(shí)際上，share pool的調(diào)整根本是從應(yīng)用入手，應(yīng)用代碼的編寫、調(diào)整才是根本。

?

? ? ?3.Version_count 過高的現(xiàn)象：

? ? ? ? ? ? ? 應(yīng)用系統(tǒng)一段時(shí)間運(yùn)行緩慢，一時(shí)正常。查看了$session_wait 發(fā)現(xiàn) latch free 比較多。

? ? ? ?通過 v$latch 表查看到 shared pool 和 liberary cache 比較大。

? ? ? ?通過v$sqlarea 查看到 version_count>1000 的有幾個(gè)。

? ? ? ?問題解決：1）調(diào)整timed_statistics=true 為false

? ? ? ? ? ? ? ? ? ? ? ? ? ? -----該參數(shù)是系統(tǒng)對? 比如sql解析、執(zhí)行、等待等等分別消耗了多少時(shí)間進(jìn)行統(tǒng)計(jì)

? ? ? ? ? ? ? ? ? ? ? 2）調(diào)整cursor_sharing=similar ?為 force--強(qiáng)制匹配 或者 exact--精確匹配（缺省值） ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? -----該參數(shù)是sql強(qiáng)制變量綁定

? ? ? ??

? ? ? ? ? ? ? ? 另外：說明一下cursor_sharing

? ? ? ? ? ? ? ? ? ? ? ?根據(jù)oracle官方建議在11g中不推薦使用cursor_sharing=SIMILAR,其實(shí)在所有版本中都不推薦,設(shè)置為該值很容易導(dǎo)致高版本問題.

? ? ? ? ? ? 而且該值會出現(xiàn)莫名其妙的,無法解釋的高版本問題.而且根據(jù)oracle相關(guān)文檔,在即將發(fā)布的12c版本中,將除掉SIMILAR值.

? ? ? ? ? ? 對于客戶庫的該問題,因?yàn)楹芏鄐ql未綁定參數(shù),為了減少硬解析, 建議在業(yè)務(wù)低谷時(shí)設(shè)置cursor_sharing=FORCE,并刷新shared pool.

? ? ?

深入淺出Oracle學(xué)習(xí)筆記：Buffer Cache 和Shared pool