Re: lost of redo logs

"Howard J. Rogers" wrote:
>
> If it's archived, it won't be producing a hole in the redo stream, will it?
> The issue was whether recovery would be *required* because of the loss of an
> active log. The answer is no, it's not required, because an active log can
> be lost without crashing the database (difficult, but it can happen).

I assume you mean to say it won't crash the database assuming the database hasn't tried to access this (lost) redo log group yet? If a database tries to switch to a group that has lost all its members, the instance will crash immediately.

> No, I don't think so. If you can issue a checkpoint, there is no need to
> perform recovery at all. Clearly the database is still in a functional
> state, and the checkpoint presumably manages to flush everything to disk.
> Incomplete recoveries are horrendous affairs, rendering all prior backups
> and archives unusable, and inevitably losing data. Why you'd ever want to
> perform unless you absolutely needed to, I can't imagine.

We do it all the time. Anytime we clone a database, we take a hotbackup, do an incomplete recovery, recreate the controlfile with a new database name, and open resetlogs. Hardly a horrendous affair.

> Why? When a log switch occurs, that signals (1) DBWR to flush all buffers
> dirtied by the redo stream contained within the log just filled (ie, a check
> point event) and the CKPT process to stamp the header of the affected data
> files and (2) ARCH to take a copy of the log just filled. Two completely
> separate events, and both capable of finishing independently of each other.

Yes.

> Yet the log remains active until *both* events report successful completion.

No. An online redo can have a status of INACTIVE (i.e. no longer need for recovery, so the checkpoint has completed), but still not have been archived. This can easily happen in a number of scenarios, e.g. a full archive destination, or a database in NOARCHIVELOG mode.

> So you could have an active log that has long-since been archived, but a
> sluggish DBWR and/or CKPT are still chugging away doing their thing. Hence,
> active and archived. Or, DBWR and/or CKPT could do their stuff at
> lightening speed, but ARCH runs into trouble writing to the archive
> destination (by the far the more common scenario)... hence, active and
> unarchived. It's this last one where the loss of an active log would not
> *necessarily* require recovery... because the data files have received a new
> SCN from CKPT, those transactions don't need to be recovered using redo
> contained in the lost log.

Sorry? If a log is listed as ACTIVE, it is by definition still needed for instance recovery:

CURRENT
Indicates this is the current redo log. This implies that the redo log is active. The redo log could be open or closed.

ACTIVE
Indicates the log is active but is not the current log. It is needed for crash recovery. It may be in use for block recovery. It might or might not be archived.

INACTIVE
Indicates the log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived.

Regards,
Sean Received on Tue Mar 12 2002 - 22:49:24 CST