oracle controlfile backup and recovery
备份：
alter database backup controlfile to 'xxxxxxx' reuse;
alter database bakcup controlfile to trace as 'xxxxxxx';
RMAN备份控制文件
恢复实例：
1.控制文件损坏后利用二进制备份恢复(异常断电）
备份控制文件：
alter database backup controlfile to '/home/oracle/control.ctl ' reuse;
插入测试数据：
SQL> insert into t1 values(1);
SQL> commit;
模拟断电：
SQL> shutdown abort;
模拟控制文件故障：
rm -rf /database/oradata/skyread/control01.ctl
rm -rf /database/oradata/skyread/control02.ctl
rm -rf /database/oradata/skyread/control03.ctl
再次开启数据库：
SQL> startup;
ORA-00205: error in identifying control file, check alert log for more info
报00205错误
把备份文件复制到数据库控制文件所在位置：
cp /home/oracle/control.ctl /database/oradata/skyread/control01.ctl
cp /home/oracle/control.ctl /database/oradata/skyread/control02.ctl
cp /home/oracle/control.ctl /database/oradata/skyread/control03.ctl
SQL> startup force mount
Total System Global Area 5049942016 bytes
Fixed Size 2090880 bytes
Variable Size 1375733888 bytes
Database Buffers 3657433088 bytes
Redo Buffers 14684160 bytes
Database mounted.
检查数据文件，数据文件头，日志文件以及控制文件的scn信息，由于是机器断电，所以这里fuzzy的状态是YES
SQL> select file#,status,fuzzy,CHECKPOINT_CHANGE# from v$datafile_header;
FILE# STATUS FUZ CHECKPOINT_CHANGE#
-------------------- ------- --- --------------------
1 ONLINE YES 122694280130
2 ONLINE YES 122694280130
3 ONLINE YES 122694280130
4 ONLINE YES 122694280130
18 ONLINE YES 122694280130
26 ONLINE YES 122694280130
31 ONLINE YES 122694280130
SQL> select group#,sequence#,members,archived,status,first_change# from v$log;
GROUP# SEQUENCE# MEMBERS ARC STATUS FIRST_CHANGE#
-------------------- -------------------- -------------------- --- ---------------- --------------------
1 1 1 NO CURRENT 122694212304
2 2 1 YES INACTIVE 122693905385
5 3 1 YES INACTIVE 122694191761
4 4 1 YES INACTIVE 122694190542
3 5 1 YES INACTIVE 122694168156
CONTROLFILE_CHANGE#是备份时的控制文件SCN，这里数据文件的检查点肯定是大于当时备份的控制文件，所以数据打开的时候，数据文件，日志文件，控制文件的检查点信息是不一致的，要进行介质恢复到一致，才能打开，以上V$LOG,V$DATAFILE都是和备份的控制文件的检查点一致的。但是v$datafile_header记录的是最新的，就是数据库关闭前的。所以如果打开的时候做会做检查，检查数据文件头的检查点计数和与现在控制文件的检查点技术是否相等，如果相等，进行第二次检查，也就是检查数据文件头开始的SCN和控制文件结束的SCN是否相等，如果相等，就不需要进行恢复，不相等，就需要进行恢复。这里明显是不相等的，所以需要recovery。
SQL> select checkpoint_change#,controlfile_change#,resetlogs_change# from v$database;
CHECKPOINT_CHANGE# CONTROLFILE_CHANGE# RESETLOGS_CHANGE#
-------------------- -------------------- --------------------
122694212305 122694259161 122693676208
介质恢复数据库：提示需要应用redo01.log
SQL> recover database using backup controlfile;
ORA-00279: change 122694280130 generated at 05/03/2013 11:25:37 needed for
thread 1
ORA-00289: suggestion : /database/oradata/arch/1_1_814447469.dbf
ORA-00280: change 122694280130 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/database/oradata/skyread/redo01.log
Log applied.
Media recovery complete.
重置日志文件打开数据库：
SQL> alter database open resetlogs;
Database altered.
2.控制文件损坏后利用trace文件重建控制文件(正常关机）
备份控制文件为文本格式
SQL> alter database backup controlfile to trace as '/home/oracle/controlfile.sql' reuse;
Database altered.
干净关闭数据库并破坏所有控制文件
SQL> shutdown immediate;
mv /database/oradata/skyread/control01.ctl /database/oradata/skyread/control01.ctl.bak
mv /database/oradata/skyread/control02.ctl /database/oradata/skyread/control02.ctl.bak
mv /database/oradata/skyread/control03.ctl /database/oradata/skyread/control03.ctl.bak
打开数据库出错
SQL> startup;
ORACLE instance started.
Total System Global Area 5049942016 bytes
Fixed Size 2090880 bytes
Variable Size
