标签：
所有的控制文件坏了，有备份进行恢复
（1）备份control file
SQL> alter database backup controlfile to ‘/orcl_backup/hot/control.bin‘;
Database altered.
查看 检查点情况
SQL> col name for a35
SQL> select file#,name ,checkpoint_change# from v$datafile;
FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5088611
2 /orcl_backup/cold/sysaux01.dbf 5088611
3 /orcl_backup/cold/undotbs01.dbf 5088611
4 /orcl_backup/cold/users01.dbf 5088611
5 /orcl_backup/cold/tp01.dbf 5088611
执行日志切换
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
select file#,name ,checkpoint_change# from v$datafile;
System altered.
SQL>
FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5089022
2 /orcl_backup/cold/sysaux01.dbf 5089022
3 /orcl_backup/cold/undotbs01.dbf 5089022
4 /orcl_backup/cold/users01.dbf 5089022
5 /orcl_backup/cold/tp01.dbf 5089022
（3）把控制文件删除，当机
[oracle@evancao cold]$ rm -rf control*
SQL> shutdown abort
ORACLE instance shut down.
（4）根据告警日志中的信息把 备份拷贝到相应的目录下面
日志内容：
ALTER DATABASE MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: ‘/orcl_backup/cold/control02.ctl‘
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00210: cannot open the specified control file
ORA-00202: control file: ‘/orcl_backup/cold/control01.ctl‘
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
拷贝 ：
[oracle@evancao hot]$ cp control.bin /orcl_backup/cold/control02.ctl
[oracle@evancao hot]$ cp control.bin /orcl_backup/cold/control01.ctl
（5）打开数据库到mount状态
SQL> alter database mount;
Database altered.
在查一把检查点再查询一把
SQL> select file#,name ,checkpoint_change# from v$datafile;
FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5088611
2 /orcl_backup/cold/sysaux01.dbf 5088611
3 /orcl_backup/cold/undotbs01.dbf 5088611
4 /orcl_backup/cold/users01.dbf 5088611
5 /orcl_backup/cold/tp01.dbf 5088611
SQL> select file#,name ,checkpoint_change# from v$datafile_header;
FILE# NAME CHECKPOINT_CHANGE#
---------- ----------------------------------- ------------------
1 /orcl_backup/cold/system01.dbf 5089026
2 /orcl_backup/cold/sysaux01.dbf 5089026
3 /orcl_backup/cold/undotbs01.dbf 5089026
4 /orcl_backup/cold/users01.dbf 5089026
5 /orcl_backup/cold/tp01.dbf 5089026
recover database 对数据文件，控制文件恢复
（6）SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
对控制文件不能直接recover database;
SQL> recover database using backup controlfile;
ORA-00279: change 5088952 generated at 12/30/2014 05:14:38 needed for thread 1
ORA-00289: suggestion : /app/oracle/archive_log/1_336_861876939.dbf
ORA-00280: change 5088952 for thread 1 is in sequence #336
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
报错：
ORA-00308: cannot open archived log
‘/app/oracle/archive_log/1_339_861876939.dbf‘
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
（7）查看归档日志
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /app/oracle/archive_log
Oldest online log sequence 334
Next log sequence to archive 336
Current log sequence 336
SQL> exit
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@evancao ~]$ cd /app/oracle/archive_log
[oracle@evancao archive_log]$ ls
1_317_861876939.dbf 1_325_861876939.dbf 1_333_861876939.dbf
1_318_861876939.dbf 1_326_861876939.dbf 1_334_861876939.dbf
1_319_861876939.dbf 1_327_861876939.dbf 1_335_861876939.dbf
1_320_861876939.dbf 1_328_861876939.dbf 1_336_861876939.dbf
1_321_861876939.dbf 1_329_861876939.dbf 1_337_861876939.dbf
1_322_861876939.dbf 1_330_861876939.dbf 1_338_861876939.dbf
1_323_861876939.dbf 1_331_861876939.dbf
1_324_861876939.dbf 1_332_861876939.dbf
发现339 没有归档日志
查看redo log
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
1 1 334 52428800 512 1 YES
INACTIVE 5040816 30-DEC-14 5067980 30-DEC-14
3 1 336 52428800 512 1 NO
CURRENT 5088610 30-DEC-14 2.8147E+14
2 1 335 52428800 512 1 YES
INACTIVE 5067980 30-DEC-14 5088610 30-DEC-14
原因：是v$log视图来源与备份的控制文件。所有之后切换日志是没有记录在里面的。
（8）自己指定filename
SQL> /orcl_backup/cold/redo03.log
SP2-0734: unknown command beginning "/orcl_back..." - rest of line ignored.
SQL> recover database using backup controlfile;
ORA-00279: change 5089026 generated at 12/30/2014 05:18:32 needed for thread 1
ORA-00289: suggestion : /app/oracle/archive_log/1_339_861876939.dbf
ORA-00280: change 5089026 for thread 1 is in sequence #339
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/orcl_backup/cold/redo03.log
Log applied.
Media recovery complete.
(9)尝试打开数据库
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
失败，是因为在oracle的log中记录的还是之前的redo sequence number .所以打开会报错。
（10）alter database open resetlogs;这样会重置sequence
SQL> alter database open resetlogs;
Database altered.
再查看v$log
3.应用系统的数据文件
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
1 1 1 52428800 512 1 NO
CURRENT 5089094 30-DEC-14 2.8147E+14
2 1 0 52428800 512 1 YES
UNUSED 0 0
3 1 0 52428800 512 1 YES
UNUSED 0 0
可以观察到从1开始了
这样的话在切换日志，再观察归档日志
[oracle@evancao ~]$ cd /app/oracle/archive_log
[oracle@evancao archive_log]$ ls
1_1_867649920.dbf 1_324_861876939.dbf 1_333_861876939.dbf
1_2_867649920.dbf 1_325_861876939.dbf 1_334_861876939.dbf
1_317_861876939.dbf 1_326_861876939.dbf 1_335_861876939.dbf
1_318_861876939.dbf 1_327_861876939.dbf 1_336_861876939.dbf
1_319_861876939.dbf 1_328_861876939.dbf 1_337_861876939.dbf
1_320_861876939.dbf 1_329_861876939.dbf 1_338_861876939.dbf
1_321_861876939.dbf 1_330_861876939.dbf 1_339_861876939.dbf
1_322_861876939.dbf 1_331_861876939.dbf 1_3_867649920.dbf
1_323_861876939.dbf 1_332_861876939.dbf
1_1_867649920.dbf 的sequence已经从1开始了，但是后面的化生号不一样了，这里就需要每次使用reselogs打开数据库的时候在进行一次备份。
incarnation ======》化生号：描述当前数据库的标记。
查询化生号
SQL> select * from v$database_incarnation;
INCARNATION# RESETLOGS_CHANGE# RESETLOGS PRIOR_RESETLOGS_CHANGE# PRIOR_RES
------------ ----------------- --------- ----------------------- ---------
STATUS RESETLOGS_ID PRIOR_INCARNATION# FLASHBACK_DATABASE_ALLOWED
------- ------------ ------------------ --------------------------
1 1 17-SEP-11 0
PARENT 762083164 0 NO
2 995548 25-OCT-14 1 17-SEP-11
PARENT 861876939 1 NO
3 5089094 30-DEC-14 995548 25-OCT-14
CURRENT 867649920 2 NO
标签：
原文地址：http://www.cnblogs.com/evancao350/p/4194664.html
