首先這個錯誤發生時的表現如下：
ORA-04031: unable to allocate XXXX bytes of shared memory
（“shared pool，“unknown object”，”sga heap（1，0）”，”obj stat memor“）
就是最基本的查詢簡單的動態性能視圖都無法完成：
下面來細細的分析一下原因：
這就需要從shared pool 的內存結構來分析了， 首先shared pool 有許多的內存塊組成，這些內存塊通常叫做chunk
chunk是 shared pool這是內存分配的最小單位，其中的內存都是連續的。
chunk 分爲四個類型，可以從 X$ksmsp中的 ksmchcls列看到 ，X$ksmsp視圖中的每條記錄都表示在當前shared pool 中的一個chunk
1） free 這種類型的chunk不包含有有效的對象，可以被分配。
2) recr 表示recreatable，這種類型的chunk 裏面包含的對象可以在需要的時候被臨時移走，並且在需要的時重新創建。
比如對於很多的共享SQL的chunk就是recreatable的。
3） freeabl 這種類型的chunk 包含的對象是曾經被session 使用過的。並且隨後會被完全或者部分釋放。這種chunk
不能被臨時從內存中移走，因爲他們是在處理過程中產生的，如果移走就不能被重建。
4） perm 意味着永久性，這種類型的chunk包含永久的對象，大型的permanent類型的chunk也可能包含有用的空間，
這部分可用空間可以在需要的時候釋放。
在shared pool 中可用的chunk（也就是free類型的）會被連接起來成爲 free list 或者叫bucket（一個free list就是一個bucket）
每個backet中的chunk的大小是不同的。
當某個進程需要shared pool 裏面的一個chunk，該進程首先倒伏後所需空間大小的backet上去掃描，以找到最合適的chunk，掃描持續到backet的最末端，值到找到尺寸符合的chunk爲止，如果找到的chunk尺寸必須要的要大，則這個被找到的chunk就會被拆分一個用來存儲數據
另一個成爲free類型的chunk 併成爲當前的bucket。
當某個bucket不包含有任何尺寸的chunk，那麼就從下一個非空的backet上獲得一個最小的chunk，如果在剩下的所有的backet中都找不到可用的chunk
則需要掃描已經使用的recreatable類型的chunk。從該鏈表上釋放出部分chunk，因爲只有recreatable類型的chunk纔是可以被臨時一處內存的。
但某個chunk正在被使用時該chunk是不能被移除內存的。比如某個SQL語句正在執行，那麼該語句所使用的chunk就不能被移除內存。該SQL所引用的表，索引
等對象佔用的chunk也不能夠被移除內存，當shared pool中無法找到滿足大小的所需內存時就會出現ORA-4031的錯誤。
當出現ORA-4031的錯誤的時候，我們查詢V$SGSTAT中的可用shared pool空間時，可能發現可用的內存足夠大了，爲什麼還是出現ORA-4031錯誤呢？
事實上，在oracle發出錯誤之前已經釋放出大量的recreatable類型的chunk了因此會產生不少的可用內存。但是這些可用的chunk中沒有一個是連續的從而才發出ORA-4031的錯誤。