关于alter database open resetlogs及incarnation的一点理解

关于alter database open resetlogs及incarnation的一点理解

不完全恢复只能做一次吗？

采用rman的默认设置，对数据库进行了backup database备份，进行了一些操作后，然后直接关闭启动到mount状态

RMAN> run{

2> set until time "to_date('2010-10-16 23:14:42','yyyy-mm-dd hh24:mi:ss')";

3> restore database;

4> recover database;

5> }

executing command: SET until clause

Starting restore at 17-OCT-10

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=156 devtype=DISK

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00001 to /oracle/oradata/denver/system01.dbf

restoring datafile 00002 to /oracle/oradata/denver/undotbs01.dbf

restoring datafile 00003 to /oracle/oradata/denver/sysaux01.dbf

restoring datafile 00004 to /oracle/oradata/denver/users01.dbf

restoring datafile 00005 to /oracle/oradata/denver/example01.dbf

channel ORA_DISK_1: reading from backup piece /oracle/flash_recovery_area/DENVER/backupset/2010_10_16/o1_mf_nnndf_TAG20101016T230845_6cmhzz8t_.bkp

channel ORA_DISK_1: restored backup piece 1

piece handle=/oracle/flash_recovery_area/DENVER/backupset/2010_10_16/o1_mf_nnndf_TAG20101016T230845_6cmhzz8t_.bkp tag=TAG20101016T230845

channel ORA_DISK_1: restore complete, elapsed time: 00:01:26

Finished restore at 17-OCT-10

Starting recover at 17-OCT-10

using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 10 is already on disk as file /oracle/archivelog/1_10_732510268.dbf

archive log filename=/oracle/archivelog/1_10_732510268.dbf thread=1 sequence=10

media recovery complete, elapsed time: 00:00:01

Finished recover at 17-OCT-10

RMAN> alter database open resetlogs;

database opened

发现刚才恢复的时间23:14:42有点早，于是想改为恢复时间点为23:17:26，于是再次关闭数据库，mount状态下，但是出错了

RMAN> run {

2> set until time "to_date('2010-10-16 23:17:26','yyyy-mm-dd hh24:mi:ss')";

3> restore database;

4> recover database;

5> }

executing command: SET until clause

using target database control file instead of recovery catalog

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of set command at 10/17/2010 00:45:40

RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

时间再前点恢复也不行：

RMAN> run {

2> set until time "to_date('2010-10-16 23:14:40','yyyy-mm-dd hh24:mi:ss')";

3> restore database;

4> recover database;

5> }

executing command: SET until clause

using target database control file instead of recovery catalog

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of set command at 10/17/2010 01:17:03

RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

这是为什么？那些归档都还在，难道我的rman做过一次不完全恢复后，就不能再不完全恢复了，跟有没有换备份控制文件有关系吗？里面做了什么呢？

RMAN> list incarnation;

using target database control file instead of recovery catalog

List of Database Incarnations

DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time

------- ------- -------- ---------------- --- ---------- ----------

1       1       DENVER   4021391415       PARENT  1          22-OCT-05

2       2       DENVER   4021391415       PARENT  525876     16-OCT-10

3       3       DENVER   4021391415       CURRENT 620239     17-OCT-10

问题解决：

先要弄清楚alter database open resetlogs是什么意思，为什么要用resetlogs打开数据库，这个命令发出后oracle都做了什么？

alter database open resetlogs是要打开数据时，重置重做日志，即将重做日志的sequence置零，为什么要重置重做日志呢？

不完全恢复后，原来的online redo log里面包含的是未做恢复前的数据，而这些数据对于恢复后的数据库不再有效，所以数据库会要求在Open之前先对online redo log的sequence置零。

Resetlogs命令表示一个数据库逻辑生存期的结束和另一个数据库逻辑生存期的开始，每次使用Resetlogs命令的时候，SCN不会被重置，不过oracle会重置日志序列号，而且会重置联机重做日志内容。

Oracle把这个数据库逻辑生存期称为incarnation

每次使用resetlogs打开数据库，就会使incarnation + 1，也就是产生一个新的incarnation；

如果想要恢复到之前incarnation的scn/time，就需要先恢复到之前的incarnation；

对于上面的案例，具体就是先要

Reset database to incarnation 2;

再做不完全恢复试试

注明：整理自网络

转载：http://blog.csdn.net/leishifei/article/details/6430057