You're right, flushing the shared pool doesn't truly fix anything; if
you're lucky, it just makes the problem go away for a while, to give
you time to figure out what is really wrong. So...
Keep an eye on what gets stored in the SGA:
Make sure packages, procedures, functions, triggers, etc. are pinned
(triggers are easy to forget, and developers sometimes put large
chunks of code in triggers that would be better placed in packages).
Make sure developers are assembling code into packages and not
submitting large anonymous blocks of PL/SQL throughout the day
(especially watch shell scripts and SQL*Plus scripts where
substitution variables may be used in place of bind variables, as that
will compound the problem by filling up the SGA with nearly-identical
large blocks of code).
Make sure dynamic SQL is only used when truly necessary, and when it
is used, that variables are appropriately bound. It may be especially
worthwhile to perform code reviews on programs written in Java, Perl,
and 3GLs, to look for coding style "lapses"...
Keep an eye out for unnecessary or unreasonable traffic into the SGA:
Watch out for "phantom SQL" -- things like indiscriminate use of
SYS_CONTEXT or USER in PL/SQL blocks. These generate silly SELECTs
from DUAL behind the scenes (maybe not in 10g?). I have seen cases
where hundreds of millions of these statements were flooding the SGA
without the developers realizing it.
Watch out for "SGA abuse", like silly repeated lookups of static
values from the database. I recall a case where a certain small table
of static strings was being queried one billion times a day. There
were only about 1000 rows in this table. By caching
previously-fetched values in a PL/SQL table in the package, we reduced
the number of submissions (executions) of the actual SQL statement by
(Finally, if your ORA-4031
results in a database crash, please call
Oracle and complain. There is really no good reason for an ORA-4031
to cause anything more than a brief slowdown or an error in a single
Your mileage may vary. Hope this helps --
On Thu, 3 Mar 2005 10:54:52 -0800 (PST), A Joshi <ajoshi977@(protected):
> If you have increased the size it is likely bacause of fragmentation. Pin pl/sql on database startup. and pin sql soon after startup. Get dev to use bind variables.
> You could change the cursor_sharing parameter too but that is avoidable.
> Avoid ad hoc sql queries to database.
> "Smith, Ron L." <rlsmith@(protected):
> I have a couple of unrelated Oracle 8.1.7 databases that occasionally
> getting the following error:
: unable to allocate 4200 bytes of shared memory ("shared
> pool","unknown object","sga heap","state objects")=20
> Flushing the Shared Pool does not help the problem. The size of the
> Shared Pool has been increased several times, but doesn't appear to
> help. Neither database is very busy.
> One of the databases serves as a "Gateway" database between a 7.3.4 and
> a 9.2 database just for connectivity. The other is just a straight
> 8.1.7 OLTP database.
> Bouncing the database ALWAYS corrects the problem for several weeks.
> Can anyone help be diagnose the problem?
> Important Notice!!
> If you are not the intended recipient of this e-mail message, any use, =
> distribution or copying of the message is prohibited.
> Please let me know immediately by return e-mail if you have received =
> this message by mistake, then delete the e-mail message.
> Thank you.
> Celebrate Yahoo!'s 10th Birthday!
> Yahoo! Netrospective: 100 Moments of the Web