Re: DBPITR and ORA-16005 Error: database requires recovery.

On May 5, 7:25 am, tim2bo..._at_gmail.com wrote:
> On May 5, 4:00 am, "gba..._at_ravenpack.com" <gba..._at_ravenpack.com>
> wrote:
>
>
>
>
>
> > > Where have you read you can open the database in READONLY mode without
> > > any resetlogs in this situation?
>
> > Oracle® Database Backup and Recovery Basics:http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/toc.htm
>
> > Sections 7.6.4 and 7.6.5.
>
> >  7.6.4 Database Point-in-Time Recovery Within the Current Incarnation.
>
> > "If the operation completes without errors, then your DBPITR has
> > succeeded. You can open the database read-only and perform queries as
> > needed to ensure that the effects of the logical corruption have been
> > reversed. If not, you may have chosen the wrong target SCN."
>
> > 7.6.5 Options After Database Point-in-Time Recovery.
>
> > "After a successful DBPITR, your choices are:
>
> >     *  Export one or more objects from your database using an Oracle
> > export utility such as Data Pump Export. You can then recover the
> > database to the current point in time and re-import the exported
> > objects, as a way to return these objects to their state prior to the
> > unwanted change without abandoning all other changes.
> >     *   Open your database for read-write, abandoning all changes
> > after the target SCN. In such a case, you must open the database with
> > the RESETLOGS option, as shown here:
> >       RMAN> ALTER DATABASE OPEN RESETLOGS; "
>
> I am not sure where your system stands at current.  It would seem to
> me that you followed the instructions perfectly as described in the
> Database Backup and Recovery Basics.
>
> A few things to check.
> 1)  Before you can do ALTER DATABASE OPEN READ ONLY, your database
> needs to be in a mounted state.
> 2)  Have you tried to do ALTER DATABASE OPEN READ ONLY from a sql
> prompt and not from within RMAN (I know it sounds crazy but I have
> seen stranger things work.)
>
> Lastly I don't think the documentation is correct.  I really believe
> that you have to tell it to restore using a backup controlfile (even
> if it is the "current" controlfile) RECOVER DATABASE USING BACKUP
> CONTROLFILE.  If you are using "RECOVER DATABASE" then RMAN is
> expecting the end of recovery marker.  Well if you are doing a point
> in time recovery then you are doing and "incomplete" recovery and
> therefore it can not reach the recovery marker.  I may be wrong but
> that is my view point.
>
> Regards
> Tim-

Like David, I'm also flying blind here, but I'm not so sure the docs are wrong, as they do specifically state using the current controlfile. I'm guessing the OP's problem comes from using the current SCN, he needs to try an older one. There must be some conceptual fuzziness required, henc the docs say "...you may have chosen the wrong target SCN. In such a case, investigate the unwanted change further and determine a new target SCN, then repeat the DBPITR process." Makes me wonder if there are various system-related SCN's that get posted, which are kind of iffy in the sense of being a complete transaction in the sense we are used to. I know how weird that sounds and don't even want to speculate on what I mean.

Maybe one of the authors of books on RMAN might be the one to ask.

jg

--
@home.com is bogus.
http://timesofindia.indiatimes.com/China_mounts_cyber_attacks_on_Indian_sites/articleshow/3010288.cms