DBA WARNING - Recovery doc errors

A warning to all DBA's who plan on using archive logging to recover from user errors.

The procedure documented in the Administrator's Guide (p 19-36) "Recovery From User Errors" is not possible.

Problem: A user deletes a few thousand rows from a table that other

         users share.  You can't just restore the table for one 
         at the expense of the rest.  You need a seperate copy to
         restore so you can pull the rows and insert them into the
         production table.

Briefly, the procedure instructs you to start up a temporary instance of your production database using backup files. To do this without trashing your current production database, you need to rename the files. In order to open the temporary instance on the same machine you need to rename the database. Both of these are accomplished with the CREATE CONTROLFILE command documented on page 6-5. Here the documentation shows a command to create a controlfile with a new database name and the option NORESETLOGS, necessary for archive log recovery.

Well... this produces ORA-01223:
RESETLOGS must be specified to set a new database name.

A call to the hotline confirmed this. Unless you have a second machine to restore to, or can shut down your production instance for the recovery period (don't forget to move all your produciton files first) this is not an option. Even this might not work if you have to rename the datafiles, as the new controlfile probably doesn't know the "current" logfile number.

I have submitted an enhancement request to have the product match the documentation.
The best way to guard against user error is still to make periodic exports.

Page 19-2 says "You should test your backup and recovery strategies in a test environment before you move to a production system" Good idea.

-- 
Regards
David Jordan   jordan_at_eeood.pto.ford.com