Re: Oracle 8i (8.1.7.0.1) + Redhat Linux 7.2 = Cannot create tablespace file > 2 gb

You're missing the small fact that (presumably) 10am is in the archive logs, just as 9am was. Had it been in the current logs, you'd be well and truly up a certain creek without a certain navigational and propulsional instrument.

You've been lucky. The general case remains: backup controlfiles and redo logs *if* you wish to be able to perform a perfect repeat of the recovery.

Regards
HJR "Sean M" <smckeown_at_earthlink.net> wrote in message news:3D1D4910.AA7E798F_at_earthlink.net...
> Addendum: Lest you think I'm being daft, I'll give you a concrete
> example. Take a backup of a database at noon Monday. Continue
> transactions until noon Tuesday. Decide you want the database restored
> to the way it looked at 9 a.m. Tuesday. Blow away EVERYTHING you have
> for the current database - control files, online redo logs, datafiles -
> everything. Restore your datafiles from Monday's backup. Recreate your
> controlfile. Now roll forward to 9 a.m. Open resetlogs, and voila,
> happy database (Oracle automatically creates your online redos). I
> think we're in agreement up to here.
>
> Oops! You really wanted to roll forward to 10 a.m. Tuesday you say?
> OK, blow everything away again - everything. Re-restore your datafiles
> from Monday's backup. Recreate your controlfile (again). Roll forward
> to 10 a.m. this time. Open resetlogs. There - I've just repeated a 2nd
> incomplete recovery with no controlfile or redo log backup after
> stuffing up my first attempt. What am I missing? I've done exactly
> this before, and it works just fine.
>
> Regards,
> Sean M
>
> Sean M wrote:
> >
> > "Howard J. Rogers" wrote:
> > >
> > > We were. Recover until time 10.00am, when you were told Scott dropped
the
> > > SALES table. Open resetlogs. Bugger me.... SALES is still missing.
> > >
> > > Now repeat the incomplete recovery.
> > >
> > > You can restore the datafiles, for sure. But your control file now
thinks
> > > its time 0. Your online redo logs think likewise.
> > >
> > > IE, before the recovery, you had:
> > >
> > > Control: time M
> > > Datafiles: time M
> > > Online Redo : time M
> > >
> > > Restore the datafiles:
> > >
> > > Control: M
> > > Datafiles: F
> > > Online Redo : M
> > >
> > > Perform Recovery:
> > >
> > > Control : M
> > > Datafiles : L
> > > Online Redo : M
> > >
> > > Open resetlogs:
> > >
> > > Control : A
> > > Datafiles : A
> > > Online Redo: A
> > >
> > > Now repeatr the recovery....
> > >
> > > Control A
> > > Datafiles F
> > > Online redo A.
> > >
> > > Your control file and redo logs are from a time *before* the
datafiles.
> > > Rather worse, they are from a completely different incarnation of the
> > > database. You won't be able to repeat the recovery.
> >
> > Sure you can... just recreate the controlfile and delete the online redo
> > logs. Re-restore your datafiles, and you're off and running again.
> >
> > > However, if you've backed up the original control files and redo logs
first,
> > > then given:
> > >
> > > Control: A
> > > Datafiles: A
> > > Online Redo : A
> > >
> > > You can restore the precautionary backup, to give this:
> > >
> > > Control : M
> > > Datafiles: A
> > > Online Redo : M
> > >
> > > Now re-restore the datafiles:
> > >
> > > Control : M
> > > Datafiles: F
> > > Online Redo : M
> > >
> > > And "M-F-M" is the state we were in to perform the initial recovery.
So now
> > > you can recover until time "K".
> > >
> > > Without being able to restore the initial control files or online redo
logs,
> > > you cannot repeat an incomplete recovery if it proves that the first
attempt
> > > sailed straight past the dodgy redo.
> >
> > That's not correct. First of all you can just throw away your online
> > redo logs if you're doing an incomplete recovery - they're worthless
> > since they contain information newer than the point to which you're
> > recovering. So the online redo part of your argument doesn't stand up.
> > As for the controlfile, just recreate it like I said in my last post.
> >
> > > > Sure there is! Just re-restore your backup, and start again. Might
> > > > cost you some time if the DB is big, but certainly possible.
> > >
> > > You can't do that.
> >
> > Sure I can, and I have more than once!
> >
> > > If you restore the datafiles from the "proper" backup,
> > > you are stuck with a control file and online logs from a new
incarnation.
> >
> > So what? Blow 'em away, recreate the controlfile, and I'm fine.
> >
> > > If
> > > you restore *everything* from the previous backup, you've possibly
lost
> > > transactions in the current log you wanted to re-perform.
> >
> > Transactions in the current log? We're talking incomplete recovery here
> > - we never get to the online redos. Why do we need them? Delete them,
> > and let the next open resetlogs re-recreate them.
> >
> > > 'Fraid the manuals are unambiguous on the subject, as be me: if you
don't
> > > take a precautionary backup of your control files and online logs
before
> > > beginning an incomplete recovery, you cannot repeat said recovery when
you
> > > find that it didn't bring back what you wanted it to.
> >
> > I totally disagree - UNLESS you're talking about an incomplete recovery
> > to an extremely recent point in time, so recent that there is still data
> > in the online redos that you're rolling forward onto. But I was pretty
> > sure we were talking about rolling back in time a few hours/days/weeks,
> > where we only apply *archived* redo to catch up. But in general, for an
> > incomplete recovery, Oracle never even reads the online redo logs, so it
> > will never complain that they're from a different time or incarnation.
> >
> > Regards,
> > Sean
Received on Sat Jun 29 2002 - 00:56:29 CDT