ORA-4031錯誤深刻解析

想要完全理解4031錯誤發生的緣由就要了解SQL語句的執行過程以及Oracle共享內存的結構

客戶端與Oracle之間通訊過程圖

客戶端輸入sql語句，sql語句經過網絡到達數據庫實例，server process接受sql語句。Server process接受到SQL語句後將sql語句解析成執行計劃，而後才能執行。
須要說明的是在將SQL語句解析成執行計劃的過程當中會消耗計算機大量CPU資源所以就會產生一個問題，例如：
A用戶執行一個SQL語句解析換成執行，B用戶也有可能執行一樣的SQL。如何才能高效利用CPU資源，不去作重複的解析工做呢？
所以就誕生了shared pool，shared pool就是SGA中用來緩存SQL語句以及對應解析出的執行計劃的一片內存區域。

Oracle實例管理

這裏結合Oracle實例管理的這張圖對上面一幅客戶端與Oracle之間會話通訊的過程進行簡單的解釋說明：

1. 首先客戶端會在同Oracle實例間創建的鏈接池當中的衆多鏈接中選擇一條空閒的鏈接傳輸SQL語句（server process是服務器進程，能夠鏈接到Oracle實例，在用戶創建會話時啓動 ）。
2. Server Process首先會先去shared pool中查找是否已經有了該條SQL語句對應的已緩存的執行計劃，若是有直接執行（該種SQL解析也叫做軟解析）。若是沒有則會本身生成執行計劃並緩存執行（該種解析也叫做硬解析）。
3. 其中shared pool是SGA（共享全局區）中的一部份內存資源，由全部服務器進程和後臺進程共享。
4. Buffer Cache也是SGA中的一塊區域，用來緩存Data files中取出的數據，若是沒有buffer cache的話那麼每次訪問數據的時候都須要消耗I/O。
5. 因此當執行一個SQL語句對應的執行計劃要訪問數據，server process會先進入buffer cache找是否有所須要的數據，若是有就直接取出返回沒有才會去Data files去取並將其先放入buffer cache中，並在其中對數據進行修改。以後再經過物理I/O寫回到Oracle的數據文件中去。
6. 在對數據進行修改的同時會向SGA中另外一塊內存區域叫做Redolog Buffer中寫入相關的日誌信息。以後再寫回到Oracle的日誌文件中區。
7. 將返回的數據或信息經過鏈接返回給客戶端。

上述過程當中能夠看出共享池是SGA中一塊核心的內容，經典的Oracle4031錯誤也與這一塊內存區域有密切的關係。

Free Cache:
顧名思義就是shared pool中的一塊空閒的內存區域。

Library Cache（庫緩存）：
主要緩存的是SQL語句，以及SQL句解析出來的執行計劃。

Raw Cache （字典緩存）：
Oracle數據庫的自身信息都存儲在數據字典中（好比說：數據庫中有多少表，有多少用戶，表中有多少列每一個表多大等等）

Shared Pool主要的三塊空間中通常Free Cache 和 Library Cache較容易有問題。咱們能夠總體上設置Shared Pool的大小但不能控制當中的Library Cache和Raw Cache的大小。
須要理解的是，Free Cache並非一個大塊連續的內存空間而是一個個內存塊經過chain鏈將其連接以下圖所示

圖中橙色的圓表明一個個內存塊在Oracle中稱之爲chunk,而這些chunk會根據大小的不容被歸類掛載一條條chain上，從下往上愈來愈大。

在這裏舉個例子：
若是有一條SQL語句解析出來大小爲10K，那麼就在第8K-12K的內存鏈上找好比找到一個11K的塊那麼就將其中的10K丟到Library Cache中，而剩下的1K再掛到相應的空間鏈裏面去。這就是Free空間的內存組織狀況。

這裏須要特別提醒強調的是——何時須要在Free空間你面找chunk？答案是在執行硬解析的時候。

因而可知當有大量硬解析的時候，除了要去Free空間中找chunk還會產生大量的小碎片，因而就有可能產生這種狀況，及有大量足夠的Free空間可是被分割成不少小的碎片，沒有適合可用的內存塊。這種狀況便會產生Oracle經典的4031報錯。

總結一下Oracle產生4031錯誤的背景條件：

1. 大量的硬解析產生了不少小碎片
2. 產生了大量的小碎片後忽然來了一條大的SQL語句須要解析。

本文原創首發於Cobub官網博客，做者：鍾澤
若有轉載請註明做者和出處！

推薦一款開源私有化部署的移動應用數據統計分析系統Cobub Razor
項目地址：https://github.com/cobub/razor
官網：www.cobub.com