Request Recovery Assistance 10gR2 Database on Solaris

Question

A colleague of mine inadvertently removed all of the Oracle Database binaries for a Solaris Oracle 10gR2 installation. All I have left are:
- all database datafiles
- all control file copies
- the online redo logs (redo01.log, redo02.log, redo03.log)
This is what I did in an attempt to recover:
1.] Reinstalled 10gR2 with the option to create a new database instance (with the same name as the old instance).
2.] Created a pfile from the spfile for the new instance. (now I have a pfile I can use during recovery of the old database)
3.] Shutdown the new instance
Now to try to recover the old database. . .
4.] Renamed the directory .../oradata to .../oradata/<SID>_TEMP  (to move all of the .dbf, .ctl, redo*.log files out of the way from the new instance created today)
5.] Renamed the directory containing the files I want to restore to ../oradata/<SID>
- This directory contains the .dbf's, .ctl files, and online redo logs from the instance I want to restore from.
6.] sqlplus / as sysdba
7.] startup mount;
ORACLE instance started.
SQL> recover database until cancel;
ORA-00279: change 53100530 generated at 02/19/2009 18:22:39 needed for thread 1
ORA-00289: suggestion :
+/usr3/app/oracle/product/10.2.0/Db_1/dbs/arch1_1876_602173188.dbf+
ORA-00280: change 53100530 for thread 1 is in sequence #1876
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1:
+'/usr3/app/oracle/product/10.2.0/oradata/TSDS/system01.dbf'+
ORA-01112: media recovery not started
I was hoping to issue 'alter database open resetlogs;' next, but I guess I can't because I don't have the archived log file that is missing.
Did this approach not work because the database was not in a consistent state when it was inadvertently removed (I believe I've seen this approach work before)?
Is there anything else I can try to recover this database?

Answer 1

When was your last backup (and set of archived redo logs prior to the ones that were lost)? That is the safest/most supported point in time you can recover to, up to that backup plus whatever SCN you can get to in the arch logs. There is an unsupported (or do it with support's guidance) way of opening a corrupted database.
If this is a production database, you really need to be working with support.
In the corruption case:
In most of the allowwhatever parameters (_allow_resetlogs_corruption, allowread_only_corruption, corruptblocks_on_stuck_recovery, etc.), you're looking at rebuilding the database via export/import.
If you want to live dangerously, you could also use bbed to edit the datafiles and set the scns to what you need, still followed by export/import to get the data out safely.
You could also try recovering to an SCN before what's suggested in the output (53100530). If you have the redo logs, the startup process would perform the roll forward/roll back two-phase recovery because then your situation is really no different than an instance failure, and your startup would be normal once you've restored the files you need.
What happens when you issue startup by itself? That is likely where you should wind up - recovery from an instance failure (again, assuming your files are not corrupted or that you really do not need a missing archived redo log).