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

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

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

> 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 Fri Jun 28 2002 - 23:55:12 CDT