RE: Recovery database with RMAN after resetlogs
- From: "Ruth Gramolini" <rgramolini@xxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 25 Feb 2004 14:36:17 -0500
In 9.2.0.4 it is relatively simple to reset the incarnation if you are using
a recovery catalog. This is one reason I went back to using a recovery
catalog after taking OWS' advice and going nocatalog at first. They said
the catalog will be going away, however it still exists therefore there must
be a reason for using it. I try to avoid the bleeding edge whenever
possible.
But even in nocatalog, it can be done. It is just a bit tricky. I have done
it in 8.0.6.2 and 9.2.0.4 twice: once after advice from OWS on a simple
question caused my migration database to be completely hosed after we had
moved the OS to 64 bit and 8.0.6.3 wouldn't run on 64 bit and again when
someone forgot to put backups to tape when I was out one day and we had to
go back several days with missing archivelogs. Most of the support analysts
will say that the package is not for end users and then send you the paper
and expect you to do it on your own. I can now!
OF course, backup after recovery is still the best way to handle things, but
that is what testing is for. What if you have a crash before you can
backup?
Regards,
Ruth
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Mladen Gogala
Sent: Wednesday, February 25, 2004 1:35 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Recovery database with RMAN after resetlogs
Well, recovery after resetlogs is a complex issue. For one DBID changes
after resetlogs and you end up with a different database. It would require
playing around with set dbid=.....
Common wisdom says that there is no recovery after resetlogs, and
that is,
of course, false, but recovery after resetlogs is something I've
been taking
all precautions against and I've never done it. One doesn't want
to perform
"alter database open resetlogs" automatically unless he or she is
300% certain
that the operation will succeed. Of course, the first thing to do
after resetlogs
is - backup.
On 02/25/2004 01:20:30 PM, Ruth Gramolini wrote:
> Are you using a catalog? If you are, you can set the
incarnation back to
> the original incarnation and restgore and recover until time or
until scn.
> If not, you will have to do a manual recovery using the plsql package
> sys.dbma_backup_restore. This package is not really meant for
users, so if
> you have support call them and have them help you. If not, let
me know and
> I will try to find the paper which explains how to use it. You
will have to
> recover the controlfile and datafiles separately. It is a
pain, but I have
> done it.
>
> Good luck,
> Ruth
>
>
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Skurský Michal
> Sent: Tuesday, February 24, 2004 12:05 PM
> To: Oracle-L Freelists
> Subject: Recovery database with RMAN after resetlogs
>
>
> Hello,
> I am testing my recovery scenario.
> I completed first step of RMAN online backup and incomlete
> recovery with resetlogs without problems.
> But in second step I am in trouble:
> - after reseting recovery catalog and switch to next incarnation
> I am proceeding with RMAN online backup
> - then I try to recover from these online backups (after
> incomlete recovery with resetlogs)
> - restore database is OK
> - recover database using backup controlfile until change
> (resetlogs_change#-1) is also OK for all archived logs
> - alter database open resetlogs reports error ORA-1113 and
> ORA-1110 - system01.dbf needs data recovery or
> ORA-1152 and
> ORA-1110 - system01.dbf was not recovered from sufficient old
> backup (sorry -I am translating error messages from Czech)
>
> I know I should do full cold backup after incomlete recovery but
> there is no way how to recover from online backups?
> Or am I missing something?
> Thanks
> Michal
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
