Re: DBMS_SHARED_POOL / pinning for consistent performance

  • From: "Powell, Mark" <mark.powell2@xxxxxxx>
  • To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 31 Mar 2020 20:12:35 +0000


Perhaps checking v$db_object_cache for loads, locks,  pins, and invalidations 
would be helpful in determining if the package is being flushed too often.

Mark Powell
Database Administration
(313) 592-5148


________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on behalf 
of Lothar Flatz <l.flatz@xxxxxxxxxx>
Sent: Tuesday, March 31, 2020 3:29 PM
To: vxsmimmcp@xxxxxxxxxx <vxsmimmcp@xxxxxxxxxx>; ORACLE-L 
<oracle-l@xxxxxxxxxxxxx>
Subject: Re: DBMS_SHARED_POOL / pinning for consistent performance

Hi Mark,

what bothers me is the lack of good information, e.g. measurement.
There seemed to be your underlying assumption that the time spent for the long 
waits is spent parsing and loading the package.
That is possible. But time could be also spent on I/O.
Is there any good evidence that parsing your package is causing the long waits?
If you had diagnostic and tuning pack installed, you would find good 
information in active session history.
If not, a trace might help too.

regards

Lothar


Am 31.03.2020 um 16:17 schrieb McPeak, Matt (Consultant):

We have a very large, packaged software application with tons of PL/SQL code.



One of the PL/SQL APIs, a package which relies on other packages, and so on β€“ 
many levels deep β€“ is showing intermittent terrible performance.  Usually, the 
API returns a response in less than one second.  Occasionally, it takes over a 
minute.



We think we have identified a pattern showing that the poor performance seems 
to follow a period of no activity.  That is, if no call is made to the API for 
a while, the next call is likely to be excessively slow.



For this reason, we are wondering if caching might have something to do with it 
and whether DBMS_SHARED_POOL could help stabilize performance.



My questions are as follows:



  1.  Would we want to pin the PL/SQL packages or the SQL cursors involved, or 
both?





  1.  Would it be reasonable to purge *everything* from the shared pool (in 
test!), run the API, and then query the shared pool as a good way to identify 
the objects and/or cursors to pin?





  1.  What are the dangers and downsides of pinning?





  1.  We have tons of RAM β€“ is there some way or setting that we could just 
size this cache big enough to cache ALL PL/SQL in the application?  It’s 
enormous (Oracle E-Business Suite), but so is our machine.





Thanks in advance for your attention to any or all of these questions.



Regards,

Matt







--






DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 
22102, USA.
DXC Technology Company -- This message is transmitted to you by or on behalf of 
DXC Technology Company or one of its affiliates. It is intended exclusively for 
the addressee. The substance of this message, along with any attachments, may 
contain proprietary, confidential or privileged information or information that 
is otherwise legally exempt from disclosure. Any unauthorized review, use, 
disclosure or distribution is prohibited. If you are not the intended recipient 
of this message, you are not authorized to read, print, retain, copy or 
disseminate any part of this message. If you have received this message in 
error, please destroy and delete all copies and notify the sender by return 
e-mail. Regardless of content, this e-mail shall not operate to bind DXC 
Technology Company or any of its affiliates to any order or other contract 
unless pursuant to explicit written agreement or government initiative 
expressly permitting the use of e-mail for such purpose. --.

Other related posts: