但行好事 莫问前程

设置闪回区的情况下还原控制文件所使用的命令是相同的。然而如果当前数据库正在使用闪回区，RMAN通过对所有基于控制文件中的基于磁盘的备份和镜像副本和任何在闪回区中而不在还原的控制文件中的备份执行隐式的crosscheck来更新从备份中还原的控制文件。因此还原后的控制文件会完整的和精确的记录在闪回区中的所有备份和其它任何在备份该控制文件时所知道的备份。这提高了在数据库还原操作中的可用性。

下面来看一个使用闪回区还原控制文件的实例：
1.环境检查，看是否已经启用闪回区与设置控制文件自动备份

SQL> show parameter db_recover

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /u01/app/oracle/flash_recovery_area
db_recovery_file_dest_size           big integer 2G

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES


RMAN> show controlfile autobackup;

RMAN configuration parameters are:
CONFIGURE CONTROLFILE AUTOBACKUP ON;

从上面信息可知已经启用了闪回区并设置了控制文件自动备份

2.创建一个表空间,在数据库结构发生变化时，就会自动备份控制文件

SQL> create tablespace testbak datafile '/u01/app/oracle/oradata/test/testbak.dbf' size 10M  extent management local segment space management auto;

Tablespace created.

从alert日志中可以看到产生的控制文件自动备份的文件信息

create tablespace testbak datafile '/u01/app/oracle/oradata/test/testbak.dbf' size 10M  extent management local segment space management auto
Mon Feb 02 00:17:28 CST 2015
Starting control autobackup
Control autobackup written to DISK device
        handle '/u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_02/o1_mf_s_870567448_bdwndtqk_.bkp'
Completed: create tablespace testbak datafile '/u01/app/oracle/oradata/test/testbak.dbf' size 10M  extent management local segment space management auto

其实控制文件和spfile同时被自动备份了

查看闪回区是否存在自动备份文件

[root@oracle11g 2015_02_02]# ls -lrt
total 19360
-rw-r----- 1 oracle oinstall 9895936 Feb  2 00:17 o1_mf_s_870567448_bdwndtqk_.bkp

3.人为删除所有控制文件

[root@oracle11g test]# ls -lrt
total 2213868
-rw-r----- 1 oracle oinstall  20979712 Feb  1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall  11804672 Feb  1 22:31 users01.dbf
-rw-r----- 1 oracle oinstall  52436992 Feb  1 22:31 test01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo03.log
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo02.log
-rw-r----- 1 oracle oinstall 104865792 Feb  1 22:31 example01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb  1 22:37 sysaux01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb  1 22:42 undotbs01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb  1 22:42 system01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:42 redo01.log
-rw-r----- 1 oracle oinstall   9814016 Feb  1 22:42 control03.ctl
-rw-r----- 1 oracle oinstall   9814016 Feb  1 22:42 control02.ctl
-rw-r----- 1 oracle oinstall   9814016 Feb  1 22:42 control01.ctl
[root@oracle11g test]# rm -rf control*.ctl
[root@oracle11g test]# ls -lrt
total 2185068
-rw-r----- 1 oracle oinstall  20979712 Feb  1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall  11804672 Feb  1 22:31 users01.dbf
-rw-r----- 1 oracle oinstall  52436992 Feb  1 22:31 test01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo03.log
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo02.log
-rw-r----- 1 oracle oinstall 104865792 Feb  1 22:31 example01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb  1 22:37 sysaux01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb  1 22:42 undotbs01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb  1 22:42 system01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:42 redo01.log

4.人为将数据库异常终止

[root@oracle11g test]# ps -ef | grep smon
oracle    3068     1  0 22:30 ?        00:00:00 ora_smon_test
root      3179  3123  0 22:45 pts/3    00:00:00 grep smon
[root@oracle11g test]# kill -9 3068

5.将数据库启动到nomount状态

SQL> startup nomount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes

6.恢复控制文件

RMAN> restore controlfile  from autobackup;

Starting restore at 02-FEB-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=148 devtype=DISK

recovery area destination: /u01/app/oracle/flash_recovery_area
database name (or database unique name) used for search: TEST
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_02/o1_mf_s_870567448_bdwndtqk_.bkp
channel ORA_DISK_1: control file restore from autobackup complete
Finished restore at 02-FEB-15

在上面的还原控制文件的过程可以看到如下内容说明是使用存储在闪回区中的控制文件自动备份来还原控制文件

channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: /u01/app/oracle/flash_recovery_area/TEST/autobackup/2015_02_02/o1_mf_s_870567448_bdwndtqk_.bkp

磁带备份在还原控制文件后不会自动执行crosscheck。如果正使用磁带备份，那么在还原控制文件并将数据库置于mount状态后，必须手工执行crosscheck.

RMAN> CROSSCHECK BACKUP DEVICE TYPE SBT;

7.执行完全恢复

RMAN> sql 'alter database mount';

sql statement: alter database mount
released channel: ORA_DISK_1

RMAN> recover database;

Starting recover at 01-FEB-15
Starting implicit crosscheck backup at 01-FEB-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
Crosschecked 8 objects
Finished implicit crosscheck backup at 01-FEB-15

Starting implicit crosscheck copy at 01-FEB-15
using channel ORA_DISK_1
Crosschecked 6 objects
Finished implicit crosscheck copy at 01-FEB-15

searching for all files in the recovery area
cataloging files...
no files cataloged

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 3 is already on disk as file /u01/app/oracle/oradata/test/redo03.log
archive log thread 1 sequence 4 is already on disk as file /u01/app/oracle/oradata/test/redo01.log
archive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=3
archive log filename=/u01/app/oracle/oradata/test/redo01.log thread=1 sequence=4
media recovery complete, elapsed time: 00:00:01
Finished recover at 01-FEB-15



RMAN> sql 'alter database open resetlogs';

sql statement: alter database open resetlogs
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

当没有使用恢复目录时，必须从控制文件自动备份中还原控制文件。如果从控制文件自动备份中还原控制文件，数据库必须置于nomount状态。必须首先设置数据库的DBID，然后执行restore controlfile from autobackup命令

1.人为删除所有控制文件

[root@oracle11g test]# ls -lrt
total 2213868
-rw-r----- 1 oracle oinstall  20979712 Feb  1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall  11804672 Feb  1 22:31 users01.dbf
-rw-r----- 1 oracle oinstall  52436992 Feb  1 22:31 test01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo03.log
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo02.log
-rw-r----- 1 oracle oinstall 104865792 Feb  1 22:31 example01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb  1 22:37 sysaux01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb  1 22:42 undotbs01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb  1 22:42 system01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:42 redo01.log
-rw-r----- 1 oracle oinstall   9814016 Feb  1 22:42 control03.ctl
-rw-r----- 1 oracle oinstall   9814016 Feb  1 22:42 control02.ctl
-rw-r----- 1 oracle oinstall   9814016 Feb  1 22:42 control01.ctl
[root@oracle11g test]# rm -rf control*.ctl
[root@oracle11g test]# ls -lrt
total 2185068
-rw-r----- 1 oracle oinstall  20979712 Feb  1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall  11804672 Feb  1 22:31 users01.dbf
-rw-r----- 1 oracle oinstall  52436992 Feb  1 22:31 test01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo03.log
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:31 redo02.log
-rw-r----- 1 oracle oinstall 104865792 Feb  1 22:31 example01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb  1 22:37 sysaux01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb  1 22:42 undotbs01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb  1 22:42 system01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 22:42 redo01.log

2.人为将数据库异常终止

[root@oracle11g test]# ps -ef | grep smon
oracle    3063     1  0 22:30 ?        00:00:00 ora_smon_test
root      3179  3123  0 22:45 pts/3    00:00:00 grep smon
[root@oracle11g test]# kill -9 3063

3.将数据库启动到nomount状态

SQL> startup nomount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes

4.从以前的备份信息中可以找到如下信息，其中c-2155613261-20150201-03中的2155613261就是DBID

Starting Control File and SPFILE Autobackup at 01-FEB-15
piece handle=/u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150201-03 comment=NONE
Finished Control File and SPFILE Autobackup at 01-FEB-15

5.还原控制文件

RMAN> show controlfile autobackup format;

RMAN configuration parameters are:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'STB' TO '%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO '%F';

RMAN> set dbid 2155613261;

executing command: SET DBID

RMAN> restore controlfile from autobackup;

Starting restore at 01-FEB-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK

recovery area destination: /u01/app/oracle/flash_recovery_area
database name (or database unique name) used for search: TEST
channel ORA_DISK_1: no autobackups found in the recovery area
channel ORA_DISK_1: looking for autobackup on day: 20150201
channel ORA_DISK_1: autobackup found: c-2155613261-20150201-03
channel ORA_DISK_1: control file restore from autobackup complete
output filename=/u01/app/oracle/oradata/test/control01.ctl
output filename=/u01/app/oracle/oradata/test/control02.ctl
output filename=/u01/app/oracle/oradata/test/control03.ctl
Finished restore at 01-FEB-15

6.恢复数据库

RMAN> sql 'alter database mount';

sql statement: alter database mount
released channel: ORA_DISK_1

RMAN> recover database;

Starting recover at 01-FEB-15
Starting implicit crosscheck backup at 01-FEB-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
Crosschecked 13 objects
Finished implicit crosscheck backup at 01-FEB-15

Starting implicit crosscheck copy at 01-FEB-15
using channel ORA_DISK_1
Crosschecked 6 objects
Finished implicit crosscheck copy at 01-FEB-15

searching for all files in the recovery area
cataloging files...
no files cataloged

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 2 is already on disk as file /u01/app/oracle/oradata/test/redo02.log
archive log thread 1 sequence 3 is already on disk as file /u01/app/oracle/oradata/test/redo03.log
archive log filename=/u01/app/oracle/oradata/test/redo02.log thread=1 sequence=2
archive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=3
media recovery complete, elapsed time: 00:00:03
Finished recover at 01-FEB-15

RMAN> sql 'alter database open resetlogs';

sql statement: alter database open resetlogs

RMAN会使用自动备份的格式与DBID来判断在什么存储位置来搜索控制文件自动备份。如果找到，RMAN就会从备份中将控制文件还原到由control_files参数所指定的所有位置

如果丢失或损坏所有的控制文件就需要从备份中还原控制文件。restore controlfile命令用来还原控制文件。在还原控制文件后需要对数据亩执行完全介质恢复并以resetlog选项来打开数据库。RMAN可以将控制文件还原到它的默认存储位置，也可以使用restore controlfile … to destination来指定位置。

从已经知的控制文件备份中还原控制文件

SQL> show parameter control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /u01/app/oracle/oradata/test/c
                                                 ontrol01.ctl, /u01/app/oracle/
                                                 oradata/test/control02.ctl, /u
                                                 01/app/oracle/oradata/test/con
                                                 trol03.ctl

显示当前可用的备份

RMAN> list backup;


List of Backup Sets
===================

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
77      693.50K    DISK        00:00:02     28-JAN-15
        BP Key: 75   Status: AVAILABLE  Compressed: YES  Tag: TAG20150128T131713
        Piece Name: /u02/test_df870182233_s95_s1

  List of Archived Logs in backup set 77
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    13      2928236    28-JAN-15 2928830    28-JAN-15

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
78      Full    166.91M    DISK        00:01:19     28-JAN-15
        BP Key: 76   Status: AVAILABLE  Compressed: YES  Tag: TAG20150128T131716
        Piece Name: /u02/test_df870182236_s96_s1
  List of Datafiles in backup set 78
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 2928835    28-JAN-15 /u01/app/oracle/oradata/test/system01.dbf
  2       Full 2928835    28-JAN-15 /u01/app/oracle/oradata/test/undotbs01.dbf
  3       Full 2928835    28-JAN-15 /u01/app/oracle/oradata/test/sysaux01.dbf
  4       Full 2928835    28-JAN-15 /u01/app/oracle/oradata/test/users01.dbf
  5       Full 2928835    28-JAN-15 /u01/app/oracle/oradata/test/example01.dbf
  6       Full 2928835    28-JAN-15 /u01/app/oracle/oradata/test/test01.dbf

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
79      7.50K      DISK        00:00:01     28-JAN-15
        BP Key: 77   Status: AVAILABLE  Compressed: YES  Tag: TAG20150128T131841
        Piece Name: /u02/test_df870182321_s97_s1

  List of Archived Logs in backup set 79
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    14      2928830    28-JAN-15 2928868    28-JAN-15

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
80      Full    9.42M      DISK        00:00:02     28-JAN-15
        BP Key: 78   Status: AVAILABLE  Compressed: NO  Tag: TAG20150128T131843
        Piece Name: /u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150128-0d
  Control File Included: Ckp SCN: 2928874      Ckp time: 28-JAN-15
  SPFILE Included: Modification time: 28-JAN-15

从上面的信息可以看到备份集80是控制文件与spfile文件的备份

下面来删除当前数据库的所有控制文件：

[root@oracle11g ~]# cd /u01/app/oracle/oradata/test/
[root@oracle11g test]# ls -lrt
total 2213868
-rw-r----- 1 oracle oinstall  11804672 Feb  1 11:36 users01.dbf
-rw-r----- 1 oracle oinstall  52436992 Feb  1 11:36 test01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 11:36 redo02.log
-rw-r----- 1 oracle oinstall  52429312 Feb  1 11:36 redo01.log
-rw-r----- 1 oracle oinstall 104865792 Feb  1 11:36 example01.dbf
-rw-r----- 1 oracle oinstall  20979712 Feb  1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb  1 19:05 system01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb  1 19:05 undotbs01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb  1 19:05 sysaux01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 19:10 redo03.log
-rw-r----- 1 oracle oinstall   9814016 Feb  1 19:11 control03.ctl
-rw-r----- 1 oracle oinstall   9814016 Feb  1 19:11 control02.ctl
-rw-r----- 1 oracle oinstall   9814016 Feb  1 19:11 control01.ctl
[root@oracle11g test]# rm -rf control*.ctl
[root@oracle11g test]# ls -lrt
total 2185068
-rw-r----- 1 oracle oinstall  52429312 Feb  1 11:36 redo02.log
-rw-r----- 1 oracle oinstall  20979712 Feb  1 11:37 temp01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 19:13 redo03.log
-rw-r----- 1 oracle oinstall  11804672 Feb  1 19:14 users01.dbf
-rw-r----- 1 oracle oinstall 492838912 Feb  1 19:14 undotbs01.dbf
-rw-r----- 1 oracle oinstall  52436992 Feb  1 19:14 test01.dbf
-rw-r----- 1 oracle oinstall 838868992 Feb  1 19:14 system01.dbf
-rw-r----- 1 oracle oinstall 576724992 Feb  1 19:14 sysaux01.dbf
-rw-r----- 1 oracle oinstall  52429312 Feb  1 19:14 redo01.log
-rw-r----- 1 oracle oinstall 104865792 Feb  1 19:14 example01.dbf

向测试表t2中插入一些数据库

SQL> insert into t2 select * from dba_objects;

51319 rows created.

SQL> select count(*) from t2;

  COUNT(*)
----------
    102560

SQL> commit;

Commit complete.

这里因为是从linux操作系统层面删除了所有控制文件，因为在数据库没有关闭的情况下文件的句柄没有释放所以数据库还能运行。

人为将数据库异常终止

[root@oracle11g test]# ps -ef | grep smon
oracle    3463     1  0 22:30 ?        00:00:00 ora_smon_test
root      3179  3123  0 22:45 pts/3    00:00:00 grep smon
[root@oracle11g test]# kill -9 3463

启动数据库：

SQL> startup
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
ORA-00205: error in identifying control file, check alert log for more info

alert日志的内容如下:

ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/oradata/test/control01.ctl'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Sun Feb 01 19:18:18 CST 2015
ORA-205 signalled during: ALTER DATABASE   MOUNT...

找不到控制文件不能将数据库置于mount状态.现在通过备份来还原控制文件执行完全数据库恢复:

RMAN> restore controlfile from '/u01/app/oracle/10.2.0/db/dbs/c-2155613261-20150128-0d';

Starting restore at 01-FEB-15
using channel ORA_DISK_1

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:05
output filename=/u01/app/oracle/oradata/test/control01.ctl
output filename=/u01/app/oracle/oradata/test/control02.ctl
output filename=/u01/app/oracle/oradata/test/control03.ctl
Finished restore at 01-FEB-15


RMAN> sql 'alter database mount';

sql statement: alter database mount
released channel: ORA_DISK_1

SQL> select status from v$instance;

STATUS
------------------------
MOUNTED

执行完全恢复

RMAN> recover database;

Starting recover at 01-FEB-15
Starting implicit crosscheck backup at 01-FEB-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=155 devtype=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at 01-FEB-15

Starting implicit crosscheck copy at 01-FEB-15
using channel ORA_DISK_1
Crosschecked 6 objects
Finished implicit crosscheck copy at 01-FEB-15

searching for all files in the recovery area
cataloging files...
no files cataloged

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 17 is already on disk as file /u01/app/oracle/oradata/test/redo02.log
archive log thread 1 sequence 18 is already on disk as file /u01/app/oracle/oradata/test/redo03.log
archive log thread 1 sequence 19 is already on disk as file /u01/app/oracle/oradata/test/redo01.log
archive log filename=/u02/1_15_870133266.dbf thread=1 sequence=15
archive log filename=/u02/1_16_870133266.dbf thread=1 sequence=16
archive log filename=/u01/app/oracle/oradata/test/redo02.log thread=1 sequence=17
archive log filename=/u01/app/oracle/oradata/test/redo03.log thread=1 sequence=18
archive log filename=/u01/app/oracle/oradata/test/redo01.log thread=1 sequence=19
media recovery complete, elapsed time: 00:00:06
Finished recover at 01-FEB-15


RMAN> sql 'alter database open resetlogs';

sql statement: alter database open resetlogs

SQL>  select status from v$instance;

STATUS
------------
OPEN

SQL> select count(*) from t2;

  COUNT(*)
----------
    102560

表t2中的记录与恢复之前相同，说明恢复成功。

当还原控制文件时，控制文件的默认位置是由参数control_files控制的。如果没有设置control_files参数，那么数据库判断还原控制文件存储位置的规则将会与没有设置control_files参数时创建控制文件时使用的规则一样。

朋友在rman中执行crosscheck backup出现ORA-19554错误

RMAN> crosscheck backup;

using channel ORA_DISK_1
released channel: ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of crosscheck command at 01/23/2015 17:23:19
ORA-19554: error allocating device, device type: STB, device name:
ORA-27001: unsupported device type
Additional information: 1

提示找不到STB，根本就没有这种设备，下面执行命令来显示所有配置信息

RMAN> show all;

RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE STB TO '%F'; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET PARALLELISM 1;
CONFIGURE DEVICE TYPE 'STB' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE STB TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE STB TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/u02/test_df%t_s%s_s%p';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/10.2.0/db/dbs/snapcf_test.f'; # default

上述信息中有
CONFIGURE DEVICE TYPE ‘SBT_TAPE’ BACKUP TYPE TO BACKUPSET PARALLELISM 1;
说明确实有人设置了SBT_TAPE类型的设备信息，下面将其设置还原为默认值：

RMAN> configure device type 'SBT_TAPE' clear;

old RMAN configuration parameters:
CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 1;
RMAN configuration parameters are successfully reset to default value

RMAN> show all;

RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'STB' TO '%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO '%F';
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET PARALLELISM 1;
CONFIGURE DEVICE TYPE 'STB' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE 'STB' TO 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE 'SBT_TAPE' TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE 'STB' TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE 'SBT_TAPE' TO 1;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/u02/test_df%t_s%s_s%p';
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF;
CONFIGURE ENCRYPTION ALGORITHM 'AES128';
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/10.2.0/db/dbs/snapcf_test.f';

再来执行crosscheck backup命令正常执行：

RMAN> crosscheck backup;

allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=145 devtype=DISKcrosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u02/test_df869734336_s15_s1 recid=5 stamp=869734336
crosschecked backup piece: found to be 'AVAILABLE'
backup piece handle=/u02/test_df869734461_s16_s1 recid=6 stamp=869734463
Crosschecked 2 objects

闪回数据库和还原点是两种与数据恢复相关的功能，它们用来替代按时间点恢复来撤消对数据库的改变。闪回数据库能让你将整个数据库进行回滚，使用指定时间窗口来撤消对数据库的改变。这类似于数据库的按时间点恢复。

还原点提供了与闪回数据库相关的能力它是另一种恢复操作。受保护的还原点，在特定的情况下，提供了闪回数据库完整的功能，允许你选择一个SCN并强制要求闪回数据库对这个SCN是可用的。

还原点和闪回数据库可以单独使用也可以一起使用。在这两种情况下，RMAN的flashback database命令或者flashback database语句实际上将数据库还原到一个指定的SCN所对应的状态，例如：

flashback database to restore point ‘before_upgrade’;
flashback databasae to scn 202381;

闪回数据库
闪回数据库，可以通过RMAN的flashback database命令和SQL*Plus的flashback database语句来完成。能够将数据库快速的从逻辑数据错误或用户错误中进行恢复。

它类似于传统的按时间点恢复一样，能够将数据库还原到过去某个时间点的状态。闪回数据库比按时间点恢复来快很多，因为闪回数据库不需要从备份中还原数据文件和从归档重做日志文件中应用相应的改变。

闪回数据库能被用来撤消对数据库不需要的改变。而数据文件完好无损。这包括将数据库还原到之前数据库化身对应的状态。这将撤消open resetlogs操作。

闪回数据库使用它自己的日志机制，它会在闪回区中创建闪回日志。只有在闪回日志是可用时才能使用闪回数据库。因此如果要使用这个功能就必须对数据库进行设置让其创建相关的闪回日志。

为了启用闪回数据库，需要设置闪回区和设置闪回保留策略目标来指定能够将数据库还原到过去某个时间点。

从启用闪回数据库开始，在定期的时间间隔内，数据库将会把每个数据文件中发生改变的数据块复制到闪回日志中。这些数据块镜像以后可用来重构数据文件的内容。

当数据库使用闪回数据库将数据库还原到过去的某些目标时间点时，自从还原时间点开始发生改变的每个数据块将从闪回日志中复制目标时间点对应的数据块。然后应用自数据块被复制到闪回日志时间点开始的重做日志。

注意：在整个时间跨度对于闪回日志相应的重做日志必须都是可用的。

闪回数据库窗口
在一定范围SCN之间有足够的闪回日志数据来支持flashback database命令这就叫闪回数据库窗口。如果闪回区的空间太小，通过设置保留策略当为了给新生成的闪回日志文件分配空间可能会删除过期的闪回日志。根据闪回区的大小，必须被保留的其它备份和需要的闪回日志数据，这可能造成闪回数据库窗口比闪回保留目标的时间要短。

注意：闪回保留目标是一个目标，不是一个绝对受保护能执行闪回数据库的目标。

如果闪回区的大小不能存储为了满足保留策略所需要的闪回日志和其它文件，比如归档重做日志和其它备份。那么为了存储其它文件从最早的SCN开始的闪回日志可能因为空间问题而被删除。

闪回数据库窗口不能对可用闪回日志中的最早SCN进行向前的扩展。闪回日志不能备份到闪回区之外的目录。因此为了增加可用的闪回日志来满足闪回数据窗口，所以要给闪回区可用的最大存储空间。

这里也有一些操作比如删除表空间或收缩数据文件，这些是不能通过闪回数据进行撤消的。在这些操作执行之后，闪回窗口就会立即从这些操作之后重新计算。

如果因为闪回数据库窗口不满足flashback database的要求，按时间点恢复可以最大程度的完成相似的任务。

使用受保护的还原点是唯一能保证你使用闪回数据库能将数据库还原点指定时间点或闪回窗口的方法。

正常还原点
通过指定时间点或SCN来作为还原点的名称来创建还原点，在执行有restore point子句的命令时使用这种标签或别名来指定SCN。

如果可能对你执行的任何操作执行撤消，那么可以创建一个正常的还原点。还原点名称和SCN会被记录到控制文件中。如果后面需要使用闪回数据库，闪回表或按时间点恢复，可以使用还原点名称来指示这个目标时间来代替一个时间表达式或SCN。在可能被撤消的操作执行前定义一个正常的还原点来消除需要手工记录SCN的需要，或在执行闪回查询时查找正确的SCN的需要。

正常还原点是非常轻量级的。控制文件可以包含上千个正常还原点而不会影响数据库的性能。正常还原点最终从控制文件中移除，而不是手工删除，那么它们将不再需要进行维护。

支持还原点的命令
在下面的上下文中还原点用来指定目标SCN：
1.RMAN的recover database和flashback database命令

2.SQL*Plus中的flashback database语句

注意：通常来说，受保护的还原点可以在任何使用正常还原点的操作中作为SCN的别名来使用。除非另有说明，否则正常还原点的使用方法也适用于受保护的还原点。

受保护的还原点
与正常还原点一样，受保护的还原点在恢复操作中也能作为SCN的别名。然而，它们也对闪回数据库提供了特定的功能。

在一个特定的SCN创建一个受保护的还原点可以强制通过执行闪回数据库能将数据库还原到这个SCN所处的状态，即使数据库没有启用闪回日志也能保证。如果闪回日志被启用，创建受保护的还原点强制闪回日志保留策略能满足将数据库闪回到创建受保护还原点后的任意时间点。

受保护还原点能用于将整个数据库还原到一个已知的状态良好的时间点，前提条件是闪回区有足够的空间来存储闪回日志。使用闪回数据库，受nologging操作影响的直接路径插入也能使用受保护的还原点来进行还原操作。

受保护的还原点替代存储快照
在实践中，受保护的还原点能够有效地替代存储快照，它通常用来在一些危险操作之前来保护数据库，比如大范围的更新，应用程序打补丁，或者升级。与创建快照或复制数据库再进行这些操作的相比，可以创建一个受保护的还原点然后执行这些危险操作，只要确只保留必要的闪回日志就行。

闪回数据库和受保护还原点的日志
闪回数据库和受保护还原点的日志是基于在改变应用前被捕获的数据块镜像，因此这些镜像能用来在执行flashback database命令时将数据文件还原到之前时间点所对应的状态。

正常闪回日志和受保护还原点的日志的主要差别就是日志是否会因为闪回区可用空间的压力而被删除。这些差别影响日志可用空间的使用和数据库的性能。

是否对闪回数据库，受保护的还原点启用日志都依赖于你的恢复目标，以及对性能的影响和这些功能对空间的使用。

受保护还原点和闪回区的空间使用
当创建一个受保护的还原点，不管有没有启用完全闪回数据库日志，你都必须监控闪回区可用空间的状态。如果为了满足受保护的还原点而需要的文件是不会满足从闪回区删除的条件。因此，闪回日志的保留策略和为了满足受保护的还的所需要的其它文件，就是满足备份保留策略一样，可能会让闪回区完全被使用掉。

注意：当因为保留策略不能删除任何文件而又遇到空间被使用完的情况时，在许多情况下数据库会被hang住。

闪回日志禁用时受保护还原点日志
如果当闪回数据库日志禁用时创建了受保护的还原点，那么，在受保护还原点创建之后第一次数据文件的数据块更改，在更改之前数据块的镜像会被存储到闪回日志中。闪回日志因此能还原被修改的数据块回到受保护还原点创建时的状态。然而后续对相同数据块的修改不会被记录在日志中，除非在这些修改之前创建另外的受保护还原点。

这种方式的日志有以下重要的影响：
1.可用的块镜像可以在使用flashback database时将数据文件的内容还原到受保护还原点所对应的状态但不能使用flashback database将数据库还原到受保护还原点与当前时间之间的某个时间点。只有当对闪回数据库启用日志才行。如果你需要将数据库还原到一个中间时间点，你只能使用数据库按时间点恢复。

2.因为每个数据块的改变只会被记录一次，当闪回日志被禁用时受保护还原点的日志所使用的空间要比正常闪回日志所使用的空间小。可以按天或周来维护受保护的还原点而不必关注当闪回数据库启用后闪回日志的增长。记录受保护的还原点的日志所产生的性能在禁用闪回数据库日志的情况下影响是很小的。

如果你主要是将数据库还原到受保护还原点所创建的时间点，那么通常关闭闪回数据库日志只使用受保护还原点更有效。例如当正计划在生产数据库服务器上对应用进行升级，在升级开始之前创建一个受保护的还原点，如果升级过程最终失败，可以使用flashback database撤消改变，而不用从备份中进行还原。

使用受保护还原点的闪回数据库日志
如果闪回数据库被启用并且定义了一个或多个受保护的还原点，那么数据库执行正常闪回日志时，会对性能有些影响。根据数据库的工作模式闪回区可能会产生较大的空间压力。然而，不像正常的闪回数据库日志，闪回区总是要保留为了使用flashback database将数据库还原到最早的当前受保护还原点时所需要的闪回日志。闪回日志如果要求满足受保护还原点恢复就不会因为空间压力而被删除。

在这种情况下对于flashback database可以将数据库恢复到闪回窗口中的任意时间点和特定的受保护的还原点所对应的状态，但你必须监控制闪回区的空间使用。

使用正常和受保护还原点

使用受保护还原点的要求
为了支持使用受保护还原点，数据库必须满足下面的要求：
1.compatible参数必须设置为10.2或更高版本

2.数据库必须运行在归档模式下。flashback database操作将数据库还原到受保护的还原点时要求使用一直到还原点以来的归档重做日志。

3.必须设置闪回区.受保护的还原点使用了一种类似于闪回日志的机制，Oracle必须在闪回区存储所要使用的日志

4.如果没有启用闪回数据库，当创建第一个受保护的还原点心（或者如果所有之前创建的受保护的还原点已经被删除后）那么数据库必须处于mount状态，不能是open状态。

注意：在使用正常的还原点没有特殊的要求。

创建正常和受保护还原点
为了创建正常或受保护还原点，使用create restore point语句，并给还原点提供了一个名称并指定它是受保护还原点还是正常还原点（默认值）。

在创建还原点时数据库可以处于open或mount状态。如果是mount状态，那么必须已经完全关闭（物理备库除外）。

下面的命令用来创建一个正常还原点

SQL> create restore point before_truncate;

Restore point created.

下面的命令用来创建一个受保护还原点

SQL> create restore point before_truncate guarantee flashback database;
create restore point before_truncate guarantee flashback database
*
ERROR at line 1:
ORA-38784: Cannot create restore point 'BEFORE_TRUNCATE'.
ORA-38787: Creating the first guaranteed restore point requires mount mode when flashback database is off.

根据错误提示可以看出当数据库没有启用flashback database时想要创建受保护的还原点只能在mount状态下创建。

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.
SQL> create restore point before_truncate guarantee flashback database;

Restore point created.


SQL> col name for a20
SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
  2  GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
  3  FROM V$RESTORE_POINT;

NAME                        SCN TIME                                DATABASE_INCARNATION# GUARANTEE_FLASHBACK_DATABASE STORAGE_SIZE
-------------------- ---------- ----------------------------------- --------------------- ---------------------------- ------------
BEFORE_TRUNCATE         2849315 27-JAN-15 02.40.56.000000000 PM                         2 YES                          8192000

显示还原点
为了查看当前定义的还原点，可以使用v$restore_point控制文件视图：

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
FROM V$RESTORE_POINT;

SQL> col name for a20
SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
  2  GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
  3  FROM V$RESTORE_POINT;

NAME                        SCN TIME                                DATABASE_INCARNATION# GUARANTEE_FLASHBACK_DATABASE STORAGE_SIZE
-------------------- ---------- ----------------------------------- --------------------- ---------------------------- ------------
BEFORE_TRUNCATE         2849315 27-JAN-15 02.40.56.000000000 PM                         2 YES                          8192000

可以看到每个还原点的名称，SCN，时间和还原点创建时的数据库对应化身的序列号，是正常还原点还是受保护还原点，以及为了提供足够的信息来支持闪回数据库操作该还原点在闪回区所使用的空间大小。

可以使用只查询受保护的还原点信息：

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE
FROM V$RESTORE_POINT
WHERE GUARANTEE_FLASHBACK_DATABASE='YES';


SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
  2  GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE
  3  FROM V$RESTORE_POINT
  4  WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

NAME                        SCN TIME                                                                        DATABASE_INCARNATION# GUARANTEE_FLASHBACK_DATABASE   STORAGE_SIZE
-------------------- ---------- --------------------------------------------------------------------------- --------------------- ------------------------------ ------------
BEFORE_TRUNCATE         2849315 27-JAN-15 02.40.56.000000000 PM                                                                 2 YES                                 8192000

对于正常还原点，storage_size为0。对于受保护的还原点storage_size指示了为了保证能对还原点执行flashback database操作所要保留日志所消耗的闪回区的空间大小。

下面的正常还原点的storage_size确实为0:

SQL> SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
  2  GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE
  3  FROM V$RESTORE_POINT
  4  WHERE GUARANTEE_FLASHBACK_DATABASE='YES';

NAME                        SCN TIME                                                                        DATABASE_INCARNATION# GUARANTEE_FLASHBACK_DATABASE   STORAGE_SIZE
-------------------- ---------- --------------------------------------------------------------------------- --------------------- ------------------------------ ------------
BEFORE_TRUNCATE         2849315 27-JAN-15 02.40.56.000000000 PM                                                                 2 YES                                 8192000



SQL> select count(*) from tt;

  COUNT(*)
----------
     51281

SQL> truncate table tt;

Table truncated.

SQL> select count(*) from tt;

  COUNT(*)
----------
         0


SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.
SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED

SQL>  select  flashback_on from v$database;

FLASHBACK_ON
------------------
RESTORE POINT ONLY

SQL> flashback database to restore point before_truncate;

Flashback complete.



SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open


SQL>  alter database open resetlogs;

Database altered.

SQL> select count(*) from tt;

  COUNT(*)
----------
     51281

删除还原点
当不再需要已经存在的还原点时或者想用已经存在的还原点名称来创建一个新的还原点时就可以删除该还原点，下面使用dorp restore point语句还删除还原点：

SQL> drop restore point before_truncate;

Restore point dropped.

drop restore point用于删除正常还原点受保护还原点。

注意：正常还原不管有没有被显式删除最终都会从控制文件中删除。控制文件中还原点保留规则如下：
1.在控制文件中总是会保留最近的2048个还原点
2.只有还原点比比control_file_record_keep_time值所保留的还原点更新，而不管定义还原点的个数

正常还原点只要不满足上述条件就会从控制文件中删除。
受保护还原点从不会因为自动地从控制文件中删除，除非显式删除它们。

监控受保护还原点的空间使用情况
当在数据库中定义受保护还原点后，应该监控为了满足还原点而被存储的相关文件在闪回区中的空间使用情况。可以使用下面的查询语句查看storage_size列来判断每个受保护还原点相关文件的大小。

SELECT NAME, SCN, TIME, DATABASE_INCARNATION#,
GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
FROM V$RESTORE_POINT;

为了查看闪回区的使用大小可以查询v$recovery_file_dest和v$flash_recovery_area_usage视图:

SQL> select * from v$recovery_file_dest;

NAME                                                                             SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
-------------------------------------------------------------------------------- ----------- ---------- ----------------- ---------------
/u01/app/oracle/flash_recovery_area                                               2147483648    9699328           9699328               1
SQL> select * from v$flash_recovery_area_usage;

FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE                   0                         0               0
ONLINELOG                     0                         0               0
ARCHIVELOG                    0                         0               0
BACKUPPIECE                   0                         0               0
IMAGECOPY                  0.45                      0.45               1
FLASHBACKLOG                  0                         0               0

Oracle闪回数据库的设置与维护

闪回数据库的限制
因为阀回数据库是用来撤消某一时刻对数据文件所做的改变，因此它有以下限制：
1.闪回数据库只能撤消对数据文件的改变。它不能用于修复介质故障或者对意外删除的数据文件进行恢复。

2.不能使用闪回数据库来撤消对数据文件的收缩操作

3.如果数据库的控制文件从备份中进行了还原或者重新创建了控制文件，那么之前所累积的闪回日志信息将会被废弃。不能使用flashback database将数据库还原到还原控制文件或重新创建控制文件之前的某个时间点。

4.使用闪回数据库还原到某个时间点时，如果在这个时间点数据库正在执行nologging操作，那么在闪回数据库完成之后，受nologging操作影响的对象和数据文件可能存在坏块。例如，如果在2015-01-27的9:00到9:15正在以nologging模式执行直接路径插入操作，而后来你需要使用闪回数据库将数据库还原到2015-01-27的9:07分所对应的状态，那么在闪回数据库操作完成之后，由直接路径插入操作相关的对象和数据文件可有坏块。

如果可能要避免闪回数据库将数据库还原有nologging操作的时间点。也可以在任何nologging操作之后为了确保能恢复到该操作之后某个时间点可以执行全备或增量备份。如果你期望使用闪回数据库将数据库还原到某个操作执行的时间点，比如直接路径插入，可以考虑在logging模式下执行这些操作。

启用闪回数据库的条件
启用闪回数据库需要满足以下条件：
1.数据库必须运行在archivelog模式下，因为在执行闪回数据库操作时需要归档重做日志

2.必须设置闪回区，因为闪回日志只能存储在闪回区中

3.对于RAC环境中的数据库，闪回区必须是可以共享访问的集簇文件系统或者ASM

启用闪回日志
为了对闪回数据库启用闪回日志，要设置db_flashback_retention_target初始化参数并执行alter database flashback on语句。下面是启用闪回日志的过程：
1.确保数据库处于mount状态而不是open状态。例如：

SQL> shutdown immediate

SQL> startup mount

2.可选操作，可以将db_flashback_retention_target参数的值设置为你所期待的闪回窗口以分钟为单位

SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days

db_flashback_retention_target的默认值是一天(1440分钟）

3.使用v$database.FLASHBACK_ON可以查看闪回日志是否已启用，现在是“NO”，表示尚未启用：

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
NO

4.对整个数据库启用闪回数据库功能：

SQL> ALTER DATABASE FLASHBACK ON;

从此，在快速恢复区的flashback子目录下将会出现扩展名为.flb的文件，它们就是闪回日志。

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
YES

闪回数据库命令的语法很简单：在进入MOUNT状态后执行flashback database to scn xxx 或flashback database to timestamp xxx 。

一次闪回数据库操作可能由两种方式进行。比如，令当前时间点为T_C，数据库闪回的目标时间点为T_1（T_C大于T_1），使用的命令为“flashback database to timestamp T_1”，该命令会自动选择以下两种方式的其中一个进行闪回操作。

方式一：

（1）第一阶段：利用闪回日志将数据库从T_C回退至较T_1更旧的某一时刻T_2。
（2）第二阶段：利用重做日志将数据库从T_2前滚至T_1。

方式二：

（1）第一阶段：确定一个比T_1更旧的某一时刻T_2。
（2）第二阶段：对于闪回日志根本无法恢复的对象或数据，把当初此类对象第一次产生的时间为T_3，首先利用T_3到T_2的重做日志将其重新产生并恢复。
（3）第三阶段：利用闪回日志将数据库从T_C回退至T_2。
（4）第四阶段：利用重做日志将数据库从T_2前滚至T_1（途中经过T_2）。

究竟采用哪种方式执行取决于目标时间点T_1与当前时间点T_C之间执行过什么命令，如果是在闪回日志中有对应反向操作的命令（如insert、update、delete）就采用方式一；如果在闪回日志中找不到对应反向操作的命令（比如：truncate命令）则采用方式二。方式二较方式一可能会索要更多的重做日志才可以完成闪回。

比如，若有任何对象发生过截断操作（truncate table xxx），那么方式二中的T3就是当初创建被截断的表的时刻，这意味着整个闪回操作需要从T3至T1的所有的重做日志，否则闪回数据库不可能成功。这样，可能会发生这样的问题：即使只是在10秒前错误地截断了一张表，现需要回到10秒之前，但是闪回数据库时flashback database命令向管理员索要几年前的归档日志！

如果T_1和T_C之间只是发生过类似update那样的DML，若是想回到10秒前，那么会采用方式一，差不多只是需要10秒的闪回日志和归档日志，闪回会很快，这也是闪回的真谛。

无论哪种方式，都可能遇到重做日志不充分的问题,下面来模拟这种情况：

1.检查数据库是否启用了闪回数据库，从下面的查询结果可知当前数据库没有启用闪回数据库

SQL> select flashback_on from v$database;

FLASHBACK_ON
------------------
NO

2.创建一个测试表，该表共有51282条记录

SQL> create table jy as select * from dba_objects;

Table created.

SQL> select count(*) from jy;

  COUNT(*)
----------
     51282

3.查询一下当前数据库的SCN号

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN
-----------
    2879920

4.重启数据库并启用闪回数据库

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.
SQL> alter database flashback on;

Database altered.

SQL> alter database open;

Database altered.

5.向表jy中增加一倍的记录

SQL> insert into jy select * from jy;

51282 rows created.

SQL> commit;

Commit complete.

SQL> select count(*) from jy;

  COUNT(*)
----------
    102564

6.查询当前数据库的SCN号

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

CURRENT_SCN
-----------
    2880218

7.执行闪回数据库，将表jy的记录恢复到只有51282条记录

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.


SQL> flashback database to scn 2879920;
flashback database to scn 2879920
*
ERROR at line 1:
ORA-38754: FLASHBACK DATABASE not started; required redo log is not available
ORA-38762: redo logs needed for SCN 2879811 to SCN 2879920
ORA-38761: redo log sequence 19 in thread 1, incarnation 2 could not be accessed

也可能遇到闪回日志不够的问题，报错信息如下所示：

SQL> flashback database to scn 2879920;
flashback database to scn 2879920
*
ERROR at line 1:
ORA-38729: Not enough flashback database log data to do FLASHBACK.

这里之所以不能闪回到SCN为2879920的时间点，是因为那时数据库没有启用闪回。

8.查看一下v$flashback_database_log视图，检查最远可以回到哪里

SQL> select oldest_flashback_scn,
  2  to_char(oldest_flashback_time,'YYYY-MM-DD HH24:MI:SS')
  3  from v$flashback_database_log;

OLDEST_FLASHBACK_SCN TO_CHAR(OLDEST_FLAS
-------------------- -------------------
             2880101 2015-01-27 23:32:18

从查询结果可以看到数据库最远可以闪回到SCN号为2880101的时间点

9.在MOUNT状态发起闪回操作后，管理员可以反复地以任何顺序执行这3个命令：flashback database to xxx,recover database和alter database open read only

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.

SQL> flashback database to scn 2880210;

Flashback complete.

SQL> alter database open read only;

Database altered.

SQL> select count(*) from jy;

  COUNT(*)
----------
    102564

从上述结果可以看到现在将数据库闪回到SCN为2880210的时间点，表jy的记录数为102564不是我们期待的51282

10.再次将数据库闪回到SCN号为2880150的时间点

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.


SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.
SQL> flashback database to scn 2880150;

Flashback complete.

SQL> alter database open read only;

Database altered.

SQL> select count(*) from jy;

  COUNT(*)
----------
     51282

从上述结果可以看到将数据库闪回到SCN为2880150的时间点时表jy的记录为51282达到我们期待的结果。

11.完成闪回数据库的最后操作。

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.

SQL> alter database open resetlogs;

Database altered.

SQL>  select count(*) from jy;

  COUNT(*)
----------
     51282

默认情况下对于所有永久表空间都会生成闪回日志。你也可以通过对指定的表空间来禁用闪回日志来减少开销：
SQL> ALTER TABLESPACE users FLASHBACK OFF;

可以使用下面的命令对表空间重新启用闪回日志:
SQL>alter tablespace users flashback on;

注意如果对一个表空间禁用了闪回数据库，那么在执行flashback database之前要确保该表空间的数据文件处于脱机状态。

对整个数据库禁用闪回日志：
SQL>alter database flashback off;

RMAN的改变跟踪
RMAN的改变跟踪功能通过在改变跟踪文件中记录每一个数据文件发生改变的数据块来提高增量备份的性能。如果改变跟踪被启用，RMAN使用改变跟踪文件来标识自上次增量备份以来发生改变的数据块，这样就能避免扫描每个数据文件的所有数据块。

在启用改变跟踪后，第一次level 0级的增量备份仍然会扫描每个数据文件的所有数据块，这时改变跟踪文件不能反应数据块的状态。后续的增量备份将使用level 0级的增量备份作为父备份集这样就可以利用改变跟踪文件来进行增量备份。

使用改变跟踪不会改变执行增量备份的命令，改变跟踪本身在设置后通常需要较少的维护。

改变跟踪默认情况下是禁用的，因为它在数据库的正常操作期间会有一些小的性能开销。然而，为了在备份期间对数据文件执行完全扫描，且在两次备份期间只有少量数据块发生改变时，使用改变跟踪就是很有用的。如果你的备份策略使用增量备份，那么应该启用改变跟踪。

一旦对整个数据库创建了改变跟踪文件，默认情况下改变跟踪文件所生成的目录是由
db_create_file_dest参数来决定的。也可以在启用改变跟踪时指定改变跟踪的文件名和存储目录。

注意：在RAC环境下，为了让所有的节点都能使用改变跟踪文件应该将改变跟踪文件存储在共享存储中

Oracle保存足够的改变跟踪文件能让增量备份使用最近8个增量备份作为它的父备份。

虽然RMAN不支持对改变跟踪文件本身的备份和恢复，如果整修数据库或部分需要还原和恢复，那么恢复对改变跟踪没有影响。在还原和恢复之后，改变跟踪文件会被清除，并再次开始记录数据块的改变。在任何恢复之后下一次的增量备份都能够使用改变跟踪的数据。

启用或禁用块改变跟踪
存储块改变跟踪文件的目录是由db_create_file_dest参数来设置的，下面的语句用来启用块改变跟踪：

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

还可以在启用块改变跟踪时指定块改变跟踪文件创建的目录

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
USING FILE '/mydir/rman_change_track.f' REUSE;

REUSE选项告诉Oracle会覆盖已经存在的块跟踪文件

为了禁用块改变跟踪：

SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

如果块改变跟踪文件存储在数据库区域，当禁用改变跟踪时会删除。

SQL> alter database enable block change tracking using file '/u01/app/oracle/rman_change_trace.f' reuse;

Database altered.

检查是否生成了改变跟踪文件

[root@oracle11g oracle]# ls -lrt
total 11632
drwxr-xr-x  3 oracle oinstall     4096 Sep  5 08:47 10.2.0
drwxrwxr-x  3 oracle oinstall     4096 Sep  5 09:12 oradata
drwxr-x---  3 oracle oinstall     4096 Sep  5 09:12 admin
drwxrwxr-x  3 oracle oinstall     4096 Sep  5 09:13 flash_recovery_area
-rw-r--r--  1 oracle oinstall   226495 Nov 18 10:55 utlu112i_8.sql
-rw-r--r--  1 oracle oinstall    10373 Nov 18 11:02 upgrade_info.log
drwxr-xr-x  3 root   root         4096 Nov 18 21:00 11.2.0
drwxrwx---  7 oracle oinstall     4096 Nov 18 21:37 oraInventory
drwxrwxr-x 11 oracle oinstall     4096 Nov 18 21:37 diag
drwxr-xr-x  2 oracle oinstall     4096 Nov 18 21:39 checkpoints
drwxr-x---  5 oracle oinstall     4096 Nov 19 18:55 cfgtoollogs
-rw-r--r--  1 oracle oinstall     3261 Nov 23 21:24 upchk.log
-rw-r--r--  1 oracle oinstall     2237 Nov 26 11:55 downgrade.log
-rw-r-----  1 oracle oinstall 11600384 Jan 26 21:32 rman_change_trace.f

禁用块改变跟踪：

SQL> alter database disable block change tracking;

Database altered.

检查是否删除了生成的改变跟踪文件

[root@oracle11g oracle]# ls -lrt
total 284
drwxr-xr-x  3 oracle oinstall   4096 Sep  5 08:47 10.2.0
drwxrwxr-x  3 oracle oinstall   4096 Sep  5 09:12 oradata
drwxr-x---  3 oracle oinstall   4096 Sep  5 09:12 admin
drwxrwxr-x  3 oracle oinstall   4096 Sep  5 09:13 flash_recovery_area
-rw-r--r--  1 oracle oinstall 226495 Nov 18 10:55 utlu112i_8.sql
-rw-r--r--  1 oracle oinstall  10373 Nov 18 11:02 upgrade_info.log
drwxr-xr-x  3 root   root       4096 Nov 18 21:00 11.2.0
drwxrwx---  7 oracle oinstall   4096 Nov 18 21:37 oraInventory
drwxrwxr-x 11 oracle oinstall   4096 Nov 18 21:37 diag
drwxr-xr-x  2 oracle oinstall   4096 Nov 18 21:39 checkpoints
drwxr-x---  5 oracle oinstall   4096 Nov 19 18:55 cfgtoollogs
-rw-r--r--  1 oracle oinstall   3261 Nov 23 21:24 upchk.log
-rw-r--r--  1 oracle oinstall   2237 Nov 26 11:55 downgrade.log

SQL> select filename from v$block_change_tracking;

FILENAME
——————————————————————————–
/u01/app/oracle/rman_change_trace.f

2.关闭数据库.

SQL> shutdown immediate

Database closed.
Database dismounted.
ORACLE instance shut down.

3.使用操作系统命令将块改变跟踪文件移动到新的位置

[root@oracle11g oracle]# mv rman_change_trace.f rman_change_trace_new.f

4.mount数据库，更改块改变跟踪文件

SQL> startup mount
ORACLE instance started.

Total System Global Area  327155712 bytes
Fixed Size                  1273516 bytes
Variable Size             138412372 bytes
Database Buffers          184549376 bytes
Redo Buffers                2920448 bytes
Database mounted.
SQL> alter database rename file '/u01/app/oracle/rman_change_trace.f' to '/u01/app/oracle/rman_change_trace_new.f';

Database altered.

5.打开数据库

SQL> alter database open;

Database altered.

SQL> alter database disable block change tracking;

Database altered.

[root@oracle11g oracle]# ls -lrt
total 284
drwxr-xr-x  3 oracle oinstall   4096 Sep  5 08:47 10.2.0
drwxrwxr-x  3 oracle oinstall   4096 Sep  5 09:12 oradata
drwxr-x---  3 oracle oinstall   4096 Sep  5 09:12 admin
drwxrwxr-x  3 oracle oinstall   4096 Sep  5 09:13 flash_recovery_area
-rw-r--r--  1 oracle oinstall 226495 Nov 18 10:55 utlu112i_8.sql
-rw-r--r--  1 oracle oinstall  10373 Nov 18 11:02 upgrade_info.log
drwxr-xr-x  3 root   root       4096 Nov 18 21:00 11.2.0
drwxrwx---  7 oracle oinstall   4096 Nov 18 21:37 oraInventory
drwxrwxr-x 11 oracle oinstall   4096 Nov 18 21:37 diag
drwxr-xr-x  2 oracle oinstall   4096 Nov 18 21:39 checkpoints
drwxr-x---  5 oracle oinstall   4096 Nov 19 18:55 cfgtoollogs
-rw-r--r--  1 oracle oinstall   3261 Nov 23 21:24 upchk.log
-rw-r--r--  1 oracle oinstall   2237 Nov 26 11:55 downgrade.log

如果不能关闭数据库，那么你必须禁用改变跟踪，再在重新启用时指定新的目录。例如：

ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';

如果你选择使用这种方法，将会丢失改变跟踪文件中的内容。直到你下次完成level 0级的增量备份之前，RMAN将不得不扫描整个文件

评估改变跟踪文件的大小
改变跟踪文件的大小与数据库的大小和重做日志线程数成正比。它的大小不与数据库的频繁更新相关。通常来说块改变跟踪所需要的空间大小是将被跟踪的数据块大小的1/30000。注意，然而下面的两种原因可能会让改变跟踪文件比评估的大小大很多：
1.为了避免随着数据库的增长而要给改变跟踪文件分配空间所产生的开销，改变跟踪文件一开始创建时就是10M，并且以10M的大小来增加。因此对于任何大小接近300G的数据库来说，改变跟踪文件的大小不小于10M，对于大小接近600G的数据库来说，改变跟踪文件的大小不小于20M，依此类推。

2.对于每个数据文件，不管改变跟踪文件有多大都会在改变跟踪文件中将分配320K的空间。因此，如果有大量的小数据文件，改变跟踪文件将会比包含同样数据量的少量的大数据文件对应的改变跟踪文件大