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

  • From: Charles Schultz <sacrophyte@xxxxxxxxx>
  • To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>, Wolfgang Breitling <breitliw@xxxxxxxxxxxxx>
  • Date: Sun, 15 May 2011 13:47:17 -0500

Actually, what bothers me most is that even if I change diagnostic_dest,
there is absolutely not alert.log whatsoever. There is the log.xml file in
the alert directory, and there are process trace files in the trace
directory, but no alert.log in the new structure. Why?!?

On Sun, May 15, 2011 at 13:37, Charles Schultz <sacrophyte@xxxxxxxxx> wrote:

> Wolfgang,
> *grin* The mount holding the diag directory structure is not full, nor has
> it been for some time. I have indeed checked elsewhere for the alert.log. In
> fact, I even did a massive 'find /u01 -type f -exec grep -iln <unique redo
> log name> {} \;', and that did not show me any suspect files.
> To others that asked questions privately, the ownership/permissions of the
> files and directories have not changed to my knowledge. Other alert.logs in
> the same diag directory hierarchy (obviously under their own $SID) are
> active and updated by the respective databases. The trace directory in
> question is constantly updated with other trace files (ie, background
> process traces, user traces) - just not the alert.log.
> Of course, the analyst handling my SR ("SR 3-3591317751: missing alert.log"
> for those that can/like to look at such things) went off-shift sometime
> Friday, so I have no updates from that direction. I am cross-posting this
> question to the Oracle Communities (sorry for those that read this twice)
> but no hits there, yet.
> My biggest fear is that I am totally missing the most obvious thing (ie,
> fat-fingering the name of the alert.log I am looking at *grin*), but I feel
> pretty confident I double- (and triple-) checked most stupid mistakes. But
> one never knows....
> On Sun, May 15, 2011 at 09:37, Wolfgang Breitling 
> <breitliw@xxxxxxxxxxxxx>wrote:
>> Any chance that the file system where the trace is is full? As you already
>> changed the diag dest this is not very probable. Other slight possibility:
>> have you checked elsewhere for the alert log, somewhere underneath
>> On 2011-05-15, at 7:22 AM, Charles Schultz wrote:
>> > Good day, listers,
>> >
>> > Environment: Oracle EE on Solaris 10
>> >
>> > I know, the first thing that comes to mind "Oh yeah, the
>> binary_dump_destination is overridden by diag_destination in 11g". That's
>> not the problem here.
>> > The next thing you think "Well, it could be an orphaned inode (ie,
>> deleting a file that is open by another process)". That is also not the
>> problem.
>> >
>> > We have an alert.log that was last updated by the database on May 6th.
>> Strangely enough, the log.xml in the alert directory of the diag destination
>> is being updated normally, it is just the plain text alert.log in the trace
>> directory that is not updated. We have bounced the database, changed the
>> diag_destination parameter and I have even grepped all the file descriptors
>> in /proc/*/fd for traces of a possibly opened alert.log - nothing, the
>> alert.log is still not being updated. I tried dbms_system.ksdwrt to force a
>> write to the alert.log - again, the log.xml is updated, the plain text is
>> not. My last resort was to file a case with Oracle Support, and they are
>> having me redo everything I have already done, even though I stated up front
>> that I did all these things already (see above).
>> >
>> > So now I have a mystery. I could pull out the Microsoft solution and
>> bounce the entire host. But the curiosity inside me wants to figure out what
>> is going on before I do that. What could possibly explain why the alert.log
>> is not being written to? It looks, smells and feels like there is an
>> underscore parameter that prevents writing to the alert.log. But Oracle
>> Support is telling me no such parameter exists (and I have not found one).
>> >
>> > Any thoughts from this collective of intelligence? :)
>> >
>> > --
>> > Charles Schultz
> --
> Charles Schultz

Charles Schultz

Other related posts: