Restore Control Files

Using Arcserve UDP Agent (Linux) › How to Restore an Oracle Database Using Arcserve UDP Agent (Linux) › Perform Granular Recovery of an Oracle Database › Restore Control Files

Restore Control Files

If database control files are lost or corrupted, you can restore it by performing a File-Level Recovery. After the file-level recovery is successful, you have to manually recover the control files.

Follow these steps:

Log in to the target machine as a root user.
Shut down the Oracle instance.
```
SQL>shutdown abort
```
Start the database in the nomount state.
```
SQL>startup nomount
```

List the path for all control files.

SQL> show parameter control_files;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /opt/oracle/oradata/lynx/control01.ctl, /opt/oracle/flash_recovery_area/lynx/control02.ctl

Restore the control files using the Restore Wizard. For more information on the restore process, see How to Perform a File-Level Recovery on Linux Nodes.
Specify the following information on the Restore Wizard and submit the job:
1. When you select the files and folders, enter the required name of the control file and search. Repeat this step until all the control files are selected.
  Example: Enter "control01.ctl " and search.
2. On the Target Machine page, provide the following information:
  - Select Restore to original location.
  - Enter the hostname or IP address of the target Oracle Server.
  - Enter the root user name and the password of the target Oracle Server.
  - Select Overwrite existing files for the Resolving Conflicts option.
After all the control files are restored, mount the database and open it.
```
$sqlplus / as sysdba
SQL>alter database mount;
```
Recover the database with the RECOVER command and add the USING BACKUP CONTROLFILE clause.
```
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE
```

Apply the prompted archived logs.

Note: If the required archived log is missing, then it implies that a necessary redo record is located in the online redo logs. It occurs because unarchived changes are located in the online logs when the instance failed. You can specify the full path of an online redo log file and press Enter (you may have to try this a few times until you find the correct log).

Example:

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE 
ORA-00279: change 1035184 generated at 05/27/2014 18:12:49 needed for thread 1
ORA-00289: suggestion :
/opt/oracle/flash_recovery_area/LYNX/archivelog/2014_05_27/o1_mf_1_6_%u_.arc
ORA-00280: change 1035184 for thread 1 is in sequence #6
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/opt/oracle/oradata/lynx/redo03.log
Log applied.
Media recovery complete.

Open the database with the RESETLOGS clause after completing the recovery process.
```
SQL>alter database open resetlogs;
```

The control files are successfully recovered.