Re: Question on Backup and Recovery Software comments.

From: John Higgins <JH33378_at_deere.com>
Date: Mon, 17 May 1999 20:06:32 -0500
Message-ID: <3740BD18.DCC52301@deere.com>

There remains the further question of consistency. Any table(s) rolled back to a prior point in time may be in-consistent with respect to the rest of the database. This doesn't depend on the method of rolling back; both the import from an old export or the import from a newly recovered export have this problem.

This means you may need to import or recover-import more tables than just the 'damaged' tables.

Another tool is a 'log-sniffer'. You can extract the redo and or undo needed for logical recovery. I have used Patrol's DB Log Master for Oracle. I understand Oracle 8i has a 'log sniffer' built in.

Jeremiah Wilton wrote:

> On Mon, 17 May 1999, Ed Stevens wrote:
> > Jeremiah Wilton <jeremiah_at_wolfenet.com> wrote:
> >
> > <snip>
> >
> > > Consider that in the event of a logical corruption or an "oops," a user
> > > could recover the database in a separate location or with a different SID
> > > from the running production system. The user could even recover only the
> > > tablespace with the problem segments, plus the rollback and system
> > > tablespaces, saving space over restoring the whole database. The problem
> > > segments could then be exported and imported into the running production
> > > system. That way the user gets both point-in-time transactional
> > > coherence, and the whole database doesn't need to be taken down for
> > > recovery.
> > >
> > Sounds dangerous to me. Suppose your travel agent books you into a certain
> > cabin on a cruise ship. Then someone at the cruise line's IT dept. corrupts
> > the reservations database. Using your off-line recovery there is a period of
> > time where your cabin is shown "available." In the mean time, another travel
> > agent sells me your cabin. Then the DBA completes the recovery. Next week, we
> > both show up at the pier with a confirmed reservation for the same cabin ...

>

> You are right. The suggestion of repairing logical corruptions with a
> physical backup is meant To show that is is possible to recover from a
> logical corruption with a physical backup, and comes with with some
> qualifications:

>

> - Such a recovery assumes that either
> A) The table has been dropped so no further transactions can have been
> made against it, or
> B) Access has been resticted to the segments that have been mangled by a
> user but not dropped, or
> C) You figure out which rows to restore from the recovered copy of the
> database based on your understanding of the data and the nature of
> the corruption.

>

> In any of these scenarios, a point-in-time restore and export is better
> than a 24 or 48-hour old export file, because you get all the transactions
> up to the time that the logical corruption occurred. The suggestion to use
> physical backups for this purpose is made in light of such an alternative.

>


> --


> Jeremiah Wilton      http://www.wolfenet.com/~jeremiah

Received on Mon May 17 1999 - 20:06:32 CDT