解決ORA-4031「無法分配x字節的共享內存」

Question

我需要一些關於如何診斷和解決這個問題的指針。我不知道這是一個簡單的服務器設置問題還是應用程序設計問題（或兩者兼而有之）。

每隔幾個月會有一次或兩次此Oracle XE數據庫報告ORA-4031錯誤。它並沒有一直指向sga的任何特定部分。最近的一個例子是：

ORA-04031: unable to allocate 8208 bytes of shared memory ("large pool","unknown object","sort subheap","sort key")

當這個錯誤出現，如果用戶不斷刷新，點擊不同的鏈接，他們通常會得到更多的此類錯誤的在不同的時間，然後很快他們」會得到「404找不到」頁面錯誤。

重新啓動數據庫通常可以解決問題一段時間，然後一個月左右它再次出現，但很少在程序中的相同位置（即，它似乎沒有鏈接到任何特定部分的代碼） （上面的示例錯誤是由Apex頁面發起的，該頁面從表格中排序了5000多行）。

我試過將sga_max_size從140M增加到256M，希望這會有所幫助。當然，我不知道這是否有幫助，因爲我不得不重新啓動數據庫來更改設置:)

我在Oracle Enterprise Linux 5機箱上運行Oracle XE 10.2.0.1.0，其中512MB內存。服務器只運行數據庫，Oracle Apex（v3.1.2）和Apache Web服務器。我用幾乎所有的默認參數安裝了它，並且一年左右運行得非常好。我通過調整應用程序代碼可以解決大部分問題;它沒有被廣泛使用，也不是一個關鍵業務系統。

這些都是當前的設置，我認爲可能是相關的：

pga_aggregate_target  41,943,040 
sga_max_size    268,435,456 
sga_target    146,800,640 
shared_pool_reserved_size 5,452,595 
shared_pool_size   104,857,600 

如果它的任何幫助，這裏的電流SGA大小：

Total System Global Area 268435456 bytes 
Fixed Size     1258392 bytes 
Variable Size    251661416 bytes 
Database Buffers   12582912 bytes 
Redo Buffers    2932736 bytes 

Answer 1

即使您正在使用ASMM，可以設置大型游泳池的最小尺寸（MMAN不會將其縮小到低於該值）。 您也可以嘗試鎖定一些對象並增加SGA_TARGET。

Answer 2

不要忘記碎片。 如果流量很大，您的池可能會被分段，即使您有幾MB空閒空間，也可能沒有大於4KB的塊。 檢查最大可用塊的大小與像查詢：

select 
    '0 (<140)' BUCKET, KSMCHCLS, KSMCHIDX, 
    10*trunc(KSMCHSIZ/10) "From", 
    count(*) "Count" , 
    max(KSMCHSIZ) "Biggest", 
    trunc(avg(KSMCHSIZ)) "AvgSize", 
    trunc(sum(KSMCHSIZ)) "Total" 
from 
    x$ksmsp 
where 
    KSMCHSIZ<140 
and 
    KSMCHCLS='free' 
group by 
    KSMCHCLS, KSMCHIDX, 10*trunc(KSMCHSIZ/10) 
UNION ALL 
select 
    '1 (140-267)' BUCKET, 
    KSMCHCLS, 
    KSMCHIDX, 
    20*trunc(KSMCHSIZ/20) , 
    count(*) , 
    max(KSMCHSIZ) , 
    trunc(avg(KSMCHSIZ)) "AvgSize", 
    trunc(sum(KSMCHSIZ)) "Total" 
from 
    x$ksmsp 
where 
    KSMCHSIZ between 140 and 267 
and 
    KSMCHCLS='free' 
group by 
    KSMCHCLS, KSMCHIDX, 20*trunc(KSMCHSIZ/20) 
UNION ALL 
select 
    '2 (268-523)' BUCKET, 
    KSMCHCLS, 
    KSMCHIDX, 
    50*trunc(KSMCHSIZ/50) , 
    count(*) , 
    max(KSMCHSIZ) , 
    trunc(avg(KSMCHSIZ)) "AvgSize", 
    trunc(sum(KSMCHSIZ)) "Total" 
from 
    x$ksmsp 
where 
    KSMCHSIZ between 268 and 523 
and 
    KSMCHCLS='free' 
group by 
    KSMCHCLS, KSMCHIDX, 50*trunc(KSMCHSIZ/50) 
UNION ALL 
select 
    '3-5 (524-4107)' BUCKET, 
    KSMCHCLS, 
    KSMCHIDX, 
    500*trunc(KSMCHSIZ/500) , 
    count(*) , 
    max(KSMCHSIZ) , 
    trunc(avg(KSMCHSIZ)) "AvgSize", 
    trunc(sum(KSMCHSIZ)) "Total" 
from 
    x$ksmsp 
where 
    KSMCHSIZ between 524 and 4107 
and 
    KSMCHCLS='free' 
group by 
    KSMCHCLS, KSMCHIDX, 500*trunc(KSMCHSIZ/500) 
UNION ALL 
select 
    '6+ (4108+)' BUCKET, 
    KSMCHCLS, 
    KSMCHIDX, 
    1000*trunc(KSMCHSIZ/1000) , 
    count(*) , 
    max(KSMCHSIZ) , 
    trunc(avg(KSMCHSIZ)) "AvgSize", 
    trunc(sum(KSMCHSIZ)) "Total" 
from 
    x$ksmsp 
where 
    KSMCHSIZ >= 4108 
and 
    KSMCHCLS='free' 
group by 
    KSMCHCLS, KSMCHIDX, 1000*trunc(KSMCHSIZ/1000); 

Code from

Answer 3

錯誤： ORA-04031：無法分配4064個字節的共享內存（ 「共享池」 中，「選擇增量$ ，MINVALUE，米... 「」 SGA堆（3,0）」， 「kglsim堆」）

Solution: by nepasoft nepal 

1 PS -ef | grep的預言

2找到SMON並殺死它

3 SQL>啓動安裝

ORACLE實例啓動的PID。

總系統全局區4831838208個字節 固定大小2027320個字節 大小可變4764729544個字節 數據庫緩衝區的字節50331648重做 緩衝14749696個字節 數據庫安裝。 SQL>

4 SQL> alter system set shared_pool_size = 100M scope = spfile;

系統改變。

5 SQL>關機立即

ORA-01109：數據庫未打開

數據庫卸除。 ORACLE實例關閉。

6 SQL>啓動

ORACLE實例已啓動。

總系統全局區4831838208個字節 固定大小2027320個字節 大小可變4764729544個字節 數據庫緩衝區的字節50331648重做 緩衝14749696個字節 數據庫安裝。 數據庫已打開。

7 SQL>從spfile創建pfile;

已創建文件。

解決

Answer 4

這是Oracle的bug，在SHARED_POOL內存泄漏，最有可能的DB管理大量的分區。 解決方法：我認爲補丁不存在，請檢查oracle支持。你可以用子池或EN（DE）能夠AMM嘗試...

Answer 5

下列物品，因爲他們沒有得到解決，不需要：

1. 1個PS英法| grep的甲骨文
2. 找到smon並殺死它的pid
3. SQL> startup mount SQL>
4. 從spfile創建pfile;

重新啓動數據庫將刷新您的池並解決問題而不是問題。

修復您的large_pool，以便它不能低於某個點或增加內存並設置較高的最大內存。

Answer 6

所有當前的答案都是針對症狀（共享內存池耗盡），而不是問題，即使看起來不需要這樣做，很可能不會在sql \ JDBC查詢中使用綁定變量。在沒有綁定變量的情況下傳遞查詢會導致Oracle每次「硬解析」查詢，確定其執行計劃等。

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::p11_question_id:528893984337

從上面的鏈接的一些片段：

「Java支持綁定變量，你的開發人員。如果你希望你的系統，最終擴展到超過必須開始使用預處理語句和綁定投入它說的3或4個用戶 - 你現在就會這樣做（修正代碼），這是不必考慮的，這是你必須做的事情。這樣做的副作用 - 共享池問題幾乎消失了。根本原因「。

」The way of the Oracle 共享池（一個非常重要的共享內存數據結構） 操作是基於使用綁定變量的開發人員。「

「綁定變量是如此大規模的重要 - 我不能以任何方式或形式誇大其重要性。」