> Tried to flush the shared pool and it would release some space but a large
> chuck was not being released and this was strange since we have only
acouple
> of objects pinned.
If by pinned you mean kept (with dbms_shared_pool pkg), the large chrunk
space you are talking about might have not been released
because it was part of an object that was being pinned at that moment
(executed/parsed/etc at that moment) or maybe it was a permament chrunk
which
won 't get released by executing a flush shared pool. Where did you see that
chrunk?
What I would do is to set 4031 event in the init.ora file, and would also
try to keep all the important objects in the SP. Exactly what you have
already done.
If you are not seeing contention for the SP latch you don 't have to worry
for SP freelists fragmentation. Anyway I believe it 's good practice to keep
some objects (procedures as well as cursors) in the SP to avoid such
fragmentation and to minimize reloads/reparsing.
Depending on the session lifetime, and in the amount of concurrent sessions,
I believe cursor_space_for_time= true grabs a lot of SP memory. That
might have been the cause of your 4031 problem. Maybe you got out of SP free
memory because of that.
HTH
Regards
Diego.
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe send email to: oracle-l-request@(protected)
put 'unsubscribe ' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- --
