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

"Sean M" <smckeown_at_earthlink.net> wrote in message news:3D1D3D4E.BE759FD5_at_earthlink.net...
> "Howard J. Rogers" wrote:
> >
> > "Sean M" <smckeown_at_earthlink.net> wrote...
> > >
> > > I snipped plenty of good advice/description, all of which I agree
with.
> > > My only contribution to the above would be to not color incomplete
> > > recoveries in such a dark light. They certainly aren't your first
> > > choice usually, but they aren't the end of the world and, IMO, aren't
> > > much more awkward/difficult than a complete recovery. But that's more
> > > opinion than fact.
> >
> > You must be one of those rare souls that remembers to take a
preventative
> > backup of their control files and redo logs before starting. 'Cos
otherwise,
> > if the recovery doesn't manage to bring back what you hoped it would,
you're
> > stuffed.
>
> How so? I mean, what do I need redo logs for during an incomplete
> recovery (assuming you meant online redos)? If you meant offline redos
> (i.e. archive logs), why would I need to back them up before I start?
> And I can always just recreate a controlfile... no real need to back it
> up before I begin. Unless... were you talking about complete
> recoveries? In that case I agree, yes, backup everything before your
> start - but I thought we were talking about incomplete recoveries.

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.

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.
>
> > Then there's the little matter of "FILE 1 NEEDS MORE RECOVERY TO BE
> > CONSISTENT', meaning.... er. what the stuff did I restore, and why
didn't I
> > restore everything??? And so on.
> >
> > I can pull off an incomplete recovery 100% of the time I go to demo one
> > these days (but it wasn't always like that!!). They still give me the
> > eebie-jeebies, though: stuff it up, and there's no come-back.
>
> 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. If you restore the datafiles from the "proper" backup, you are stuck with a control file and online logs from a new incarnation. If you restore *everything* from the previous backup, you've possibly lost transactions in the current log you wanted to re-perform.

'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.

Regards
HJR
> > On the other hand, I agree with you: if you follow standard procedures,
> > religiously, then there's nothing intrinsically so awful about them as
to
> > make you want to chop your head off.
> >
> > In truth, their awfulness comes from the fact that the database MUST be
down
> > for the duration, and they are therefore very expensive in terms of
> > concurrent access to data. I suppose it's a minor inconsequential matter
> > that they happen, also, to result in the loss of perfectly good data!
>
> True enough.
>
> > At the end of the day, though, I know what you are saying, and agree
with
> > it.
>
> Yes, I think we're in violent agreement once again. ;)
>
> Regards,
> Sean M
Received on Sat Jun 29 2002 - 00:17:07 CDT