This post about to restore from a loss of all current control files to a non-default location using autobackup. One of the many features included in RMAN is the ability to automatically backup your control file. It is very important for (some) recovery purposes to ensure you have a recent copy of your control file, especially if it contains your recovery catalog. There is one feature of control file autobackups which a lot of DBA’s seem to be unfamiliar with, which is why I thought i’d write up a brief article on it. If you have this feature enabled and you make a structural change to the database, the control file is automatically backed up. ie, If you add a datafile, rename a file, etc. Information which could affect your ability to recover. This backup will be placed on disk even if your regular backup goes to tape.

What happens when we configure autobackup on -If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically backs up the control file and the current server parameter file (if used to start up the database) in one of two circumstances: when a successful backup must be recorded in the RMAN repository, and when a structural change to the database affects the contents of the control file which therefore must be backed up

Like the previous scenario the following one simulates again a database losing all the control files, but they will be restored using the autobackup to a non-default location.
As already stated in the mentioned previous post when losing all current control files 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).
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 re-synchronized.
Generally speaking, having the instance in NOMOUNT mode means your control files are still not accessed (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.

The instance is not running.

Let’s simulate the loss of all current control files.

In my future non default location there still isn’t any file.

Connect through RMAN and…

… start the instance in nomount mode

Execute the following command to restore the autobackup control file copy to a different location compared to the originals.

After the execution of restore command you can find a control file under the specified location

Is it possible to mount the database ? No, of course.

You have to modify at least the control_files parameter and set the location of the new available control file.

Connect the instance with RMAN and start it in mount mode

Issue the recover command for the whole database…

…and, as already stated, open it with the RESETLOGS option.

Now if your original location becomes available again, you may want to configure the control_files parameter to the original value.

Close the instance…

…and copy the only available control file to the original locations.

Connect to the instance and start it once again.

The instance is available, the database is in OPEN mode and ready to be used with control_files parameter modified.

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