主库resetlogs对物理备库的影响

myownstars

Hi Maclean

一直以来我对此知识点都有困惑，以下是11g的官方文档

即主库进行resetlogs时，备库在什么情况下才不受影响
什么叫redo data past the new resetlogs SCN和new redo branch，对表格描述的第一种情形，能不能举个具体例子说明一下

十分感谢

If the standby database. . .	Then. . .	Perform these steps. . .
Has not applied redo data past the new resetlogs SCN (past the start of the new branch of redo data) and the new redo branch from OPEN RESETLOGS has been registered at the standby	Redo Apply automatically takes the new branch of redo.	No manual intervention is necessary. The MRP automatically resynchronizes the standby database with the new branch of redo data. Note: To check whether the new redo branch has been registered at the standby, perform the following query at the primary and standby and verify that the results match: SELECT resetlogs_id, resetlogs_change# FROM V$DATABASE_INCARNATION WHERE status='CURRENT'

[ 本帖最后由 myownstars 于 2012-3-9 15:49 编辑 ]

Maclean Liu(刘相兵

ODM DATA:


Recovering Through the OPEN RESETLOGS StatementData Guard allows recovery on a physical standby database to continue after the primary database has been opened with the RESETLOGS option. When an ALTER DATABASE OPEN RESETLOGS statement is issued on the primary database, the incarnation of the database changes, creating a new branch of redo data.
When a physical standby database receives a new branch of redo data, Redo Apply automatically takes the new branch of redo data. For physical standby databases, no manual intervention is required if the standby database did not apply redo data past the new resetlogs SCN (past the start of the new branch of redo data). The following table describes how to resynchronize the standby database with the primary database branch.

If the standby database. . .	Then. . .	Perform these steps. . .
Has not applied redo data past the new resetlogs SCN (past the start of the new branch of redo data)	Redo Apply automatically takes the new branch of redo.	No manual intervention is necessary. The MRP automatically resynchronizes the standby database with the new branch of redo data.
Has applied redo data past the new resetlogs SCN (past the start of the new branch of redo data) and Flashback Database is enabled on the standby database	The standby database is recovered in the future of the new branch of redo data.	Follow the procedure in Section 12.5.1 to flash back a physical standby database. Restart Redo Apply to continue application of redo data onto new reset logs branch. The MRP automatically resynchronizes the standby database with the new branch.
Has applied redo data past the new resetlogs SCN (past the start of the new branch of redo data) and Flashback Database is not enabled on the standby database	The primary database has diverged from the standby on the indicated primary database branch.	Re-create the physical standby database following the procedures in Chapter 3.
Is missing intervening archived redo log files from the new branch of redo data	The MRP cannot continue until the missing log files are retrieved.	Locate and register missing archived redo log files from each branch.
Is missing archived redo log files from the end of the previous branch of redo data.	The MRP cannot continue until the missing log files are retrieved.	Locate and register missing archived redo log files from the previous branch.

myownstars

还是不太明白，我自己举个例子吧：
假如现在主库scn为100，由于不完全恢复或者介质损坏，主库恢复到80并
open resetlogs；
若此时备库的SCN只应用到<=80，那么备库不需要DBA手工干预

请问此例是否正确？有一点十分不解，若备库已经接受到80-100之间的redo但并未应用，此时主库又传送了resetlogs之后的日志
此时备库是采用什么样的机制而不对
80-100之间的redo进行apply，或者说此时备库只是接受到resetlogs之后的日志但并未进行redo apply，它是如何知道此时主库已经resetlogs从而不去应用80-100之间redo

Maclean Liu(刘相兵

ODM DATA:

12.5.1 Flashing Back a Physical Standby Database to a Specific Point-in-Time

The following steps describe how to avoid re-creating a physical standby database after you issued the OPEN RESETLOGS statement on the primary database.

Step 1   Determine the SCN before the RESETLOGS operation occurred.

On the primary database, use the following query to obtain the value of the system change number (SCN) that is 2 SCNs before the RESETLOGS operation occurred on the primary database:

SQL> SELECT TO_CHAR(RESETLOGS_CHANGE# - 2) FROM V$DATABASE;

Step 2   Obtain the current SCN on the standby database.

On the standby database, obtain the current SCN with the following query:

SQL> SELECT TO_CHAR(CURRENT_SCN) FROM V$DATABASE;

Step 3   Determine if it is necessary to flash back the database.

If the value of CURRENT_SCN is larger than the value of resetlogs_change# - 2, issue the following statement to flash back the standby database.

SQL> FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# -2;

    If the value of CURRENT_SCN is less than the value of the resetlogs_change# - 2, skip to Step 4.

    If the standby database's SCN is far enough behind the primary database's SCN, log apply services will be able to continue through the OPEN RESETLOGS statement without stopping. In this case, flashing back the database is unnecessary because log apply services do not stop upon reaching the OPEN RESETLOGS statement in the redo data.

Maclean Liu(刘相兵

"若此时备库的SCN只应用到<=80，那么备库不需要DBA手工干预 "

正确

"有一点十分不解，若备库已经接受到80-100之间的redo但并未应用，此时主库又传送了resetlogs之后的日志
此时备库是采用什么样的机制而不对80-100之间的redo进行apply，或者说此时备库只是接受到resetlogs之后的日志但并未进行redo apply，它是如何知道此时主库已经resetlogs从而不去应用80-100之间redo"

ODM finding:

[oracle@vrh8 ~]$ oerr ora 19906
19906, 00000, "recovery target incarnation changed during recovery"
// *Cause: While a media recovery was active, a new incarnation was detected
//         by the server due to inspection or cataloging of archived logs
//         or backup files.
// *Action: If you want recovery to use the new incarnation, restart recovery.
//          This is the most common action on a standby database when resetlogs
//          is done in primary. If you do not want recovery to use the new
//          incarnation,
//          change the recovery destination using RMAN's RESET DATABASE
//          TO INCARNATION <incarnation#> command.
//          To see which incarnations are available for this target database,
//          query V$DATABASE_INCARNATION or use RMAN's LIST INCARNATION


的确存在这种机制 保证MRP 会定期检查Primary的incarnation 情况，若 发现incarnation 存在变化， 则停止recover 并报ORA-19906， 具体MRP是如何做的 需要进一步测试。