Re: Corrupted Redo Logs

On Sat, 15 Feb 2003 18:44:25 +0000, Kevin McDaniel wrote:

> I'm reading up on the Backup and Recovery study materials and it talks
> about clearing corrupted redo logs. Specifically, it states "If an
> online redo log file has been corrupted while the database is open,
> ALTER DATABASE CLEAR LOGFILE can be used to create or clear the files
> without the database needing to be shut down." That's cool, but I'm
> trying to understand how a DBA would KNOW that the file was corrupted,
> versus anything else. It mentions querying the v$logfile view and
> looking at the status column (INVALID=inaccessible, STALE=contents
> incomplete because file not filled, blank=in use). Does this mean
> that if I have a STALE member, I've got a corrupted file? How can I
> be certain the file is corrupted so that I can take appropriate
> action? Appreciate all serious replies in advance. Thanks.
>
> Kevin

The V$logfile and v$log views are notorious for reporting spurious information. Add a new log group, and the ARCHIVED column in v$logfile will report 'YES' even if you're not in archivelog mode, and your instance wouldn't know what ARCH was if it came up and hit it on the head with a croquet mallet.

Likewise, v$log reports STALE at all sorts of inappropriate occasions. You leanr to live with it. Other statuses are possible, too, for no apparent reason other than that the wind direction just changed.

So: to test whether a status reported in v$log is 'genuine' or spurious, do log switches... as many as are required to cyle through all your online logs. Three groups, 3 log switches. If the status goes away, you're fine. If it doesn't, you're not.

Also, don't forget the alert log and the trace files that lgwr will throw into background_dump_dest if it really encounters corruption.

Regards
HJR Received on Mon Feb 17 2003 - 04:56:29 CST