ORA-04031 in spite of enough free memory

From: Noveljic Nenad <nenad.noveljic_at_vontobel.com>
Date: Tue, 28 May 2019 13:04:30 +0000
Message-ID: <22726_1559048684_5CED31EC_22726_595_1_85d212a2f6b840a5a8a5865650cc2093_at_vontobel.com>



I've got the following error on a 12.2 database during some intensive DML operations on securefile LOBs:

ORA-04031: unable to allocate 52824 bytes of shared memory ("shared pool","unknown object","KTSL subheap","ktsl_load_disp-2")

The session was waiting on an SGA resizing operation to complete:

0: waited for 'SGA: allocation forcing component growth'

    =0x0, =0x0, =0x0
    wait_id=75 seq_num=126 snap_id=26
    wait times: snap=0.000000 sec, exc=2.501782 sec, total=2.504110 sec     wait times: max=infinite
    wait counts: calls=25 os=25
    occurred after 0.000000 sec of elapsed time 1: waited for 'SGA: allocation forcing component growth'

    =0x0, =0x0, =0x0
    wait_id=100 seq_num=125 snap_id=1
    wait times: snap=0.000085 sec, exc=0.000085 sec, total=0.000085 sec     wait times: max=infinite
    wait counts: calls=1 os=1
    occurred after 0.000000 sec of elapsed time 2: waited for 'SGA: allocation forcing component growth'

    =0x0, =0x0, =0x0
    wait_id=75 seq_num=124 snap_id=25
    wait times: snap=0.100115 sec, exc=2.501782 sec, total=2.504025 sec     wait times: max=infinite
    wait counts: calls=25 os=25
    occurred after 0.000000 sec of elapsed time

The resizing operations failed - I assume that's one of the reasons for ORA-04031:

COMPONENT OPER_TYPE OPER_MODE PARAMETER INITIAL_SIZE TARGET_SIZE FINAL_SIZE STATUS

-------------------- ------------- --------- ----------------- ------------ ----------- ---------- ---------
shared pool          STATIC                  shared_pool_size             0  1493172224 1493172224 ERROR
shared pool          STATIC                  shared_pool_size             0  1493172224 1493172224 ERROR
shared pool          STATIC                  shared_pool_size             0  1493172224 1493172224 ERROR
shared pool          STATIC                  shared_pool_size             0  1493172224 1493172224 ERROR
shared pool          STATIC                  shared_pool_size             0  1493172224 1493172224 ERROR
DEFAULT buffer cache STATIC                  db_cache_size                0   402653184  402653184 ERROR
DEFAULT buffer cache STATIC                  db_cache_size                0   402653184  402653184 ERROR
shared pool          STATIC                  shared_pool_size             0  1493172224 1493172224 ERROR

However, according to the ORA-04031 dump there were 496 MB free memory to allocate 52824 bytes from:



TOP 10 MEMORY USES FOR SGA HEAP

"free memory " 496 MB 35%
"object queue hash buckets " 192 MB 13%
"Checkpoint queue " 96 MB 7%
"KTSL subheap " 93 MB 7%
"ASH buffers " 71 MB 5%
"dbwriter coalesce buffer " 46 MB 3%
"event statistics per sess " 23 MB 2%
"private strands " 22 MB 2%
"kcbi io desc slot " 21 MB 1%
"kglsim object batch " 19 MB 1%
TOTALS ---------------------------------------
Total free memory                   496 MB
Total memory alloc.                 928 MB
Grand total                        1424 MB

Furthermore, the consecutive pieces of freeable memory seemed to be large enough to fulfil the request for 52824 bytes allocation:

/u00/oracle/orabase/local/bin/heapdump_analyzer DB_ora_13989.trc | grep free | more

  Total_size #Chunks Chunk_size, From_heap, Chunk_type, Alloc_reason

  • ------- ------------ ----------------- ----------------- ----------------- ... 73586688 1392 52864 , sga heap(1,0), freeable, KTSL subheap 20987008 397 52864 , sga heap(1,0), R-freeable, KTSL subheap 19408560 11390 1704 , sga heap(1,0), freeable, kcbi io desc sl 16789760 20 839488 , sga heap(1,3), R-free, 12581760 6 2096960 , sga heap(1,0), R-free, 11036608 11 1003328 , sga heap(1,0), R-free, 7983416 3853 2072 , sga heap(1,0), freeable, parameter table 7367360 7 1052480 , sga heap(1,0), R-free, 5876208 1898 3096 , sga heap(1,0), freeable, keomg: entry li 4642128 1 4642128 , sga heap(1,3), free, 4625848 127 36424 , sga heap(1,0), freeable, krbmror 4624200 9175 504 , sga heap(1,0), freeable, KGLDA 4423720 305 14504 , sga heap(1,0), freeable, ksu:stats_freel 4342896 1 4342896 , sga heap(1,3), free, 4271864 1021 4184 , sga heap(1,0), freeable, KTSL subheap 4161536 1016 4096 , sga heap(1,3), freeableU, SQLA^74619d27 4129664 1 4129664 , sga heap(1,3), free, 3985104 1 3985104 , sga heap(1,3), free, 3693256 1 3693256 , sga heap(1,3), free, 3237952 1 3237952 , sga heap(1,3), free, 3169152 6 528192 , sga heap(1,0), R-free, 2811872 1 2811872 , sga heap(1,3), free, 2588672 632 4096 , sga heap(1,3), freeableU, SQLA^1e63b6a ...

A little side note: Thank you, Tanel, for providing such a useful script!

I'm aware that the memory assigned to this instance is tiny (it's a sandbox) and that throwing a couple of GBs would prevent the error. I could easily do that, but my objective is to use this occurrence for learning.

In particular, I'm interested to know what might have triggered the resizing decision when there was enough consecutive freeable memory to fulfil the request. Further, is there some possibility to trace the resizing decisions?

I'm also aware of the bugs related to "KTSL subheap" allocations in 12.1, but that's not being the issue here.

Best regards,

Nenad

https://nenadnoveljic.com/blog/



Please consider the environment before printing this e-mail. Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br />

This message is intended only for the individual named. It may contain confidential or privileged information. If you are not the named addressee you should in particular not disseminate, distribute, modify or copy this e-mail. Please notify the sender immediately by e-mail, if you have received this message by mistake and delete it from your system.<br /> Without prejudice to any contractual agreements between you and us which shall prevail in any case, we take it as your authorization to correspond with you by e-mail if you send us messages by e-mail. However, we reserve the right not to execute orders and instructions transmitted by e-mail at any time and without further explanation.<br /> E-mail transmission may not be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also processing of incoming e-mails cannot be guaranteed. All liability of Vontobel Holding Ltd. and any of its affiliates (hereinafter collectively referred to as "Vontobel Group") for any damages resulting from e-mail use is excluded. You are advised that urgent and time sensitive messages should not be sent by e-mail and if verification is required please request a printed version.</br> Please note that all e-mail communications to and from the Vontobel Group are subject to electronic storage and review by Vontobel Group. Unless stated to the contrary and without prejudice to any contractual agreements between you and Vontobel Group which shall prevail in any case, e-mail-communication is for informational purposes only and is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction.<br /> The legal basis for the processing of your personal data is the legitimate interest to develop a commercial relationship with you, as well as your consent to forward you commercial communications. You can exercise, at any time and under the terms established under current regulation, your rights. If you prefer not to receive any further communications, please contact your client relationship manager if you are a client of Vontobel Group or notify the sender. Please note for an exact reference to the affected group entity the corporate e-mail signature. For further information about data privacy at Vontobel Group please consult <a href="https://www.vontobel.com">www.vontobel.com</a>.<br />
</p>
</body>
</html>



--
http://www.freelists.org/webpage/oracle-l
Received on Tue May 28 2019 - 15:04:30 CEST

Original text of this message