>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 >>> [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).