Re: Question about Archivemode

I'm going to do the test now, and I'll post back. So if I have to eat humble pie then, so be it.

But where I think you're wrong is that it is the discrepancy in the timestamps of the datafile headers that induces a media recovery, and the presence of transactions after the last checkpoint in the redo logs that induces instance recovery. Therefore, media recovery is perfectly possible even in a noarchivelog database, because even a noarchivelog database can find itself with out-of-synch datafile headers.

But I'll post back shortly.

Regards
HJR "Sean M" <smckeownNO_at_BACKSIESearthlink.net> wrote in message news:3D360194.D10E40F1_at_BACKSIESearthlink.net...
> "Howard J. Rogers" wrote:
> >
> > There is one scenario where, despite not being in archivelog mode, you
might
> > get away with a complete and perfect recovery: if the continuous stream
of
> > redo you require still happens to be sitting in the online logs. If you
have
> > 5 online redo log groups, which switch every half hour, then you have
2.5
> > hours of redo available to you. So if you backed up last night, opened
the
> > database at 9.00am, and the intruder swiped the system tablespace at
> > 11.00am, you're doomed. But if he swiped it at 9.45am, the redo required
to
> > recover the backup of the system datafile is still available in the
online
> > logs, so you could just restore that one file and do a recovery on it.
>
> Interesting... I'm not sure I agree, though I've never actually tested
> it, so please take what I'm about to say with a grain of salt. (I'm not
> talking about your timing thing - I saw your other post re: noon.) I'm
> talking about the ability to take a datafile from a cold backup of a
> noarchivelog database, insert it into the mix, and recover using only
> online redo (assuming, of course, that you haven't cycled through the
> onlines since the cold backup so you have an unbroken stream of redo
> available). The problem (at least, I suspect, but I don't have
> noarchivelog mode databases handy to test) is that although you have all
> the redo in online logs still available since the backup, Oracle only
> lets you do instance recovery (as opposed to media recovery) for a
> noarchivelog mode database. And during instance recovery, Oracle only
> applies redo since the last checkpoint to the datafile. Now, in your
> scenario, that datafile has likely been checkpointed more than once
> since you started up after the cold backup. So even though Oracle
> hasn't yet overwritten the redo generated since the startup, it's only
> smart enough to apply the redo since the last checkpoint. So if you
> replace a file with one who's checkpoint in its header doesn't match
> what the controlfile thinks it should be, I suspect Oracle would freak
> out during instance recovery. Oracle would look at the controlfile and
> say "cool, I need to apply changes since the last checkpoint at 11:30 to
> this guy". But the datafile's header says "but that's not right - my
> last checkpoint is actually from 9:00 a.m." Now, maybe if you recreated
> your controlfile so that the only info Oracle has to go on is the
> datafile header you could fake it out... hmm... I smell a test
> coming... Howard, do you have a noarchivelog test database handy?
>
> > Clearly, there's no guarantees, though, that the required redo would be
> > available. Only archivelog mode can make that guarantee.
>
> Definitely.
>
> Regards,
> Sean
Received on Wed Jul 17 2002 - 19:07:20 CDT