控制文件
总结：
1.控制文件十分重要，要将rman设置为自动备份控制文件
2.长期保存一份重建控制文件的脚本：
alter database backup controlfile to trace as '*.txt'
热备控制文件：alter database backup controlfile to '/file_path';
当备份文件丢失后还原备份文件：拷贝备份的控制文件到原来的文件位置；
此时只是完成了备份文件的转储，接下来还原备份文件；
recover database;
此时提示需要使用备份的控制文件恢复：
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
此时提示需要用到归档日志恢复：
SQL> recover database using backup controlfile;
ORA-00279: change 1306172 generated at 09/15/2013 15:19:14 needed for thread 1
ORA-00289: suggestion : /s01/orabase/flash_recovery_area/ORCL/archivelog/2013_09_15/o1_mf_1_27_%u_.arc
ORA-00280: change 1306172 for thread 1 is in sequence #27
由于数据库运行在非归档模式下，所以直接使用联机日志:
SELECT controlfile_type, controlfile_sequence#, controlfile_change#,controlfile_time,open_resetlogs FROM v$database;
此时redo01.log为current状态，因此使用此日志恢复；
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/s01/orabase/oradata/orcl/redo01.log
ORA-00279: change 1347440 generated at 09/15/2013 15:58:47 needed for thread 1
ORA-00289: suggestion : /s01/orabase/flash_recovery_area/ORCL/archivelog/2013_09_15/o1_mf_1_29_%u_.arc
ORA-00280: change 1347440 for thread 1 is in sequence #29
ORA-00278: log file '/s01/orabase/oradata/orcl/redo01.log' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/s01/orabase/oradata/orcl/redo02.log
Log applied.
Media recovery complete.
SQL>
恢复完成
使用resetlogs打开数据库:
alter database open resetlogs;
******************************************************************************************************************************************************************
控制文件版本号不一致问题：
ORA-00214: control file '/s01/app/control01.ctl' version 2528 inconsistent with file '/s01/orabase/flash_recovery_area/orcl/control02.ctl' version 2480
使用高版本号覆盖低版本号：
*********************************************************************************************************************************************************************
关于resetlogs详解（转载）：
racle的resetlogs机制浅析
alter database open resetlogs 这个命令我想大家都很熟悉了，那有没有想过这个resetlogs选项为什么要用？什么时候用？
它的原理机制是什么？他都起哪些作用？
我们都知道数据在启动时候是要做一致性检查的，oracle在open阶段要做两次检查
1. 检查数据文件头的检查点计数（checkpoint cnt）是否和控制文件的检查点计数（checkpoint cnt）一致。目的是确认数据文件
是否来自同一版本，而不是从备份中恢复的。如果这一步检查通过，就进行第二步检查
2. 检查数据文件头的开始scn和控制文件中记录该文件的结束scn是否一致。如果数据文件头的开始scn和控制文件中该文件的结束scn
相等，那说明这个数据文件就不需要恢复，否则就要恢复文件
如果以上两步检查都通过，那就可以正常打开数据库，锁定数据文件，同时将控制文件中每个数据文件的结束scn设置无穷大。
我们在某些条件下打开数据，会提示让用resetlogs选项open数据库，为什么要用resetlogs呢？它是干嘛用的呢？问号一大堆了吧,
下面来具体分析下。
resetlogs的作用
防止陈旧的数据进入数据库（保证数据库的一致性），这也就是为什么在用resetlogs打开数据库，一定要立即对数据库做个全备。
在控制文件，data file header，redo log header里存储”resetlogs data“，当open resetlogs被执行时，可以通过这些内容检查一致性。
什么时候用resetlogs
1. 不完全恢复
2. 用备份的控制文件恢复
3. 新创建的控制文件来恢复
resetlogs的原理机制
resetlogs是如何来保证打开数据库是一致的呢？
1）在open resetlogs时，oracle要对比检查控制文件和数据字典file$,如果一个数据文件在file$中存在，但在控制文件中不存在，
那在控制文件中将创建一个这个文件条目（MISSINGnnn ‘nnn’是十进制的file_id）,同时这个文件被标记为离线并需要恢复。如果
实际中这个文件存在的话，可以通过如下sql更改到正确的文件名。
sql> alter database rename file 'MISSINGnnn' to '<filename>'；
然后数据文件被恢复，online。
2）如果一个数据文件存在控制文件中，而不在数据字典file$中，那么直接把控制文件中这个文件的记录条目删除（oracle认为file$文
件是正确的，要以它为准）
3）当用旧的备份控制文件恢复的时候，如果有数据文件不在控制文件中注册（会提示控制文件比较旧的错误），那就不得不重建数据文件
，以使数据文件注册到控制文件中，然后系统会自动利用redo/archivelog恢复这个数据文件。
在保证控制文件和file$文件内容一致之后，oracle还有做如下检查才能open resetlogs
4）数据文件的版本要小于当前数据库的版本（counter）
5）offline的数据文件必须被online或者直接drop
6）所有的数据文件不能设置fuzzy bit，所有的数据文件要有相同的检查点（checkpoint SCN）
到目前为止，open resetlogs的前提条件都已经满足，resetlogs究竟做了哪些工作呢？（重新使用redo log）
1）所有的online logfile 的信息重新被放置在控制文件中。并且还要为有效的thread挑选一个logfile文件作为current logfile
2）log header被更新为log seq#
3）所有的online的数据文件头被新的checkpoint和新的‘resetlogs data’更新，offline的数据文件被标记为需要媒体恢复。
resetlogs data：当前的scn和counter被称作”resetlogs data“
如果oracle数据库一致性检查失败的，那数据库是不允许被open的，即 open resetlogs不成功。但也不是绝对不能open，可以通过隐含参数“_allow_resetlogs_curruption”,绕过oracle的一致性检查，但这样会引起数据库的不一致（文件可能有不同的scn或有fuzzy bit设置），如果open后，数据库一定要rebuild （建议ANALYZE TABLE ...VALIDATE STRUCTURE CASCADE;或者imp/exp ）
