2 cases to recover standby after primary open resetlogs:

It's supported by oracle:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm#i1026480

首先是incarnation的概念，原本打算自己讲解一下来着，发现已有前辈研究过，以供各位学习：

http://space.itpub.net/22235/viewspace-348212

这块信息是记录在controlfile内的，所以如果你是重建controlfile那么这块信息肯定会丢失。

可以通过oradebug dump controlf 3来查看这段内容：

通过rman，list incarnation可以查看：

数据库原型列表
DB 关键字 Inc 关键字 DB 名 DB ID STATUS 重置 SCN 重置时间
------- ------- -------- ---------------- --- ---------- ----------
1 1 O11 1712983965 PARENT 1 15-10月-07
2 2 O11 1712983965 PARENT 886308 02-1月 -09
3 3 O11 1712983965 CURRENT 1387087 25-9月 -09

OK, 言归正传。

1. managed standby: 这种最简单，什么都不用做，standby会自动恢复过resetlog点。

2. normal physical standby using manually recovery: 需要copy primary的controlfile

首先是1的测试结果：

这次测试没有做任何操作，从库能够自动恢复过resetlog点6314837，注意这里不同的地方是open resetlog之后scn号还是连续的，普遍意义上应该是scn+1为新的sequence1的first_scn.个人感觉是oracle为了managed standby能够正常恢复而故意为之。没有测试，有机会再测一遍。

For managed standby database, it can fix this automatically:
In primary, we open resetlogs:
SQL> select SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# from v$archived_log;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
992 6304959 6305379
993 6305379 6306626
994 6306626 6314837
994 6306626 6314837 =>此处open resetlogs, 但是下一个log的scn还是连续的，所以standby无需任何操作能够继续恢复。
1 6314837 6314971
1 6314837 6314971
2 6314971 6314978
2 6314971 6314978

In standby, no action needed:

测试2的结果：

After primary did an open resetlogs(the second time):

primary:

数据库原型列表
DB 关键字 Inc 关键字 DB 名 DB ID STATUS 重置 SCN 重置时间
------- ------- -------- ---------------- --- ---------- ----------
1 1 O11 1712983965 PARENT 1 15-10月-07
2 2 O11 1712983965 PARENT 886308 02-1月 -09
3 3 O11 1712983965 CURRENT 1387087 25-9月 -09

standby:

RMAN> list incarnation;

使用目标数据库控制文件替代恢复目录

数据库原型列表
DB 关键字 Inc 关键字 DB 名 DB ID STATUS 重置 SCN 重置时间
------- ------- -------- ---------------- --- ---------- ----------
1 1 O11 1712983965 PARENT 1 15-10月-07
2 2 O11 1712983965 CURRENT 886308 02-1月 -09

SQL> select SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# from v$archived_log;

SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
1 1387087 1388681

recoved standby until 1387086: => sequence 44 which is the latest archivelog before open resetlogs

SQL> select file#,RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;

FILE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------- ----------------- ------------------
1 886308 1387086
2 886308 1387086
3 886308 1387086
4 886308 1387086
5 886308 1387086

copy controlfile from primary:

数据库原型列表
DB 关键字 Inc 关键字 DB 名 DB ID STATUS 重置 SCN 重置时间
------- ------- -------- ---------------- --- ---------- ----------
1 1 O11 1712983965 PARENT 1 15-10月-07
2 2 O11 1712983965 PARENT 886308 02-1月 -09
3 3 O11 1712983965 CURRENT 1387087 25-9月 -09

SQL> select file#,RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;

FILE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------- ----------------- ------------------
1 886308 1387086
2 886308 1387086
3 886308 1387086
4 886308 1387086
5 886308 1387086

SQL> recover standby database until cancel;
ORA-00279: 更改 1387087 (在 09/25/2009 17:00:20 生成) 对于线程 1 是必需的
ORA-00289: 建议: C:ORACLECSHANORADATAO11ARCHIVEARC00001_0698518820.001
ORA-00280: 更改 1387087 (用于线程 1) 在序列 #1 中

after this:

SQL> select file#,RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;

FILE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------- ----------------- ------------------
1 1387087 1387087
2 1387087 1387087
3 1387087 1387087
4 1387087 1387087
5 1387087 1387087

指定日志: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 1388681 (在 09/25/2009 17:13:28 生成) 对于线程 1 是必需的
ORA-00289: 建议: C:ORACLECSHANORADATAO11ARCHIVEARC00002_0698518820.001
ORA-00280: 更改 1388681 (用于线程 1) 在序列 #2 中
ORA-00278: 此恢复不再需要日志文件
'C:ORACLECSHANORADATAO11ARCHIVEARC00001_0698518820.001'

ORA-00308: 无法打开归档日志
'C:ORACLECSHANORADATAO11ARCHIVEARC00002_0698518820.001'
ORA-27041: 无法打开文件
OSD-04002: ？???？？?
O/S-Error: (OS 2) The system cannot find the file specified