想要徹底理解4031錯(cuò)誤發(fā)生的原因就要了解SQL語句的執(zhí)行過程以及Oracle共享內(nèi)存的結(jié)構(gòu)
客戶端輸入sql語句酷誓，sql語句通過網(wǎng)絡(luò)到達(dá)數(shù)據(jù)庫實(shí)例颊亮，server process接受sql語句。Server process接受到SQL語句后將sql語句解析成執(zhí)行計(jì)劃伸蚯，然后才能執(zhí)行攻锰。
需要說明的是在將SQL語句解析成執(zhí)行計(jì)劃的過程中會消耗計(jì)算機(jī)大量CPU資源因此就會產(chǎn)生一個(gè)問題揩魂，例如：
A用戶執(zhí)行一個(gè)SQL語句解析換成執(zhí)行，B用戶也有可能執(zhí)行同樣的SQL拐揭。如何才能高效利用CPU資源撤蟆，不去做重復(fù)的解析工作呢？
因此就誕生了shared pool堂污，shared pool就是SGA中用來緩存SQL語句以及對應(yīng)解析出的執(zhí)行計(jì)劃的一片內(nèi)存區(qū)域家肯。
這里結(jié)合Oracle實(shí)例管理的這張圖對上面一幅客戶端與Oracle之間會話通信的過程進(jìn)行簡單的解釋說明：
首先客戶端會在同Oracle實(shí)例間建立的連接池當(dāng)中的眾多連接中選擇一條空閑的連接傳輸SQL語句（server
process是服務(wù)器進(jìn)程，可以連接到Oracle實(shí)例盟猖，在用戶建立會話時(shí)啟動(dòng)）讨衣。
Server Process首先會先去shared pool中查找是否已經(jīng)有了該條SQL語句對應(yīng)的已緩存的執(zhí)行計(jì)劃，如果有直接執(zhí)行（該種SQL解析也叫作軟解析）式镐。如果沒有則會自己生成執(zhí)行計(jì)劃并緩存執(zhí)行（該種解析也叫作硬解析）值依。
其中shared pool是SGA（共享全局區(qū)）中的一部分內(nèi)存資源，由所有服務(wù)器進(jìn)程和后臺進(jìn)程共享碟案。
Buffer Cache也是SGA中的一塊區(qū)域愿险，用來緩存Data
files中取出的數(shù)據(jù)，如果沒有buffer cache的話那么每次訪問數(shù)據(jù)的時(shí)候都需要消耗I/O。
所以當(dāng)執(zhí)行一個(gè)SQL語句對應(yīng)的執(zhí)行計(jì)劃要訪問數(shù)據(jù)辆亏，server process會先進(jìn)入buffer cache找是否有所需要的數(shù)據(jù)风秤，如果有就直接取出返回沒有才會去Data files去取并將其先放入buffer
cache中，并在其中對數(shù)據(jù)進(jìn)行修改扮叨。之后再通過物理I/O寫回到Oracle的數(shù)據(jù)文件中去缤弦。
在對數(shù)據(jù)進(jìn)行修改的同時(shí)會向SGA中另一塊內(nèi)存區(qū)域叫作Redolog Buffer中寫入相關(guān)的日志信息。之后再寫回到Oracle的日志文件中區(qū)彻磁。
將返回的數(shù)據(jù)或信息通過連接返回給客戶端碍沐。
上述過程中可以看出共享池是SGA中一塊核心的內(nèi)容，經(jīng)典的Oracle4031錯(cuò)誤也與這一塊內(nèi)存區(qū)域有密切的關(guān)系衷蜓。
Free Cache:
顧名思義就是shared pool中的一塊空閑的內(nèi)存區(qū)域累提。
Library Cache（庫緩存）：
主要緩存的是SQL語句，以及SQL句解析出來的執(zhí)行計(jì)劃磁浇。
Raw Cache（字典緩存）：
Oracle數(shù)據(jù)庫的自身信息都存儲在數(shù)據(jù)字典中（比如說：數(shù)據(jù)庫中有多少表斋陪，有多少用戶，表中有多少列每個(gè)表多大等等）
Shared Pool主要的三塊空間中一般Free Cache和Library Cache較容易有問題置吓。我們可以整體上設(shè)置Shared Pool的大小但不能控制當(dāng)中的Library Cache和Raw Cache的大小无虚。
需要理解的是，F(xiàn)ree Cache并不是一個(gè)大塊連續(xù)的內(nèi)存空間而是一個(gè)個(gè)內(nèi)存塊通過chain鏈將其鏈接如下圖所示
圖中橙色的圓代表一個(gè)個(gè)內(nèi)存塊在Oracle中稱之為chunk,而這些chunk會根據(jù)大小的不容被歸類掛載一條條chain上衍锚，從下往上越來越大友题。
在這里舉個(gè)例子：
如果有一條SQL語句解析出來大小為10K，那么就在第8K-12K的內(nèi)存鏈上找比如找到一個(gè)11K的塊那么就將其中的10K丟到Library Cache中戴质，而剩下的1K再掛到相應(yīng)的空間鏈里面去度宦。這就是Free空間的內(nèi)存組織情況。
這里需要特別提醒強(qiáng)調(diào)的是——什么時(shí)候需要在Free空間你面找chunk置森？答案是在執(zhí)行硬解析的時(shí)候斗埂。
由此可見當(dāng)有大量硬解析的時(shí)候，除了要去Free空間中找chunk還會產(chǎn)生大量的小碎片凫海，于是就有可能產(chǎn)生這種情況呛凶，及有大量足夠的Free空間但是被分割成很多小的碎片，沒有適合可用的內(nèi)存塊行贪。這種情況便會產(chǎn)生Oracle經(jīng)典的4031報(bào)錯(cuò)漾稀。
總結(jié)一下Oracle產(chǎn)生4031錯(cuò)誤的背景條件：
大量的硬解析產(chǎn)生了很多小碎片
產(chǎn)生了大量的小碎片后突然來了一條大的SQL語句需要解析。
本文原創(chuàng)首發(fā)于Cobub官網(wǎng)博客建瘫，作者：鐘澤
如有轉(zhuǎn)載請注明作者和出處崭捍！
推薦一款開源 私有化部署的移動(dòng)應(yīng)用數(shù)據(jù)統(tǒng)計(jì)分析 系統(tǒng)Cobub Razor
開源社區(qū)技術(shù)交流QQ群：194022996
