Failure when trying to open db with resetlogs after restore of hot backup

Question

Hello,
i know that ora-600 errors should be directed to oracle instead of here, but as i have no access to oracle support you may be able / willing to give me some hint anyway. here is what i tried to do:
1. Make a Hot Backup of an Oracle DB running on Win2003, Version 9.2.0.5
2. Trying to restore this backup on a new host, running WinXP, Oracle 9.2.0.5
I can create the new controlfile and do a recovery with the syntax
"recover database using backup controlfile until cancel"
However, after this i'm trying to open the DB with the following syntax:
"alter database open resetlogs"
This takes a few seconds, then the instance gets terminated, showing an ora-600 error in the alert.log (i guess its useless to show the specific ora-600 error here, or am i wrong at this point?)
now i'm wondering if the difference in the operating system could be the reason ? I also have to mention that the database files from the hot backup were transfered over a WAN line, could a damage to this files, happened during the transfer cause something like this ?

Answer 1

These are from Howard
When you re-create a controlfile using a script or command that says 'create controlfile...', that command will require you to spell out the path to all the datafiles and online redo logs. It is a simple matter for your server process to visit each of the files mentioned in the create controlfile and read the SCN stored in the datafile header. It can also read the online redo logs and read the latest checkpoint change number stored there.
If all those numbers agree, that is obviously the age to which the rest of the database had gotten before the controlfiles were lost, and it's OK to create the new controlfile with that agreed-upon SCN forced in to the controlfile as its new SCN. Therefore the entire database is consistent and the database can be opened without recovery.
This sort of thing is what happens when you close your database down nicely and then delete all controlfiles as part of a recovery demo on a training course!
If those numbers don't agree, then it doesn't really matter. Logically, the highest number found, whether that be in one or more of the datafiles or one of the online logs, must be the age the database had reached before disaster struck. Your server process then writes that highest number into the new controlfile as its new SCN, and therefore your new controlfile agrees with the age of the latest bit of your database. The bits which were found to have smaller SCNs than that are therefore obviously in need of recovery -and because your new controlfile knows the SCN at which recovery should stop, recovery can be performed without trouble.
When the datafiles are inconsistent the control file has the latest SCN on it and it tries to bring the entrire database consisent with respective to its SCN..if something does not matches it says it is consisten
SO the recovery is done mainly based on the Controlf file..but the term backup..assume we have binary backup or the created new controlfile will have the scn to bring the DB to consistent state
Message was edited by:
Maran Viswarayar