Re: [SOLVED] missing alert.log mystery (it's not what you think)
- From: Gus Spier <gus.spier@xxxxxxxxx>
- To: sacrophyte@xxxxxxxxx
- Date: Mon, 16 May 2011 22:04:30 -0400
Fascinating!
I'm terribly sorry you had to go through all of this, but I am
extraordinarily grateful for that handy little bit of knowledge.
Friendly regards,
Gus
On Mon, May 16, 2011 at 8:33 PM, Charles Schultz <sacrophyte@xxxxxxxxx>wrote:
> 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@xxxxxxxxxxxxx>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@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
>>
>>
>>
>
>
> --
> Charles Schultz
>
Other related posts:
