 | | | ORA-04031 error while trying to load a PL/SQL object | ORA-04031 error while trying to load a PL/SQL object 2006-02-06 - By Hameed, Amir
Folks,
I have an 11i (11.5.0)/9.2.0.6 (64-bit) database running on Solaris 8
with the following shared pool sizing:
Shared_pool: 1.2 GB
Db_cache_size: 6 GB
ODM is enabled and that is why the cache size is large.
We run hot backups on this database (using use-managed backup procedure)
and flush the shared pool every night after the hot backup (this process
is scripted into the backup process). I pin ~ 300 packages into SGA
based upon an algorithm in the pinning script. We had an issue this past
Friday where some concurrent programs failed and reported the following
error in their log files:
-- --
Cause: wiltbf failed due to ORA-04031 (See ORA-04031.ora-code.com): unable to allocate 43712 bytes of
shared memory ("shared pool","WIP_TRANSACTIONS_PKG","PL/SQL
MPCODE","BAMIMA: Bam Buffer")
ORA-06508 (See ORA-06508.ora-code.com): PL/SQL: could not find program unit being called
ORA-06512 (See ORA-06512.ora-code.com): at line 1
----
The action taken to remediate the problem was that we shutdown the
concurrent managers and then flushed the shared pool (without bouncing
the database) and the problem went away. I now have the following
questions:
1. I have had this issue about two years ago when I was running 64-bit
8.1.7.4/11.5.6 but at that time Oracle had reported the ORA-04031 (See ORA-04031.ora-code.com) in the
database alert log file but this time it did not. I was expecting it to
report this message in the alert file. Could someone please explain
whether this message does not necessarily have to appear in the alert
log file or that it should have and that this might be a bug?
2. I was under the impression that the shared pool algorithm in 9i2 has
changed from 8.1.7.4 and that the shared pool fragmentation is not an
issue anymore; but it seems that I ran into a shared pool fragmentation
scenario and even with the daily flush, the shared pool still got
extremely fragmented. Prior to the past week, we used to bounce the
database every night after the backup but we stopped doing that about 8
days ago and I believe that it contributed to the shared pool
fragmentation. Is flushing the shared pool on daily basis not enough to
cleanup fragmentation if one wants to keep the instance running for
weeks?
Any feedback will be appreciated.
Regards
Amir
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7233.28">
<TITLE>ORA-04031 (See ORA-04031.ora-code.com) error while trying to load a PL/SQL object</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=2 FACE="Comic Sans MS">Folks,</FONT>
<BR><FONT SIZE=2 FACE="Comic Sans MS">I have an 11i (11.5.0)/9.2.0.6 (64-bit)
database running on Solaris 8 with the following shared pool sizing:</FONT>
</P>
<P><FONT SIZE=2 FACE="Comic Sans MS">Shared_pool: 1.2 GB<
/FONT>
<BR><FONT SIZE=2 FACE="Comic Sans MS">Db_cache_size: 6 GB</FONT>
</P>
<P><FONT SIZE=2 FACE="Comic Sans MS">ODM is enabled and that is why the cache
size is large. </FONT>
<BR><FONT SIZE=2 FACE="Comic Sans MS">We run hot backups on this database
(using use-managed backup procedure) and flush the shared pool every night after
the hot backup (this process is scripted into the backup process). I pin ~ 300
packages into SGA based upon an algorithm in the pinning script. We had an
issue this past Friday where some concurrent programs failed and reported the
following error in their log files:</FONT></P>
<P><FONT SIZE=2 FACE="Comic Sans MS">-- --</FONT>
<BR><FONT SIZE=2 FACE="Comic Sans MS">Cause: wiltbf failed due to ORA-04031 (See ORA-04031.ora-code.com):
unable to allocate 43712 bytes of shared memory ("shared pool","
;WIP_TRANSACTIONS_PKG","PL/SQL MPCODE","BAMIMA: Bam Buffer
")<BR>
ORA-06508 (See ORA-06508.ora-code.com): PL/SQL: could not find program unit being called<BR>
ORA-06512 (See ORA-06512.ora-code.com): at line 1<BR>
</FONT><FONT FACE="Times New Roman">----</FONT>
</P>
<P><FONT SIZE=2 FACE="Comic Sans MS">The action taken to remediate the problem
was that we shutdown the concurrent managers and then flushed the shared pool
(without bouncing the database) and the problem went away. I now have the
following questions:</FONT></P>
<P><FONT SIZE=2 FACE="Comic Sans MS">1. I have had this issue about two years
ago when I was running 64-bit 8.1.7.4/11.5.6 but at that time Oracle had
reported the ORA-04031 (See ORA-04031.ora-code.com) in the database alert log file but this time it did not.
I was expecting it to report this message in the alert file. Could someone
please explain whether this message does not necessarily have to appear in the
alert log file or that it should have and that this might be a bug?</FONT></P>
<P><FONT SIZE=2 FACE="Comic Sans MS">2. I was under the impression that the
shared pool algorithm in 9i2 has changed from 8.1.7.4 and that the shared pool
fragmentation is not an issue anymore; but it seems that I ran into a shared
pool fragmentation scenario and even with the daily flush, the shared pool
still got extremely fragmented. Prior to the past week, we used to bounce the
database every night after the backup but we stopped doing that about 8 days
ago and I believe that it contributed to the shared pool fragmentation. Is
flushing the shared pool on daily basis not enough to cleanup fragmentation if
one wants to keep the instance running for weeks?</FONT></P>
<P><FONT SIZE=2 FACE="Comic Sans MS">Any feedback will be appreciated.</FONT>
</P>
<P><FONT SIZE=2 FACE="Comic Sans MS">Regards</FONT>
<BR><FONT SIZE=2 FACE="Comic Sans MS">Amir</FONT>
</P>
<BR>
<BR>
<BR>
</BODY>
</HTML>
|
|
|