通过重建控制文件可以快速的进行数据库的恢复
SQL> alter database backup controlfile to '/tmp/control_2018_11_30.bk';
Database altered.
SQL> show parameter control;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time integer 7
control_files string /u01/app/oracle/oradata/oradb/
control01.ctl, /disk2/oradata/
oradb/control02.ctl, /disk3/or
adata/oradb/control03.ctl
将所有的控制文件都删除掉
[root@Database2 ~]# rm -rf /u01/app/oracle/oradata/oradb/control01.ctl
[root@Database2 ~]# rm -rf /disk2/oradata/oradb/control02.ctl
[root@Database2 ~]# rm -rf /disk3/oradata/oradb/control03.ctl
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00205: error in identifying control file, check alert log for more info
由于控制文件全部丢失，使用之前备份的控制文件，这个控制文件是一个二级制的。
[oracle@Database2 ~]$ ls -l /tmp/control_2018_11_30.bk
-rw-r-----. 1 oracle oinstall 9912320 May 24 12:15 /tmp/control_2018_11_30.bk
将之前备份的控制文件拷贝到之前丢失的所有的控制文件路径下
[oracle@Database2 ~]$ cp /tmp/control_2018_11_30.bk /u01/app/oracle/oradata/oradb/control01.ctl
[oracle@Database2 ~]$ cp /tmp/control_2018_11_30.bk /disk2/oradata/oradb/control02.ctl
[oracle@Database2 ~]$ cp /tmp/control_2018_11_30.bk /disk3/oradata/oradb/control03.ctl
SQL> alter database mount;
Database altered.
由于备份是之前的，控制文件上记录的检查点和当前数据库的检查点信息是否一致呢？（控制文件上记录的检查点信息，数据文件上记录的检查点信息，redo日志上面记录的检查点信息）
SQL> set linesize 1500;
SQL> col name for a30;
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile; --控制文件上记录的检查点信息
NAME CHECKPOINT_CHANGE#
------------------------------ ------------------
/u01/app/oracle/oradata/oradb/ 265701
system01.dbf
/u01/app/oracle/oradata/oradb/ 265701
sysaux01.dbf
/u01/app/oracle/oradata/oradb/ 265701
undotbs01.dbf
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile_header;--数据文件上检查点的信息
NAME CHECKPOINT_CHANGE#
------------------------------ ------------------
/u01/app/oracle/oradata/oradb/ 265709
system01.dbf
/u01/app/oracle/oradata/oradb/ 265709
sysaux01.dbf
/u01/app/oracle/oradata/oradb/ 265709
undotbs01.dbf
可以看到两个检查点信息不一致，因为数据文件是最新的检查点信息，控制文件是在备份控制文件的时候的检查点信息，这样导致了不一致性。
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
可以看到虽然可以通过备份的控制文件启动到mount状态，在open的时候一致性检查通不过导致数据库还是打不开。这个时候可能要做一个基于时间点的不完全恢复，这个可能就需要恢复的时间比较长了。
这里有一个更好的方式，利用数据文件上面的信息重建控制文件。当在重建控制文件的时候，会根据数据文件和redo日志记录的信息重写控制文件，这样控制文件就可以恢复到和数据文件一致，然后再将库打开。
SQL> alter database backup controlfile to trace; --做重建控制文件的时候要生成一个trace文件，通过trace文件进行重建
Database altered.
alter database backup controlfile to trace
Backup controlfile written to trace file /u01/app/oracle/diag/rdbms/oradb/oradb/trace/oradb_ora_6550.trc
在/u01/app/oracle/diag/rdbms/oradb/oradb/trace/oradb_ora_6550.trc里面找出重建的语句
CREATE CONTROLFILE REUSE DATABASE "ORADB" NORESETLOGS NOARCHIVELOG
MAXLOGFILES 20
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/oradb/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/u01/app/oracle/oradata/oradb/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/u01/app/oracle/oradata/oradb/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/oradb/system01.dbf',
'/u01/app/oracle/oradata/oradb/sysaux01.dbf',
'/u01/app/oracle/oradata/oradb/undotbs01.dbf'
CHARACTER SET ZHS16GBK
;
[oracle@Database2 ~]$ vi creat_control.sql --将上面的内容写到该文件里面
SQL> startup force nomount; --重建控制文件只能在nomount下
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2260088 bytes
Variable Size 671089544 bytes
Database Buffers 390070272 bytes
Redo Buffers 5517312 bytes
SQL> @/home/oracle/creat_control.sql
Control file created.
SQL> select status from v$instance; --重建控制文件数据库会到mount状态
STATUS
------------
MOUNTED
重建完成，再去看看控制文件和数据文件记录的检查点信息。
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile;
NAME CHECKPOINT_CHANGE#
------------------------------ ------------------
/u01/app/oracle/oradata/oradb/ 265709
system01.dbf
/u01/app/oracle/oradata/oradb/ 265709
sysaux01.dbf
/u01/app/oracle/oradata/oradb/ 265709
undotbs01.dbf
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
------------------------------ ------------------
/u01/app/oracle/oradata/oradb/ 265709
system01.dbf
/u01/app/oracle/oradata/oradb/ 265709
sysaux01.dbf
/u01/app/oracle/oradata/oradb/ 265709
undotbs01.dbf
重建以后新的控制文件的检查点信息是根据数据文件上的检查点来重写，重建控制文件比基于时间点的恢复要快。
打开库后，在告警日志里面有一个提示说临时表空间里面不包含文件了。
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
This condition can occur when a backup controlfile has
been restored. It may be necessary to add files to these，
tablespaces. That can be done using the SQL statement:
ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
Alternatively, if these temporary tablespaces are no longer
needed, then they can be dropped.
Empty temporary tablespace: TEMP
SQL> select name from v$tempfile; --可以看到没有tmp表空间了，因为重建控制文件的脚本里面没有创建临时表空间的语句
no rows selected
[oracle@Database2 dbs]$ cd /u01/app/oracle/oradata/oradb/
[oracle@Database2 oradb]$ ls
control01.ctl redo01.log redo02.log redo03.log sysaux01.dbf system01.dbf temp01.dbf undotbs01.dbf
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
SQL> alter tablespace temp add tempfile '/u01/app/oracle/oradata/oradb/temp01.dbf' reuse;
Tablespace altered.
SQL> select name from v$tempfile;
NAME
------------------------------
/u01/app/oracle/oradata/oradb/
temp01.dbf
可以看到，重建控制文件是在所有控制文件丢失的情况下快速打开数据库的一种方式，前提是有一个备份的trace或者二级制控制文件。
在生产库下面恢复控制文件的时候一定要注意先做好对整个数据库的一个备份，如果控制文件创建失败会导致库打不开，没法恢复了。（做好备份，再重建）
对控制文件的原则：对控制文件做多元化，多元化将文件放在不同的存储设备上，当数据库的物理结构发生变化的时候对控制文件进行一个有效的备份。
下面是在重建控制文件时候的alter后台日志：
Thu May 24 13:30:50 2018
CREATE CONTROLFILE REUSE DATABASE "ORADB" NORESETLOGS NOARCHIVELOG
MAXLOGFILES 20
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/oradb/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/u01/app/oracle/oradata/oradb/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/u01/app/oracle/oradata/oradb/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/oradb/system01.dbf',
'/u01/app/oracle/oradata/oradb/sysaux01.dbf',
'/u01/app/oracle/oradata/oradb/undotbs01.dbf'
CHARACTER SET ZHS16GBK
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Thu May 24 13:30:51 2018
Successful mount of redo thread 1, with mount id 2730237450
Completed: CREATE CONTROLFILE REUSE DATABASE "ORADB" NORESETLOGS NOARCHIVELOG
MAXLOGFILES 20
MAXLOGMEMBERS 5
MAXDATAFILES 100
MAXINSTANCES 1
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/u01/app/oracle/oradata/oradb/redo01.log' SIZE 50M BLOCKSIZE 512,
GROUP 2 '/u01/app/oracle/oradata/oradb/redo02.log' SIZE 50M BLOCKSIZE 512,
GROUP 3 '/u01/app/oracle/oradata/oradb/redo03.log' SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/oradb/system01.dbf',
'/u01/app/oracle/oradata/oradb/sysaux01.dbf',
'/u01/app/oracle/oradata/oradb/undotbs01.dbf'
CHARACTER SET ZHS16GBK
Thu May 24 13:31:29 2018
alter database mount
ORA-1100 signalled during: alter database mount...
Thu May 24 13:37:03 2018
alter database open
Initializing SCN for created control file
Database SCN compatibility initialized to 1
Thu May 24 13:37:04 2018
Thread 1 advanced to log sequence 18 (thread open)
Thread 1 opened at log sequence 18
Current log# 3 seq# 18 mem# 0: /u01/app/oracle/oradata/oradb/redo03.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu May 24 13:37:04 2018
SMON: enabling cache recovery
[6654] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:39757364 end:39758384 diff:1020 (10 seconds)
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
This condition can occur when a backup controlfile has
been restored. It may be necessary to add files to these
tablespaces. That can be done using the SQL statement:
ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
Alternatively, if these temporary tablespaces are no longer
needed, then they can be dropped.
Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Thu May 24 13:37:12 2018
QMNC started with pid=20, OS id=6689
