For a physical/logical standby database it is possible that redo apply might not halt when an OPEN RESETLOGS command is encountered.

PHYSICAL STANDBY
================
If the physical standby db SCN is far enough behind the primary database SCN then the redo apply service can interpret the OPEN RESETLOGS without stopping.

N.B. Recall the “recovery through RESETLOGS” was implemented in 10g.

Use the following:

1) On primary determine an SCN at least 2 SCN’s prior to the OPEN RESETLOGS
SELECT TO_CHAR(resetlogs_change# – 2) FROM v$DATABASE;

2) On standby, obtain the current SCN
SELECT TO_CHAR(current_scn) FROM V$DATABASE;

3) On standby flashback db
FLASHBACK STANDBY DATABASE TO SCN

4) On standby restart recovery
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

LOGICAL STANDBY
===============
1) On primary determine an SCN at least 2 SCN’s prior to the OPEN RESETLOGS
SELECT TO_CHAR(resetlogs_change# – 2) FROM v$DATABASE;

2) On standby, obtain the current SCN
SELECT TO_CHAR(current_scn) FROM V$DATABASE;

3) On standby flashback db
FLASHBACK STANDBY DATABASE TO SCN

4) On standby restart recovery
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;