My consultancy makes a business of helping clients recover from these types of failures. A number of points this post need clarification, including version and platform. In short, if all you have is a redo corruption that caused instance termination, you should be able to recover almost completely using tried and true techniques. The lack of details such as errors in this post make it impossible to determine the correct course of action in your case.
worse, by openning resetlogs (likely without saving the original stuff) you'll end up with the added fun of trying to figure out which scn was the old scn XXXX.xxxxxxxx vs. the new (post reset) SCN XXXX.xxxxxxxx which can make analysis a real bear. I'm assuming that there is/was no standby, if there were it would likely be thinking 3020 at some point in time soon.
I'm in agreement that you should be able to sort things out, particularly with oracle's help in demangling the redo stream and recovering to something approaching (or achieving) a consistent database. by performing a reset logs you really close the door on a lot of options.
as for platform, I'll hazard we're talking x86-32/windows something or another few people bother to run antivirus stuff on anything else.
For starters: do you have a copy of the database in its "pristine" and totallyl screwed up but not reset state?
-- craig -- //www.freelists.org/webpage/oracle-l
