Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: exp and archive available.... recover table

Re: exp and archive available.... recover table

From: joel garry <joel-garry_at_home.com>
Date: Thu, 12 Jul 2007 11:02:45 -0700
Message-ID: <1184263365.429431.85520@o61g2000hsh.googlegroups.com>


On Jul 11, 6:25 pm, DA Morgan <damor..._at_psoug.org> wrote:
> hpuxrac wrote:
> > On Jul 11, 5:41 pm, joel garry <joel-ga..._at_home.com> wrote:
> >> On Jul 11, 12:46 pm, "rogergor..._at_gmail.com" <rogergor..._at_gmail.com>
> >> wrote:
>
> >>> You should ideally be able to restore only a single datafile if that's
> >>> what's missing using RMAN, it's much faster than a full restore if the
> >>> DB is multi-GB in size.
> >> So how do you restore just a single table that is a small one of many
> >> in the datafile and hasn't had (or you want to get rid of the effects
> >> of) transactions since the export? While RMAN may be able to recover
> >> blocks and datafiles, in general the granularity is tablespace. So
> >> how many tables do you have, and how many of them are in their own
> >> tablespace? I tell ya, I do a lot of work where I'm just updating one
> >> or a few tables out of thousands, and being able to get those to a
> >> known state in a much larger database is one of my main uses for exp/
> >> imp these days. It's a backup and restore with table granularity (or
> >> smaller with the query option, used carefully). Not everyone is on
> >> 10g yet, flashback is just another feature.
>
> >> The real important point is that a DBA know when to use what and why.
> >> Depending on export for general production backup is undeniably bad.
> >> Export and cold backups is obsolete, yet one can justify it at a
> >> stretch (I think Alexander is in that situation). Daniel is saying
> >> how to do it right, my disagreement is that it is more important to
> >> come up with a proper SLA than to overgeneralize to the point where
> >> you are saying RMAN is a backup to the exclusion of everything else.
> >> The R in RMAN stands for recovery, and that is not the purpose of
> >> every backup.
>
> >> jg
> >> --
> >> @home.com is bogus.
> >> Sometimes it's good to be the "do-nothing."http://www.signonsandiego.com/uniontrib/20070711/news_1b11prgn.html
>
> > Anyone who doesn't think about the viability of a periodic export for
> > all their important databases as ( at least ) a complement to other
> > parts of their database recovery strategy just isn't thinking
> > correctly.
>
> > Joel is dead on here as he often is.
>
> No one is arguing against periodic exports. The argument is against
> exporting only and pretending that doing so constitutes having a
> backup.

It is a backup. The problem is in pretending that it is an appropriate backup.

> Can anyone come up with a single scenario where an export will do a
> better job than RMAN and Flashback?

I think Steve and I have, Flashback has its limitations.

> I'm willing to agree that the purpose of every backup is not recovery.
> But will you agree that not having a proper backup precludes recovery?

Agree. I even think it is appropriate to laugh at people who come here and expect to recover without a proper backup. But we should be nice to newbies, anyways.

jg

--
@home.com is bogus.
I'm not dead yet.  But not so sure about my bike:
http://www.flickr.com/photo_zoom.gne?id=787147239&size=o
Received on Thu Jul 12 2007 - 13:02:45 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US