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

From: Wolfgang Breitling <breitliw_at_centrexcc.com>
Date: Mon, 16 May 2011 18:09:28 -0600
Message-Id: <57695096-9A60-48AF-BEBE-C64AEFCB625F_at_centrexcc.com>



$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

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

Original text of this message