[Translated from mos] Things should be considered before the control file is rebuilt
Considerations before rebuilding Control Files
Source:
Things to Consider Before Recreating the Controlfile (Document ID 1475632.1)
Applicable:
Oracle Database-Enterprise Edition-Version 10.2.0.1 and later
Information in this document applies to any platform.
Purpose:
Highlight the importance of control files and issues that should be taken into account before rebuilding control files.
Steps to solve the problem:
Before recreating the control file:
Control files are very important for databases. Some information is stored only in control files, not in data dictionaries.
Metadata includes the flash log, block change tracking, Rman backup, and data file location.
There are often workarounds or solutions, and the control files do not need to be rebuilt at all.
If you have to recreate the control file or Oracle instructs you to do so, consider the following:
1. Inaccessible/offlined datafile
If all the datafiles at the beginning are not on disk, you cannot recreate controlfile.
If datafiles is on disk, ensure that there is no offline datafile.
select distinct(status) from v$datafile where status not in ('ONLINE','SYSTEM');select name, ts#, online$, contents$ from ts$ where online$ =2;Otherwise, once the control file is rebuilt using resetlogs, all offline datafiles cannot be added back to the database.
You will encounter the following errors:
RMAN> sql 'alter database datafile 6 online';sql statement: alter database datafile 6 onlineRMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03009: failure of sql command on default channel at 07/29/2012 11:07:07RMAN-11003: failure during parse/execution of SQL statement: alter database datafile 6 onlineORA-01190: control file or data file 6 is from before the last RESETLOGSORA-01110: data file 6: '/opt/app/oracle/oradata/ORA112/leng_ts.dbf'
2. flash back to database
After a control file is rebuilt, all the flashback information-normal restore point, guaranteed restore point, and flashback database will be closed, that is, it will be created using NORESETLOGS.
Flash logs on all disks cannot be returned to the control file by catelog. If you try catalog flashback log, you will encounter the following error:
File Name: /opt/app/oracle/fra/ORA112/flashback/o1_mf_85zttw61_.flb RMAN-07529: Reason: catalog is not supported for this file type
You will have to re-enable flashback database. All old flash logs will no longer be useful and need to be manually removed from the disk.
3. Flash Recovery Area usage
Once the control file is rebuilt, the v $ flash_recovery_area_usage view may not reflect the actual usage. Therefore, you need to run the following command to retrieve all the items in the catalog control file.
RMAN> catalog recovery area;
4. Backup metadata
If you do not use the recovery directory of rman, You need to import all backuppiece catalog into the control file. Furthermore, before 9i, we cannot catalog backuppiece
Control files are extremely important for backup and recovery. All the backuppiece of catalog is correct in the control file, but you must first have a control file.
If you lose all syatem and only backuppiece is available, you must have at least one controlfile to catalog backuppiece.
Furthermore, if there is no datafile on the disk, you cannot recreate the controlfile.
Back up Current controlfile
RMAN> backup current controlfile;SYS> alter database backup controlfile to '/tmp/control01.bk';
Before recreating the control file, you must back up at least one current control file.
In open/mounted mode:
When the database has been shut down, use the operating system command for backup, for example:
[email protected]> show parameter control_filesNAME TYPE VALUE------------------------------------ -------------------- ------------------------------control_files string /opt/app/oracle/oradata/ORA112 /control1.ctl, /opt/app/oracle /oradata/ORA112/control2.ctl$ cp /opt/app/oracle/oradata/ORA112/control1.ctl /opt/app/oracle/oradata/ORA112/control1.ctl.old$ cp /opt/app/oracle/oradata/ORA112/control2.ctl /opt/app/oracle/oradata/ORA112/control2.ctl.old
Note: Binary backup and ASCII backup are different!
SQL> alter database backup controlfile to trace;
The preceding command generates an ASCII command, which can be used to recreate the controlfile. This command is not actually a backup of current controlfile.
******* **********************************
Note: The following is added by the translator himself:
5. Database-level Supplemental log information will be lost after the control file is rebuilt
For details, see:
Missed Database Supplemental Log Information After Recreate Controlfile In 10g Database. (Document ID 1474952.1)
Or:
Http://blog.csdn.net/msdnchina/article/details/38360055
******* **********************************
Recommended:
1) Reuse control files on Different Storage
There must be at least two copies with control files on two different storages. If the media is damaged, at least one copy is available.
Therefore, the database parameter file must have at least two control file locations:
control_files='location1/file1','location2/file2'
2) Open the autobackup of the Control File
This will ensure that there will be a controlfile backup at the end of each backup
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
If necessary, run the following command to modify the location of autobackup:
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default