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

From: Gus Spier <gus.spier_at_gmail.com>
Date: Wed, 3 Sep 2014 21:51:53 -0400
Message-ID: <CAG8xnicoyX8QjnKU7erWvSQVDEQv_R+d3O2yWbsr3fmjtTnVgw_at_mail.gmail.com>



And before anybody asks ...

OS: RHEL 5.6
Oracle 10.2.0.4

On Wed, Sep 3, 2014 at 9:48 PM, Gus Spier <gus.spier_at_gmail.com> 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
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Sep 04 2014 - 03:51:53 CEST

Original text of this message