Re: [SOLVED] missing alert.log mystery (it's not what you think)

From: Charles Schultz <sacrophyte_at_gmail.com>
Date: Mon, 16 May 2011 19:33:23 -0500
Message-ID: <BANLkTim1aqM3GnpnJ=M-Jd4LEmMvjGnt3g_at_mail.gmail.com>



Right, I totally agree. The problem is when you create an alert.log in $ORACLE_HOME/dbs even though you have a valid alert.log elsewhere. Try it. :)

touch $ORACLE_HOME/dbs/alert_$ORACLE_SID.log

Magically, your real alert.log will no longer be updated. Worse, no matter how many times you bounce your database or reset diagnostic_dest or binary_dump_dest, you will not get a new alert.log. Fun stuff.

On Mon, May 16, 2011 at 19:09, Wolfgang Breitling <breitliw_at_centrexcc.com>wrote:

> $OH/dbs appears to be the default directory for objects where the target
> path is omitted. Viz "create spfile from pfile=..." and I have seen
> datafiles in $OH/dbs. Try
>
> create tablespace xyz datafile 'xyz01.dbf' size 10M;
>
> and see where the datafile ends up. For datafiles Oracle checks that the
> path, if one is specified, does exist and raises an error. Same when I tried
> to change diagnostic_dest to a non-existing destination.
>
> On 2011-05-16, at 1:50 PM, Charles Schultz wrote:
>
> Sorry about spamming everybody on this - I hope this will be my last email
> on this topic (at least to the List at large).
>
> It turns out that Oracle was finding an alert.log in $ORACLE_HOME/dbs. Once
> I deleted that logfile, Oracle was able to open and start writing to the
> real alert.log again. If you ask me, this is a really weird piece of logic
> in the code and I am following up with Oracle Support on that end.
>
> Here is what I believe led up to this strange twisted situation.
> On May 6th, the original alert_TEMDEV.log was bzipped and removed by a cron
> job. Usually we check to see if it is open by another process (ie, fuser),
> but somehow the stars must have been aligned or something. Anyway, we had an
> orphaned inode.
> On May 13th I attempted to change the diagnostic_dest. Unfortunately, my
> first attempt was to a directory that did not yet exist, so Oracle placed
> the alert_TEMDEV.log in $ORACLE_HOME/dbs. Every attempt afterwards to
> change diagnostic_dest appeared to not work because Oracle does this check
> for "./alert_TEMDEV.log" and found the file there. But never wrote to it.
>
> On Mon, May 16, 2011 at 14:06, Charles Schultz <sacrophyte_at_gmail.com>wrote:
>
>> Some here is something I found interesting - if I truss a sqlplus "alter
>> system" call in any other database, I get results like the following:
>>
>> 2801: access("./alert_TEMQA.log", F_OK) Err#2 ENOENT
>> 2801: access("/u01/app/oracle/local/bin/alert_TEMQA.log", F_OK) Err#2
>> ENOENT
>> 2801:
>> open("/u01/app/oracle/diag/rdbms/temqa/TEMQA/trace/alert_TEMQA.log",
>> O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE, 0660) = 11
>>
>> I would be curious if you all get the same thing. I used "truss -aefo
>> some_output_filename sqlplus / as sysdba" and did something like "alter
>> system set timed_statistics=TRUE;".
>>
>> I find it interesting that Oracle is always (always?) looking for
>> ./alert_$SID.log first. Where exactly is ./ ? Next it looks in another
>> directory defined in our PATH. Note how both attempts to access the
>> alert.log result in Err#2 ENOENT. However, in my bizarre example with TEMDEV
>> the first access does not produce an error, which implies that Oracle found
>> the file at ./ Is there some kind of logic in the code which says "if -e
>> ./alert.log then skip_everything_else"?
>>
>> --
>> Charles Schultz
>>
>
>
>
> --
> Charles Schultz
>
>
>

-- 
Charles Schultz

--
http://www.freelists.org/webpage/oracle-l
Received on Mon May 16 2011 - 19:33:23 CDT

Original text of this message