Re: RE : RMAN Repository

I have done it in 8.0.6.3 and one earlier version. As Robert says, it is a bit involved. I had help from Oracle Support when I had to do it.

Ruth
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Sunday, January 19, 2003 1:23 AM

> Indeed you can do this. It's a bit involved, but it's documented in my
> Oracle9i RMAN Backup and Recovery Book, and it is supported in 8i.
>
> RF
>
> -----Original Message-----
> Hostetter
> Sent: Friday, January 10, 2003 6:59 AM
> To: Multiple recipients of list ORACLE-L
>
>
> >But I don't anticipate having to recover from a prior "incarnation"
> >when I have a perfectly good backup from the last successful backup.
>
> I get requests from developers to "refresh" test databases from production
> backups that are 30 days old. This is for billing system software, where
> they need to test bill runs. Back when our cluster software was still
> buggy, this would occassionally require restoring from a previous
> incarnation, because the production database had been recovered with
> RESETLOGS. If I can do this in 8.1.7 without an RMAN respository, I'd
love
> to hear about it.
>
> Arup - I love the "leather interior tank" analogy!
>
>
>
> Jay Hostetter
> Oracle DBA
> D. & E. Communications
> Ephrata, PA USA
>
> >>> sorr_at_rightnow.com 01/09/03 06:19PM >>>
> Hey Brian,
>
> I only talk about the way it SHOULD be... not what I actually do. :-)
>
> I confess to presently using the suppository, er a repository but
anticipate
> just using control files after we upgrade to 9i with its enhanced RMAN
> features. I have a shell script with parameters and if it's a non-catalog
> backup I also backup the controlfiles. I don't anticipate problems with
> exceeding max files. I create a daily ASCII file with a listing of the all
> the database files. Not sure what else you're looking for.
>
> > Do you accept losing the backup history and cross fingers
> Huh??? I have CONTROL_FILE_RECORD_KEEP_TIME set to 7 or 14 days, I forget
> which. But I don't anticipate having to recover from a prior "incarnation"
> when I have a perfectly good backup from the last successful backup. I
once
> had to do a PITR to recover dropped tables that weren't noticed until 5
days
> later. To do this I created another database on another server, did the
PITR
> then restored the specific tables while all the other tables remained
> current. I was able to do this without a repository.
>
> I have some scripted recovery scenarios which I occasionally practice on a
> test machine. Hmmm... it's been a while and it's a new year so it's
probably
> a good time to review and test backup/recovery scenarios. Recover
scenarios
> should include something like the following: loss of a non-system,
> non-rollback segment datafile; loss of a rollback segment datafile; loss
of
> a system datafile; recovering a temporary tablespace; loss of 1 or all
> controlfiles; restoring archivelogs; a complete database restore; loss of
> inactive online redo log; loss of current online redo log; database server
> meltdown and recovery to a replacement server, PITR and tablespace PITR...
>
> Who said backup and recovery was boring? :-)
>
>
> Steve Orr
>
>
>
>
>
>
>
> **DISCLAIMER
> This e-mail message and any files transmitted with it are intended for the
> use of the individual or entity to which they are addressed and may
contain
> information that is privileged, proprietary and confidential. If you are
not
> the intended recipient, you may not use, copy or disclose to anyone the
> message or any information contained in the message. If you have received
> this communication in error, please notify the sender and delete this
e-mail
> message. The contents do not represent the opinion of D&E except to the
> extent that it relates to their official business.
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Jay Hostetter
> INET: jhostetter_at_decommunications.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Robert Freeman
> INET: robertgfreeman_at_yahoo.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Ruth Gramolini
  INET: rgramolini_at_tax.state.vt.us

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).