Re: Question on Backup and Recovery Software comments.

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
  1. The table has been dropped so no further transactions can have been made against it, or
  2. Access has been resticted to the segments that have been mangled by a user but not dropped, or
  3. 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 - 12:52:11 CDT