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

On May 5, 1:05 pm, tim2bo..._at_gmail.com wrote:
> On May 5, 1:05 pm, joel garry <joel-ga..._at_home.com> wrote:
>
>
>
>
>
> > 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_Indi...Hide quoted text -
>
> > - Show quoted text -
>
> Actually I did some research later on METALINK and it verifies what I
> said.
>
> Note:399276.1
>
> "Solution
> It is possible to open a database READ ONLY in the middle of recovery
> to check the data content
> before deciding to proceed with recovery but with certain
> restrictions:
>
> 1. Minimal recovery must be done before the database can be opened
> READ ONLY ie you must at least
> apply the log that was current at the time the backup ended and the
> database must be consistent.
> 2. Recovery must be done using the 'backup controlfile' option, even
> if the controlfile in use is
> actually the CURRENT controlfile otherwise the database will fail to
> open with :"-

Thanks for that, it makes sense now. controlfile_change# of v $database = checkpoint_change# of v$datafile_header (close gets no cigar, I think)

Looks like the O11 DBPITR makes it somewhat easier.

jg

--
@home.com is bogus.
http://catless.ncl.ac.uk/Risks/25.14.html#subj11