Recovering Critical Files

Recovering critical files would include control files

Recover/Re-create a controlfile

There a number of ways to recover a controlfile, restore of a backup (rman, user managed) or re-create the control. If you were to lose a controlfile while the database is up, just re-create it, no data should be lost.


sql> startup nomount; (as far as you go with a damaged controlfile)

rman> connect target / (because the db name is in the controlfile you must connect like this)
rman> set dbid 2615281366; (must be supplied)
rman> set controlfile autobackup format for device type to disk 's:\ora_backup\controlfile_%F'; (must point to where controlfile is)
rman> restore controlfile from autobackup;
rman> alter database mount; (must be run before starting the recovery)
rman> recover database;
rman> alter database open resetlogs; (explained later)

note: must use the set command within rman when you have lost a controlfile. set=memory, configure=controlfile.

Re-create the control file sql> alter database backup controlfile to trace; (file located in USER_DUMP_DEST)
c:\> edit the trace file and obtain the controlfile create part
sql> @c:\restore_controlfile.txt (file obtained from the above information obtained from the trace file)


The restlogs clause is required in most incomplete recovery to open the database. It resets the redo log sequence for the oracle database. For recovery through a resetlogs to work, it is vital that the names generated for the archive logs let oracle distinguish between logs produced by different incarnations. This is why you use the %r in the parameter log_archive_format, %r is the incarnation other wise archive logs could be written over.

After a resetlogs there will be a new database incarnation number and the log switch number will be reset. In previous version all old backups and archive logs would have been useless but not any more in Oracle 10g.