Oracle - RMAN备份 之 incarnation的实验和小结

　　对于RMAN恢复我一直都不是很明白,因为,老是搞不清楚不完全恢复该怎么进行,今天,通过这个实验即是对不完全恢复的实践,
也是希望搞清楚incarnation到底是怎么工作的.很可惜,本人对Oracle的了解还不入门,仅能做一点提示.在文末做为小结.

RMAN> list backup;

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

BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
1       Full    559.92M    DISK        00:01:08     2016-08-13 20:17:08        =============[第一个时间点]==========
        BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20160813T201600
        Piece Name: /home/oracle10/flash_recovery_area/DBINFO/backupset/2016_08_13/o1_mf_nnndf_TAG20160813T201600_cty3w0sx_.bkp
  List of Datafiles in backup set 1
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  1       Full 1080165    2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/system01.dbf
  2       Full 1080165    2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/undotbs01.dbf
  3       Full 1080165    2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/sysaux01.dbf
  4       Full 1080165    2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/users01.dbf
  5       Full 1080165    2016-08-13 20:16:00 /home/oracle10/oradata/dbinfo/gias01.dbf

BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
2       Full    6.80M      DISK        00:00:02     2016-08-13 20:17:17
        BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20160813T201600
        Piece Name: /home/oracle10/flash_recovery_area/DBINFO/backupset/2016_08_13/o1_mf_ncsnf_TAG20160813T201600_cty3yffw_.bkp
  Control File Included: Ckp SCN: 1080190      Ckp time: 2016-08-13 20:17:15
  SPFILE Included: Modification time: 2016-08-13 20:09:59

BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
3       Full    560.05M    DISK        00:00:18     2016-08-13 20:26:33         =============[第二个时间点]==========
        BP Key: 3   Status: AVAILABLE  Compressed: NO  Tag: TAG20160813T202615
        Piece Name: /home/oracle10/orabak/fulldb_20160813_919801575
  List of Datafiles in backup set 3
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  1       Full 1080933    2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/system01.dbf
  2       Full 1080933    2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/undotbs01.dbf
  3       Full 1080933    2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/sysaux01.dbf
  4       Full 1080933    2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/users01.dbf
  5       Full 1080933    2016-08-13 20:26:15 /home/oracle10/oradata/dbinfo/gias01.dbf

BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
4       Full    6.80M      DISK        00:00:01     2016-08-13 20:26:41
        BP Key: 4   Status: AVAILABLE  Compressed: NO  Tag: TAG20160813T202615
        Piece Name: /home/oracle10/orabak/fulldb_20160813_919801600
  Control File Included: Ckp SCN: 1080941      Ckp time: 2016-08-13 20:26:40
  SPFILE Included: Modification time: 2016-08-13 20:09:59

BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
5       Full    561.88M    DISK        00:00:19     2016-08-13 20:34:29            =============[第三个时间点]==========
        BP Key: 5   Status: AVAILABLE  Compressed: NO  Tag: TAG20160813T203410
        Piece Name: /home/oracle10/orabak/db_full_bak_20160813_919802050
  List of Datafiles in backup set 5
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  1       Full 1081829    2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/system01.dbf
  2       Full 1081829    2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/undotbs01.dbf
  3       Full 1081829    2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/sysaux01.dbf
  4       Full 1081829    2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/users01.dbf
  5       Full 1081829    2016-08-13 20:34:10 /home/oracle10/oradata/dbinfo/gias01.dbf

BS Key  Type LV Size       Device Type Elapsed Time Completion Time    
------- ---- -- ---------- ----------- ------------ -------------------
6       Full    6.80M      DISK        00:00:01     2016-08-13 20:34:36
        BP Key: 6   Status: AVAILABLE  Compressed: NO  Tag: TAG20160813T203410
        Piece Name: /home/oracle10/orabak/db_full_bak_20160813_919802075
  Control File Included: Ckp SCN: 1081837      Ckp time: 2016-08-13 20:34:35
  SPFILE Included: Modification time: 2016-08-13 20:09:59

从上面查看备份集的输出可知,当前有三个可用的备份集.分别是:
    1. 2016-08-13 20:17:08
    2. 2016-08-13 20:26:33
    3. 2016-08-13 20:34:29
现在的情况是,已经进行了一次完全恢复,使用的是 第3个时间点的全备.但现在需要恢复第2个时间点的全备.
注: 进行基于时间的备份时需要先导出指定日期格式的变量: export NLS_DATE_FORMAT='yyyy-mm-dd hh24:mi:ss';  
RMAN> run {
set until time='2016-08-13 20:26:33';
restore database;
recover database;
alter database open resetlogs;
}

executing command: SET until clause
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of set command at 08/13/2016 23:42:18
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

恢复时,出现了RMAN-20207的错误,这是进行恢复时,经常会出的错误.这是因为,我们先前恢复了第3个时间点
的全备,并进行了resetlogs,那么Oracle将的incarnation将加1,可以理解为Oracle将resetlogs前的备份集做为上层,
resetlogs后,重新建了一个层,开始重新记录信息.  我们现在要恢复上一层的备份集,就必须先回到上一层.

RMAN> list incarnation;            #查看当前有几个incarnation.

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DBINFO   3196490228       PARENT  1          2005-10-22 21:44:08
2       2       DBINFO   3196490228       PARENT  525876     2015-06-20 21:23:03
3       3       DBINFO   3196490228       CURRENT 1081970    2016-08-13 23:39:33    #这是当前层.

RMAN> reset database to incarnation 2;

RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DBINFO   3196490228       PARENT  1          2005-10-22 21:44:08
2       2       DBINFO   3196490228       CURRENT 525876     2015-06-20 21:23:03    #此时,它变成了当前层.
3       3       DBINFO   3196490228       ORPHAN  1081970    2016-08-13 23:39:33
4       4       DBINFO   3196490228       ORPHAN  1081972    2016-08-14 00:05:20

RMAN> run {
set until time='2016-08-13 20:26:33';        #使用第二次备份的时间点来进行不完全恢复.
restore database;
recover database;
alter database open resetlogs;
}

executing command: SET until clause

Starting restore at 2016-08-14 00:14:50
using channel ORA_DISK_1
.......
piece handle=/home/oracle10/orabak/fulldb_20160813_919801575 tag=TAG20160813T202615        #可以看到这里使用第二次的备份集.
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55
Finished restore at 2016-08-14 00:15:45

恢复完成后,再次查看incarnation：
RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DBINFO   3196490228       PARENT  1          2005-10-22 21:44:08
2       2       DBINFO   3196490228       PARENT  525876     2015-06-20 21:23:03
5       5       DBINFO   3196490228       CURRENT 1080958    2016-08-14 00:15:47    #当前层在这里.
3       3       DBINFO   3196490228       ORPHAN  1081970    2016-08-13 23:39:33
4       4       DBINFO   3196490228       ORPHAN  1081972    2016-08-14 00:05:20

这时,我们继续将恢复的数据文件gias01.dbf 删除.然后,直接执行:
restore database;        #发现恢复的是第二次备份的全备集.
recover database;
alter database open resetlogs;    #并且,执行它时会报错,因为,Oracle不认为这是不完全恢复.
alter database open;             #因此,直接此命令即可打开数据库.查看incarnation没有发生变化。

那现在要重新恢复第三次备份的备份集,要怎么做?
1. 重新关库,删除gias01.dbf
2. 重设incarnation 为4.
RMAN> reset database to incarnation 4;

RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DBINFO   3196490228       PARENT  1          2005-10-22 21:44:08
2       2       DBINFO   3196490228       PARENT  525876     2015-06-20 21:23:03
5       5       DBINFO   3196490228       ORPHAN  1080958    2016-08-14 00:15:47
3       3       DBINFO   3196490228       ORPHAN  1081970    2016-08-13 23:39:33
4       4       DBINFO   3196490228       CURRENT 1081972    2016-08-14 00:05:20    #可以看到现在已经修改成功.

3. 尝试手动恢复:
restore database;        #这次恢复的是第三次备份的全备集.
recover database;
执行recover database时,出现下面错误，可忽略:
    RMAN-03002: failure of recover command at 06/24/2015 16:02:25
    RMAN-06054: media recovery requesting unknown log: thread 1 scn 277200603

4.进入sqlplus尝试打开数据库:
alter database open resetlogs;    #成功打开.

5.再次查看incarnation：
RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DBINFO   3196490228       PARENT  1          2005-10-22 21:44:08
2       2       DBINFO   3196490228       PARENT  525876     2015-06-20 21:23:03
5       5       DBINFO   3196490228       ORPHAN  1080958    2016-08-14 00:15:47
3       3       DBINFO   3196490228       ORPHAN  1081970    2016-08-13 23:39:33
6       6       DBINFO   3196490228       CURRENT 1081972    2016-08-14 00:39:49    #现在第6层
4       4       DBINFO   3196490228       PARENT  1081972    2016-08-14 00:05:20

实验到此,我又尝试了reset database to incarnation 2; 然后,使用时间恢复第一次备份集,
成功,incarnation+1后为7,然后,我再次回到2,尝试使用时间恢复第一次备份,竟然失败了,然后,
我尝试使用时间恢复第一/二/三都不成功,但可以直接使用restore database来恢复.
    我依然没有完全理解,从实验上看,没次resetlogs后,该层上将记录此次恢复备份集的信息,
并且上个当前层上关于该备份集的信息将被删除。

后记:
    此次实验到最后,出现了一个问题,incarnation 被搞混乱了,我把所有的备份集都删除了,然后,
重新做了两次RMAN全备,每次都看incarnation有什么变化没,结果因为先前reset database to incarnation 3;
两次全备的信息似乎都没有记录到incarnation 3这层,无论我怎么切换,直接用restore database 或 基于时间的
恢复都提示找不到数据文件,将incarnation功能关闭也无法恢复.最终的解决方案是,重建控制文件来解决.

经测试重建控制文件可以重置incarnation.
    这里有需要注意重建控制文件时: resetlogs与noresetlogs的区别
        norestlogs: 控制文件的scn是来自当前日志的最大scn。
        resetlogs:  控制文件的scn是来自数据文件。
    重建控制文件的脚本:
        1. 从$ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log ,从警告日志中找.
        2. 手动写.
        参考样本:
            Create controlfile reuse database "dbinfo" noresetlogs archivelog
            MAXINSTANCES 8
            MAXLOGHISTORY 1
            MAXLOGFILES 16
            MAXLOGMEMBERS 3
            MAXDATAFILES 100
            LOGFILE
            GROUP 1 '/home/oracle10/oradata/dbinfo/redo01.log' SIZE 51200K,
            GROUP 2 '/home/oracle10/oradata/dbinfo/redo02.log' SIZE 51200K,
            GROUP 3 '/home/oracle10/oradata/dbinfo/redo03.log' SIZE 51200K
            -- STANDBY LOGFILE
            Datafile
            '/home/oracle10/oradata/dbinfo/system01.dbf',
            '/home/oracle10/oradata/dbinfo/undotbs01.dbf',
            '/home/oracle10/oradata/dbinfo/sysaux01.dbf',
            '/home/oracle10/oradata/dbinfo/users01.dbf',
            '/home/oracle10/oradata/dbinfo/gias01.dbf'
            CHARACTER SET ZHS16GBK
            ;
      写好重建控制文件的脚本后,启动Oracle到nomount：
　　　　SQL> startup  nomount
　　　   SQL> @/tmp/create-control-file.sql