Originally posted by alapps Recovery of the "system.dbf" without a backup is doubtful... However, attempt of "Force" open the database (This works with bad datafiles, system is questionable...)
STARTUP FORCE has nothing to do with starting the database with bad datafiles. It starts the database just like normal STARTUP command, so if STARTUP returns errors about corrupted datafiles, so will STARTUP FORCE.
STARTUP FORCE is nothing but the following two commands merged into one:
Jurij Modic ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
If you do have something with the system tablespace (or any other tablespaces) that you need to get then do this:
edit the init.ora file and add the following line:
Startup the database. It will open. Doublecheck on metalink for the specific syntax but I think that is it.
One BIG caveat: only use this to open the database so you can export data that you need for you to be able to rebuild the database. Oracle WILL NOT support you and your database if you use this to open the database for production use.
Oh yes one more thing: please consider a backup strategy. It will make things easier for you. Take it from experience.
Just do one thing though:
Ora 1115 indicates that the file is not accessable. That the device may be offline. Make sure the file system is mounted and available to the oracle user. I had the unix guys work on disk once and mounted them but with root access available and not with oracle access. So double check that first.
I tried your solution . It is not working for me ..I simulated the problem on my test box . I renamed the system1.dbf to temp.dbf and tried to startup with _allow_resetlogs_corruption=true entry in init.ora ..
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: 'D:\KELLER\KELLER\SYSTEM01.DBF'