ORA-04020can be related to Bug:520858 . Problem known. To be fixed in 8.1.3.
Hi. The bug is that a lock acquired by PL/SQL is not being released, thus
causing a deadlock when another lock is acquired on the same
table but in an incompatible mode. The problem was originally reported by
a customer who was using DBMS_SQL to truncate a table and
encountered the bug.
The bug manifests itself as a self-deadlock with an ORA-4020 being
signaled. In the trace you see that the session is trying to acquire an
exclusive library cache lock on an object, while still holding a share
lock on that object. This is the scenario I found in your trace file. So,
either you are encountering this bug, or it is possible that this really
is being signaled due to an application design error.
I think you may need to contact Oracle Support.
"The Views expressed here are my own and not necessarily those of Oracle
> We've had a problem occasionally on our 8i server (RH6.1).
> Oracle generated a trace file that hit the maximum file size for linux
> (2.1 gigabytes). One of the Oracle processes (i.e the one that writes
> the trace) then goes into an infinite loop. Running STRACE -P shows
> that the process was attempted to append to a file already at the
> maximum size.
> (I don't know why Oracle was trying to build such a big trace file. We
> had a deadlock ORA-04020 and have it set up to generate a process state
> As I didn't want to kill the process, I had to shutdown the production
> database and restart it.
> Has anyone else had this problem? Any comments or suggestions?
> Sent via Deja.com http://www.deja.com/
> Before you buy.