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
-- Heapdump Analyzer v1.00 by Tanel Poder ( http://www.tanelpoder.com ;)
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>
