Comments below.
HJR
--
----------------------------------------------
Resources for Oracle: http://www.hjrdba.com
===============================
"godmann" <allanwtham_at_yahoo.com> wrote in message
news:95cd51c.0203031846.1e1b16c4_at_posting.google.com...
> Howard,
>
> For inactive, I find that clearing the logs is easier than drop and
> create a new log groups.
>
As I said, fair enough. Personally, I know the 'add' and 'drop' syntax off
the top of my head, and having to learn another seems a waste of time... but
it's there for a reason, and you stick with what you're happier with.
> For active, if it is already archived, I still think leaving a gap/hole
is
> not good.
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). And
all that then implies is that there's a hole in the redo stream. Which of
course is not good -so a new backup is, as I said, 'prudent'. So, not
*necessarily* a recovery, but you'd be mad not to do a new backup.
>I normally try to issue a checkpoint and clear the log. If it is
> impossible, I do an incomplete recovery. Am I on the right track?
>
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.
> I am a little blurr with active(archived) and active(not yet archived)
> cases!
>
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.
Yet the log remains active until *both* events report successful completion.
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.
Regards
HJR
> Allan W. Tham
> Oracle DBA
Received on Sun Mar 03 2002 - 22:04:56 CST
