OracleORA-4031錯(cuò)誤原因解
Oracle ORA-4031錯(cuò)誤產(chǎn)生的原因
首先這個(gè)錯(cuò)誤發(fā)生時(shí)的表現(xiàn)如下:
ORA-04031: unable to allocate XXXX bytes of shared memory
(“shared pool,“unknown object”,”sga heap(1,0)”,”obj stat memor“)
就是最基本的查詢簡單的動(dòng)態(tài)性能視圖都無法完成:
下面來細(xì)細(xì)的分析一下原因:
這就需要從shared pool 的內(nèi)存結(jié)構(gòu)來分析了, 首先shared pool 有許多的內(nèi)存塊組成,這些內(nèi)存塊通常叫做chunk
chunk是 shared pool這是內(nèi)存分配的最小單位,其中的內(nèi)存都是連續(xù)的。
chunk 分為四個(gè)類型,可以從 X$ksmsp中的 ksmchcls列看到 ,X$ksmsp視圖中的每條記錄都表示在當(dāng)前shared pool 中的一個(gè)chunk
1) free 這種類型的chunk不包含有有效的對(duì)象,可以被分配。
2) recr 表示recreatable,這種類型的chunk 里面包含的對(duì)象可以在需要的時(shí)候被臨時(shí)移走,并且在需要的時(shí)重新創(chuàng)建。
比如對(duì)于很多的共享SQL的chunk就是recreatable的。
3) freeabl 這種類型的chunk 包含的對(duì)象是曾經(jīng)被session 使用過的。并且隨后會(huì)被完全或者部分釋放。這種chunk
不能被臨時(shí)從內(nèi)存中移走,因?yàn)樗麄兪窃谔幚磉^程中產(chǎn)生的,如果移走就不能被重建。
4) perm 意味著永久性,這種類型的chunk包含永久的對(duì)象,大型的permanent類型的chunk也可能包含有用的空間,
這部分可用空間可以在需要的時(shí)候釋放。
在shared pool 中可用的chunk(也就是free類型的)會(huì)被連接起來成為 free list 或者叫bucket(一個(gè)free list就是一個(gè)bucket)
每個(gè)backet中的chunk的大小是不同的。
當(dāng)某個(gè)進(jìn)程需要shared pool 里面的一個(gè)chunk,該進(jìn)程首先倒伏后所需空間大小的backet上去掃描,以找到最合適的chunk,掃描持續(xù)到backet
的最末端,值到找到尺寸符合的chunk為止,如果找到的chunk尺寸必須要的要大,則這個(gè)被找到的chunk就會(huì)被拆分一個(gè)用來存儲(chǔ)數(shù)據(jù)
另一個(gè)成為free類型的chunk 并成為當(dāng)前的bucket。
當(dāng)某個(gè)bucket不包含有任何尺寸的chunk,那么就從下一個(gè)非空的backet上獲得一個(gè)最小的chunk,如果在剩下的所有的backet中都找不到可用的chunk
則需要掃描已經(jīng)使用的recreatable類型的chunk。從該鏈表上釋放出部分chunk,因?yàn)橹挥衦ecreatable類型的chunk才是可以被臨時(shí)一處內(nèi)存的。
但某個(gè)chunk正在被使用時(shí)該chunk是不能被移除內(nèi)存的。比如某個(gè)SQL語句正在執(zhí)行,那么該語句所使用的chunk就不能被移除內(nèi)存。該SQL所引用的表,索引
等對(duì)象占用的chunk也不能夠被移除內(nèi)存,當(dāng)shared pool中無法找到滿足大小的所需內(nèi)存時(shí)就會(huì)出現(xiàn)ORA-4031的錯(cuò)誤。
當(dāng)出現(xiàn)ORA-4031的錯(cuò)誤的時(shí)候,我們查詢V$SGSTAT中的可用shared pool空間時(shí),可能發(fā)現(xiàn)可用的內(nèi)存足夠大了,為什么還是出現(xiàn)ORA-4031錯(cuò)誤呢?
事實(shí)上,在oracle發(fā)出錯(cuò)誤之前已經(jīng)釋放出大量的recreatable類型的chunk了因此會(huì)產(chǎn)生不少的可用內(nèi)存。但是這些可用的chunk中沒有一個(gè)是連續(xù)的從而
才發(fā)出ORA-4031的錯(cuò)誤。