Giải quyết ORA-4031 "không thể phân bổ x byte bộ nhớ chia sẻ"

Question

Tôi cần một số gợi ý về cách chẩn đoán và khắc phục vấn đề này. Tôi không biết nếu đây là một vấn đề thiết lập máy chủ đơn giản hoặc một vấn đề thiết kế ứng dụng (hoặc cả hai).

Một hoặc hai lần mỗi vài tháng cơ sở dữ liệu Oracle XE này báo cáo lỗi ORA-4031. Nó không trỏ đến bất kỳ phần nào của sga một cách nhất quán. Một ví dụ gần đây là:

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

Khi lỗi này đi lên, nếu người dùng giữ tươi mát, nhấp vào liên kết khác nhau, họ thường sẽ nhận được nhiều hơn những loại lỗi vào những thời điểm khác nhau, sau đó chẳng bao lâu họ' sẽ nhận được lỗi trang "404 không tìm thấy".

Khởi động lại cơ sở dữ liệu thường giải quyết vấn đề một lúc, sau đó một tháng hoặc lâu hơn lại xuất hiện, nhưng hiếm khi ở cùng một vị trí trong chương trình (tức là nó dường như không liên quan đến bất kỳ phần mã cụ thể nào) (lỗi ví dụ trên đã được nêu ra từ một trang Apex đang phân loại 5000 hàng từ một bảng).

Tôi đã thử tăng sga_max_size từ 140M lên 256M và hy vọng điều này sẽ giúp mọi thứ. Tất nhiên, tôi sẽ không biết nếu điều này đã giúp vì tôi phải khởi động lại cơ sở dữ liệu để thay đổi cài đặt :)

Tôi đang chạy Oracle XE 10.2.0.1.0 trên hộp Oracle Enterprise Linux 5 với 512MB RAM. Máy chủ chỉ chạy cơ sở dữ liệu, Oracle Apex (v3.1.2) và máy chủ web Apache. Tôi đã cài đặt nó với khá nhiều tham số mặc định và nó đã hoạt động khá tốt trong một năm. Hầu hết các vấn đề tôi đã có thể tự giải quyết bằng cách điều chỉnh mã ứng dụng; nó không được sử dụng nhiều và không phải là một hệ thống kinh doanh quan trọng.

Đây là một số thiết lập hiện tại tôi nghĩ rằng có thể có liên quan:

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 

Nếu đó là bất kỳ sự giúp đỡ ở đây là kích thước SGA hiện tại:

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

Answer 1

Mặc dù bạn đang sử dụng ASMM, bạn có thể thiết lập một kích thước tối thiểu cho hồ bơi lớn (MMAN sẽ không co lại dưới giá trị đó). Bạn cũng có thể thử ghim một số đối tượng và tăng SGA_TARGET.

Answer 2

Đừng quên phân mảnh. Nếu bạn có nhiều lưu lượng truy cập, các hồ bơi của bạn có thể bị phân mảnh và thậm chí nếu bạn có nhiều MB miễn phí, có thể không có khối nào lớn hơn 4KB. Kiểm tra kích thước của khối tự do lớn nhất với một truy vấn như:

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

Lỗi: ORA-04.031: không thể phân bổ 4064 byte của bộ nhớ chia sẻ ("chia sẻ hồ bơi", "chọn increment $ , minvalue, m ... "" đống SGA (3.0)", "đống kglsim")

Solution: by nepasoft nepal 

1 ps-ef | grep oracle

2 tìm ra SMON và giết pid cho nó

3 SQL> khởi động gắn kết

ORACLE dụ bắt đầu.

Tổng System Global Area 4831838208 byte Fixed Size 2.027.320 byte Biến Kích 4764729544 byte Cơ sở dữ liệu Buffers 50.331.648 byte Redo Buffers 14.749.696 byte Cơ sở dữ liệu gắn kết. SQL>

4 SQL> thay đổi tập hợp hệ thống shared_pool_size = 100M scope = spfile;

Hệ thống bị thay đổi.

5 SQL> shutdown ngay

ORA-01.109: cơ sở dữ liệu không mở

Cơ sở dữ liệu xuống ngựa. Phiên bản ORACLE tắt.

6 SQL> khởi động

ORACLE bắt đầu.

Tổng System Global Area 4831838208 byte Fixed Size 2.027.320 byte Biến Kích 4764729544 byte Cơ sở dữ liệu Buffers 50.331.648 byte Redo Buffers 14.749.696 byte Cơ sở dữ liệu gắn kết. Đã mở cơ sở dữ liệu.

7 SQL> tạo pfile từ spfile;

Đã tạo tệp.

SOLVED

Answer 4

Đây là lỗi Oracle, rò rỉ bộ nhớ trong shared_pool, rất có thể db quản lý nhiều phân vùng. Giải pháp: Trong bản vá ý kiến ​​của tôi không tồn tại, hãy kiểm tra với hỗ trợ oracle. Bạn có thể thử với subpools hoặc en (de) AMM thể ...

Answer 5

Sau đây là không cần thiết vì chúng họ không sửa chữa các lỗi:

1. 1 ps-ef | grep oracle
2. Tìm smon và giết pid cho nó
3. SQL> khởi động gắn SQL>
4. Tạo pfile từ spfile;

Khởi động lại cơ sở dữ liệu sẽ làm sạch hồ bơi của bạn và giải quyết được hiệu quả không phải vấn đề.

Chỉnh sửa large_pool của bạn để nó không thể xuống thấp hơn một điểm nhất định hoặc thêm bộ nhớ và đặt bộ nhớ tối đa cao hơn.

Answer 6

Tất cả các câu trả lời hiện tại đều giải quyết được triệu chứng (lỗi bộ nhớ chia sẻ), và không phải vấn đề, có khả năng không sử dụng các biến liên kết trong các truy vấn sql \ JDBC của bạn, ngay cả khi không cần thiết. Truy vấn thông qua mà không có biến liên kết khiến cho Oracle "phân tích cú pháp" truy vấn mỗi lần, xác định kế hoạch thực thi của nó, v.v.

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

Một số đoạn từ liên kết ở trên.

"Java hỗ trợ các biến ràng buộc, các nhà phát triển của bạn phải bắt đầu sử dụng chuẩn bị phát biểu và ràng buộc đầu vào cho nó Nếu bạn muốn hệ thống của bạn để cuối cùng mở rộng ngoài nói về 3 hoặc 4 người dùng - bạn sẽ làm điều này ngay bây giờ (sửa mã) .Đó không phải là một cái gì đó để suy nghĩ về, nó là cái gì bạn PHẢI làm Một tác dụng phụ của vấn đề này - hồ bơi chia sẻ của bạn sẽ biến mất khá nhiều. nguyên nhân gốc. "

" Cách Oracle chia sẻ hồ bơi (một cấu trúc dữ liệu bộ nhớ chia sẻ rất quan trọng) hoạt động được dựa trên các nhà phát triển sử dụng các biến liên kết. "

"biến Bind là SO ồ ạt quan trọng - Tôi không thể ở bất kỳ hình dạng bằng cách này hay hình thức phóng đại tầm quan trọng của họ."