AW: shared pool waits

From: <ahmed.fikri_at_t-online.de>
Date: Tue, 21 Sep 2021 08:30:17 +0200 (CEST)
Message-ID: <1632205817471.2155197.f9a0cb587d57d67035a9596b4ba0084f38558e5a_at_spica.telekom.de>



Hi,  

pragmatically I used to solve these problems (in my opinion oracle bugs) by creating a scheduler job to detect and remove the SQLs, that cause such problems, from the shared pool (using dbms_shared_pool.purge). Since one can not change the vendor's code.  

Best regards
Ahmed      

-----Original-Nachricht-----
Betreff: shared pool waits
Datum: 2021-09-20T21:25:36+0200
Von: "Pap" <oracle.developer35_at_gmail.com> An: "Oracle L" <oracle-l_at_freelists.org>      

Hi , We have a customer application in which we see high wait events like
'cursor:mutex ' and 'library cache lock' for a select query occasionally
and thus a specific functionality impacted. This select query(which is part of a plsql procedure) is quick query which runs ~5 million times/hr. But even though number of execution is same mostly throughout the day, it still went through these odd wait events making the per execution time went higher for around ~15 minutes duration causing slowness. And during this period, the ASH shows fro this query, the value of column in_hard_parse as
'N' but in_parse as 'Y' and 'N' both. And we saw we were having stats
gather running on that base object during same time. We have no_invalidate set as 'FALSE" as table stats preference, So wanted to understand from experts, can it be really because of 'parsing' issue and we should delete this no_invalidate preference so that it can inherit the default global preference i.e no_invalidate=>auto? The database version is 19C. 

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Sep 21 2021 - 08:30:17 CEST

Original text of this message