8i hits infinite loop --Trace file hits 2.1G

8i hits infinite loop --Trace file hits 2.1G

Post by bill.. » Sun, 31 Dec 1899 09:00:00



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
trace).

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.

 
 
 

8i hits infinite loop --Trace file hits 2.1G

Post by Vitalij Serdakovski » Sun, 31 Dec 1899 09:00:00


Usually, trace feature used for debugging if there is a problem. Appropriate
message is written into alert.log (if your looping process is background
one). Analyze this trace and eliminate the problem. Maybe your trace file is
created by network product (big client's activity is like a dead loop:-). If
so you need turn off tracing (see sqlnet.ora).
Good luck.



Quote:> 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
> trace).

> 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.


 
 
 

8i hits infinite loop --Trace file hits 2.1G

Post by ykhogal » Sun, 31 Dec 1899 09:00:00


Hi,

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.

Regards

"The Views expressed here are my own and not necessarily those of Oracle
Corporation"


> 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
> trace).

> 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.