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

$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@xxxxxxxxx> 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

Other related posts: