Recovery of the most crucial element in Oracle database plays an important role. with the help of show parameter control_files we can find the default location of controlfile in our database. Being an Oracle DBA we must know that why do need oracle controlfile in any oracle. There are some main points which remind us to keep a backup of controlfile.

  • The database name
  • Names and locations of associated data files and redo log files
  • The timestamp of the database creation
  • The current log sequence number
  • Checkpoint information

With the help of this article, we are going to learn about the steps which are required to restore from a loss of all current control files to the default location.

The following scenario simulates a loss of all the control files and the restore process using a backup control file with any Recovery Catalog.

In this situation, you are only able to open your database in NOMOUNT mode. Also remember that when you lose all (or one) control files and restore them (or one of them) from a backup control file, you have to perform a recovery of your database and open it with the RESETLOGS option, even if any datafile is restored (like in this scenario).

That’s not always true when you’re dealing with “created” control file (I hope to simulate that scenario one day), as long as you must specify RESETLOGS if the online logs are lost or NORESETLOGS if the online logs are available.

Anyway, a control file restored from a backup has an SCN taken at that “remote” time, different compared with those currently available in the datafiles and redo logs and so they have to be resynchronized.
Generally speaking, having the instance in NOMOUNT mode means your control files are still not read (if available), so RMAN is not able to know how to find information about an “unidentified” database: DBID indeed is contained into the control file.
If you are using a flash recovery area or a recovery catalog (best practice’s solution) then you don’t have to set the DBID before executing the RESTORE command of your NOMOUNTED instance, saving time and avoiding extra manual steps always prone to error.

Let’s start. My instance is running

Suddenly all my control file are lost.

When trying to create a tablespace some errors are thrown:

The instance is crashed

As you can verify the mentioned (/home/oracle/app/oracle/oradata/orcl/control01.ctl) file doesn’t exist.

Let’s try to restore the missing control files, starting the instance in NOMOUNT mode:

Connect using RMAN and issue the RESTORE CONTROLFILE FROM AUTOBACKUP command. DBID is not set, but because I’m using the flash recovery area, RMAN is able to find a backup control file.

Let’s see if the instance is able to read our restored control files, bringing the database in MOUNT state:

What does it happen if I try to simply open the database ? It fails with a clear error.

As said at the beginning of this post when you restore a control file from a backup you have first to recover the database…

… and then open it with the RESETLOGS option.

The database is now open and control files are available again.

Once the update is done, Follow the same process of upgrading agents.

Thank you for giving your valuable time to read the above information.


For More Detail , You can join us follow:

LinkedIn Group: Oracle Cloud DBAAS

Facebook Page: OracleHelp

About The Author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.