Backup and recovery of Control Files

When the control file backup and recovery instance is started, the process must read the control file and write the control file. Therefore, if a control file is damaged, the instance cannot be mounted. That is, the control files in this phase are indispensable. If the disk is damaged, it can only be started to the NOMOUNT state. Backup control file backups include: online control file image backup, manual backup, automatic backup online image backup is used in addition to the first control file (the initialization parameter control_files points to the first one) other control files are backup images. Automatic Backup: automatic backup is displayed. This type of backup is disabled by default. In RMAN, you can use the configure autobackup command to set the attribute to ON to enable this function. After oracle executes any backup operations in RMAN, The RMAN database in the control file is updated, and then the backup is automatically performed. The physical structure of the data block is also automatically backed up after the physical structure of the data block changes. Because the physical structure changes, ORACLE is automatically backed up and handed over to the MMON background process for delayed processing, while the MMON background process is handed over to its managed slave process (M000) for backup. To modify the delay interval (in seconds), modify the implicit parameter "_ controlfile_autobackup_delay ". Automatic Backup caused by changes in the physical structure can only use the default channel of the DISK type. The control file is also automatically backed up.

-- View automatic backup status RMAN> show controlfile autobackup; --- enable automatic backup RMAN> configure controlfile autobackup on; --- disable automatic backup RMAN> configure controlfile autobackup off; implicit automatic backup: when automatic backup is disabled, the control file is automatically backed up when the RMAN command is used to back up key data files. When you execute backup database and backup tablespace system, the control file is automatically backed up. However, ORACLE does not regard this as an automatic backup because the backup set is not in the autobackup directory of the quick recovery zone, but in the backupset directory. The backup name starts with "o1_mf_ncsnf _" and will be restored in the future, the steps for such backup and automatic backup are different. That is, manual backup recovery rather than Automatic Backup recovery. Manual backup can be divided into: Backup set, image copy backup, and reconstruction script backup set image copy backup the default path is quick recovery area, if the quick recovery area is not enabled, the path is $ oracle_home/dbs reconstruction script, which is written to the conventional Tracing file path. BACKUP set BACKUP: RMAN> backup as backupset current controlfile; image copy BACKUP: Both RMAN and SQL/PLUS can copy and back up the image of the control file. RMAN> backup as copy current controlfile format = 'path'; SQL> alter database backup controlfile to 'path'; reconstruction Script: SQL/PLUS can also generate a script file, it contains commands that can re-create control files. SQL> alter database backup controlfile to trace; ---- back up the control file as a text file SQL> ALTER DATABASE BACKUP CONTROLFILE TO 'path '; --- back up the control File as a binary File --- select value from v $ diag_info where name = 'default Trace file' by Default '; -- you can also check the initialization PARAMETER USER_DUMP_DEST to determine the path of the Tracing file. The SQL> SHOW PARAMETER USER_DUMP_DEST reconstruction script contains two CREATE CONTROLFILE commands without resetting logs (noresetlogs) and resetlogs ). Classified backup by time span: online image backup, structural backup, and historical backup online image backup, also known as online copy or current backup. That is, the control_files initialization parameter points to a healthy control file other than the corrupt control file. They understand the physical structure of the current database, know the latest checkpoint, the latest online log serial number, the latest SCN database SCN, the control file serial number, the control file SCN, the checkpoint information of each data file header, and the archived log. Structure backup: the physical structure information (data files and online redo logs) of the database in this backup is consistent with the current control file, however, the latest checkpoint, the latest redo log serial number, SCN, database SCN, control file serial number, control file SCN, check point set of each data file header, and archived log information are earlier than those in the current control file.. In short, if the structure of the database does not change after automatic or manual backup is generated, it is the structure backup. Historical backup: the physical structure of the database in the backup is inconsistent with that in the current control file. In short, if the physical structure of the database changes after automatic or manual backup is generated, they are historical backups. To restore the recovery control file, you must redo the log for help. Recovery includes restoring from backup and then restoring from redo logs. The restoration is performed in the NOMOUNT status. In most cases, online image backup, structure backup, and historical backup are considered in the recovery control file. In addition to image backup, other Backup Recovery control files are in the following sequence: 1. Restore control files from backup 2. Restore the database with the redo log media (also known: application log (apply log) 3. Open the database by resetting logs. Online image Backup recovery: 1. Execute startup nomount to bring the instance to the NOMOUNT state. 2. view the warning log and tracking log to check the damage details. 3. Use the operating system command to replace the damaged active state with a healthy online image backup. lost control file 4. Execute alter database mount to bring the instance to the mount status 5. Execute alter database open to open the database, recovery completed. Automatic Backup recovery: 1. Execute startup nomount to bring the instance to the nomount state. 2. Run restore controlfile from autobackup to restore the control file. 3. Run the mount database command to bring the instance to the mount state. 4. Run the recover database command to restore the database. 5. Run the alter database open resetlogs command to open the database, an extension of recovery completion: The recover database process is as follows: automatically explores unclear backup and archiving logs in the quick recovery area, and automatically finds the most current online log (that is, the online log that LGWR is writing when the instance is disabled, it indicates the end of the recovery process), determines whether the control file needs to be restored, and reads log information to restore part of the data file and control file information. Sometimes, the archive log is automatically restored from the archive log backup using the channel, so as to be used for recovery. The recover database Command differs from SQL/plus in RMAN: 1. SQL> RECOVER DATABASE --- used to restore all data files, only archive logs and online logs stored on the file system can be used. The premise is that the control file cannot be restored or rebuilt. 2. SQL> recover database using backup controlfile --- used to restore all data files and control files, only archive logs and online logs stored on the file system can be used. 3. RMAN> recover database; --- restore all data files and control files, in addition, you can use Incremental backup, archive in backup, and archive in the file system-logs, and online logs on the file system to automatically fix the following three situations: 1. There is no data file or tablespace information in the backup control file, but it actually exists. 2. There is no online log group information in the backup control file, but it actually exists. 3. the backup control file contains information about an online log group, but does not actually exist. Use the RESETLOGS command to open the database because the recover command can only repair the physical structure information of the database in the control file, but cannot modify the serial number of the current redo log in the control file. After the recover command is executed, the current online log serial number in the control file is still outdated. oralce uses the log resetting function, and the log serial number starts from 1 again. The resetlogs here is only used to take care of the restored control file. The resetlogs here is different from the resetlogs in Incomplete recovery. Manual Backup recovery: 1. Start the instance to the NOMOUNT status. 2. Locate the backup set. 3. Execute the restore controlfile from 'path' command to restore the control file. (If the from clause is used, the directory can be discarded) 4. Execute mount database to bring the instance to the mount status 5. Execute the recover database command to restore the database 6. Execute the alter database open resetlogs command to open the database and restore the database: 1. If the backup control file contains information about a database file or table space, but does not actually exist. Then: SQL> recover database using backup controlfile or recover database skip tablespace can be repaired. 2. There is no online log group information in the backup control file, but it actually exists. Then: SQL> recover database using backup controlfile command, and manually specify the path of the redo log to complete the recovery. Automatic Repair of inconsistencies: 1. There is no data file or tablespace information in the backup control file, but the actual situation exists. The automatic backup function of the control file is disabled. After the control file is backed up, a tablespace a is created, which is not included in the backup control file. In this way, the physical structure is inconsistent with the current one, backup becomes a historical backup. The restoration process is RMAN> startup nomount; restore controlfile from 'path'; --- that is, the historical backup path mount database; SQL> select name from v $ datafile; --- check whether the data files in the new tablespace exist (non-essential process) recover database; alter database open resetlogs; manually fix inconsistencies: the control file is automatically backed up and closed. After the control file is backed up, if a tablespace a is deleted, the tablespace and data file exist in the backup control file. When the control file is corrupted, the restoration process is RMAN> startup nomount; restore controlfile from 'path'; mount database; ----------- 11 SQL> SELECT * FROM DATAFILE; --- non-essential process (a tablespace and corresponding data files are found) SQL> alter database datafile 5 OFFLINE; SQL> recover database using backup controlfile; --- enter AUTO as prompted to continue. An error may occur (an archiving log cannot be found) -- if an error is reported that an archived log cannot be found, run recover SQL> recover database using backup controlfile again; -- enter AUTO to continue as prompted, and enter the path of the archived log. -- Until the data file is restored, check whether the SQL> SELECT * FROM V $ DATAFILE; ------------- 11 ---- 11 this process can use recover database skip tablespace a to replace RMAN> alter database open resetlogs; RESTORE when archive logs are missing 1. Execute startup nomount 2. Execute restore controlfile from autobackup | 'path '; 3. Run the recover database command and report an error. The system prompts that archive logs cannot be found. 4. Use the create controlfile command to recreate the control file. 5. Run the recover database Command. If an error is reported, the system prompts that archive logs cannot be found. 6. View V $ LOG view determines the LOG required in step 5 7. Execute recover d in SQL/PLUS Atabase using backup controlfile, etc. "Specify log"; after the prompt appears, give the correct online log Path until the command ends 8. Open the database in resetlogs mode. 9. Because no temporary data file information exists in the control file, you need to add it again to alter tablespace temp add tempfile 'patj' reuse; 10. Use the catalog and configure commands to add other lost information in the control file. Catalog db_recovery_file_dest; --- if you use restore catalog, you do not need to execute this process to view the maximum serial number of known archived logs. select max (SEQUENCE #) from v $ ARCHIVED_LOG; query the V $ LOG view and find that the control file needs to be restored from the number of logs. Select sequence # from v $ log wher status = 'current ';

 

Noresetlogs can open a database without the RESETLOGS keyword. The method is to re-create a new control file after the recover database is completed, and use the noresetlogs keyword in the created command. The main steps are as follows: 1. After the recover database is executed; 2. SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE; 3. Restart the instance TO the nomount status. Startup force nomount; 4. Use the create controlfile command of the noresetlogs version in the tracking file to create a new control file. After creation, the file automatically enters the MOUNT status. 5. Execute alter database open to OPEN the DATABASE, if an error is reported, execute recover database first and then open database 6 in alter DATABASE open. Because no temporary data file information exists in the control file, you need to re-add it to add a temporary tablespace. Alter tablespace temp add tempfile 'patj' reuse; 7. Use the catalog and configure commands to add other lost information in the control file. Catalog db_recovery_file_dest; --- if you use the restore catalog, you do not need to execute this process and use the configure command to reset the channel, backup retention policy, and other configuration information. Similarly, if you use the restore catalog, you do not need to execute this process.