oracle ?ORA-4031錯誤產(chǎn)生的原因

首先這個錯誤發(fā)生時的表現(xiàn)如下：

ORA-04031: unable to allocate XXXX bytes of shared memory

(“shared pool，“unknown object”，”sga heap(1，0)”，”obj stat memor“)

就是最基本的查詢簡單的動態(tài)性能視圖都無法完成：

下面來細細的分析一下原因：

這就需要從shared pool 的內(nèi)存結(jié)構(gòu)來分析了， 首先shared pool 有許多的內(nèi)存塊組成，這些內(nèi)存塊通常叫做chunk

chunk是 shared pool這是內(nèi)存分配的最小單位，其中的內(nèi)存都是連續(xù)的。

chunk 分為四個類型，可以從 X$ksmsp中的 ksmchcls列看到 ，X$ksmsp視圖中的每條記錄都表示在當(dāng)前shared pool 中的一個chunk

1) free 這種類型的chunk不包含有有效的對象，可以被分配。

2) ?recr 表示recreatable，這種類型的chunk 里面包含的對象可以在需要的時候被臨時移走，并且在需要的時重新創(chuàng)建。

比如對于很多的共享SQL的chunk就是recreatable的。

3) freeabl 這種類型的chunk 包含的對象是曾經(jīng)被session 使用過的。并且隨后會被完全或者部分釋放。這種chunk

不能被臨時從內(nèi)存中移走，因為他們是在處理過程中產(chǎn)生的，如果移走就不能被重建。

4) perm 意味著永久性，這種類型的chunk包含永久的對象，大型的permanent類型的chunk也可能包含有用的空間，

這部分可用空間可以在需要的時候釋放。

在shared pool 中可用的chunk(也就是free類型的)會被連接起來成為 free list 或者叫bucket(一個free list就是一個bucket)

每個backet中的chunk的大小是不同的。

當(dāng)某個進程需要shared pool 里面的一個chunk，該進程首先倒伏后所需空間大小的backet上去掃描，以找到最合適的chunk，掃描持續(xù)到backet

的最末端，值到找到尺寸符合的chunk為止，如果找到的chunk尺寸必須要的要大，則這個被找到的chunk就會被拆分一個用來存儲數(shù)據(jù)

另一個成為free類型的chunk 并成為當(dāng)前的bucket。

當(dāng)某個bucket不包含有任何尺寸的chunk，那么就從下一個非空的backet上獲得一個最小的chunk，如果在剩下的所有的backet中都找不到可用的chunk

則需要掃描已經(jīng)使用的recreatable類型的chunk。從該鏈表上釋放出部分chunk，因為只有recreatable類型的chunk才是可以被臨時一處內(nèi)存的。

但某個chunk正在被使用時該chunk是不能被移除內(nèi)存的。比如某個SQL語句正在執(zhí)行，那么該語句所使用的chunk就不能被移除內(nèi)存。該SQL所引用的表，索引

等對象占用的chunk也不能夠被移除內(nèi)存，當(dāng)shared pool中無法找到滿足大小的所需內(nèi)存時就會出現(xiàn)ORA-4031的錯誤。

當(dāng)出現(xiàn)ORA-4031的錯誤的時候，我們查詢V$SGSTAT中的可用shared pool空間時，可能發(fā)現(xiàn)可用的內(nèi)存足夠大了，為什么還是出現(xiàn)ORA-4031錯誤呢？

事實上，在oracle發(fā)出錯誤之前已經(jīng)釋放出大量的recreatable類型的chunk了因此會產(chǎn)生不少的可用內(nèi)存。但是這些可用的chunk中沒有一個是連續(xù)的從而

才發(fā)出ORA-4031的錯誤。

?著作權(quán)歸作者所有：來自51CTO博客作者andylhz的原創(chuàng)作品，如需轉(zhuǎn)載，請注明出處，否則將追究法律責(zé)任

ORACLE內(nèi)存休閑Oracle數(shù)據(jù)庫

總結(jié)

以上是生活随笔為你收集整理的oracle sga 4031,Oracle ORA-4031错误产生的原因详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。