[RESOLVED]: More issues with alert.log

From: Charles Schultz <sacrophyte_at_gmail.com>
Date: Fri, 3 Jun 2011 08:30:44 -0500
Message-ID: <BANLkTik4RN6cJ7aVv=VZvwA_wkxzrED3=w_at_mail.gmail.com>

Finally got to the bottom of this.

We had been using DCD (Dead Connection Detection) in 10g. When we upgraded to, we apparently hit an old bug that has resurfaced (Bugs 6918493, 3934729) (see mythology of the Hyrda<http://en.wikipedia.org/wiki/Lernaean_Hydra>). Apparently the newly broken DCD was causing undead connections to write to $ORACLE_HOME/dbs/alert_$ORACLE_SID.log, thus bumping into the other new 11g bug.

As a workaround, we have disabled DCD (sqlnet.expire_time = 0).

I am still leaning on Oracle to come up with a way to backtrack this - I only got to the root of the issue by a series of coincidences and some opensnoop sniffing.

On Tue, May 31, 2011 at 10:02, Charles Schultz <sacrophyte_at_gmail.com> wrote:

> Good day, Listers,
> In light of the issue with $ORACLE_HOME/dbs/alert_$ORACLE_SID.log in 11g
> databases, I am curious about processes that write/create this file. So far,
> we have tracked it down to incoming LOCAL connections (using pfiles on
> alert_$ORACLE_SID.log with opensnoop) . However I am at a loss why
> an incoming connection would arbitrarily write
> to $ORACLE_HOME/dbs/alert_$ORACLE_SID.log instead of the one defined
> by diagnostic_dest.
> How would I determine exactly what is going on? I am not looking for
> guesses, but scientific ways to go about getting that information.
> To make matters worse, this seems like a very intermittent issue and not
> easily reproducible. We have seen the issue occur about once per day since
> upgrading to last week. We are also receiving frequent core
> dumps, why may be completely irrelevant - so far, I have not been able to
> reconcile a core dump to an alert-log-spawning connection.

Charles Schultz

Received on Fri Jun 03 2011 - 08:30:44 CDT

Original text of this message