Re: Recover database calls for backup pieces far earlier than the level 0 backup

  • From: Gus Spier <gus.spier@xxxxxxxxx>
  • To: oracle-l <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 3 Sep 2014 21:51:53 -0400

And before anybody asks ...

OS: RHEL 5.6

On Wed, Sep 3, 2014 at 9:48 PM, Gus Spier <gus.spier@xxxxxxxxx> wrote:

> Hi guys!
> Production database became unusable when  rows in certain key tables
> "disappeared". The cause of that is still under investigation.  DBAs and
> application analysts determine the point in time just before this event
> occurred.
> Backups are on hand for AUGUST 31 (Level 0), SEPTEMBER 1(Level 1), and
> SEPTEMBER 2 (Level 1).   Archived redo logs are on hand
> DBA team datapump the database in its current state to preserve the "crime
> scene" and elect to perform database point-in-time-recovery.  The restore
> portion of this procedure appears to complete without complication.
> When it comes time to recover the database, RMAN lists the backup pieces
> it needs to recover the database.  The list includes backup piecdes,
> archived redo logs, gong back as far as January 31, 2013!!  Does anyone
> have a clue why RMAN might act that way?  We had expected that the latest
> INC 0, INC1, and archived redo logs would have sufficed to recover the
> database.
> Any clues would be appreciated.
> Thanks,
> Gus

Other related posts: