Generally, when the main library needs to be restored and opened by open resetlogs, the standby needs to be redo to construct the main and standby synchronization architecture. But in some cases, it is not necessary to spend a lot of time. Only the flash back function of the standby needs to be turned on, the main and standby synchronization process can be restored in a relatively short time.

(1)
After the main library resetlogs, query the RESETLOGS_CHANGE# (SCN) at that time. If it is smaller than the standby SCN, the standby can be repaired directly by flashing back to RESETLOGS_CHANGE# (SCN).
(two)
Main database status query

SQL>  select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2109683           2108651 YES

Standby status query

# Synchronization
SQL> select max(sequence#),applied,archived from v$archived_log group by applied,archived;

MAX(SEQUENCE#) APPLIED   ARC
-------------- --------- ---
             6 IN-MEMORY YES
             5 YES       YES

SQL>  select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2110296           2108651 YES

(three)
Main library

# Backup database
RMAN> backup database;

#Create a restore point
SQL> create restore point BEFORE_UPDATE;

#Perform update operations
SQL>  delete  from  baiyang.t where id = 99;

6 rows deleted.

SQL> commit;

# Query the current database status
SQL> select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2110440           2108651 YES

# close database
SQL> shutdown immediate

# Restore the database
SQL> startup mount  

RMAN> 
run {
restore database;
recover database until restore point BEFORE_UPDATE;
}

# Open the database
SQL> alter database open RESETLOGS;

# View database status
SQL> select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2110715           ***2110399*** YES

# Query table data
SQL> select count(*) from  baiyang.t where id = 99;

  COUNT(*)
----------
         6

After a series of suffocating operations, the deleted data from the main database table baiyang.t came back
(four)
Reserve library

#View the current standby status. SCN Greater than main library RESETLOGS_CHANGE#The backup synchronization can be restored by flashback

SQL> select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     ***2110533***           2108651 YES

# The real-time application log process has stopped, and you can see that the MRP0 process has stopped in the alarm log.

SQL> select max(sequence#),applied,archived from v$archived_log group by applied,archived;

MAX(SEQUENCE#) APPLIED   ARC
-------------- --------- ---
             7 YES       YES
             2 NO        YES
          

(five)
Standby, now flash back to the database

SQL> shutdown immediate
SQL> startup mount

# Flashback Database
RMAN> flashback database until scn 1922219;
SQL> alter database open;

# Start real-time applications
SQL> select max(sequence#),applied,archived from v$archived_log group by applied,archived;

MAX(SEQUENCE#) APPLIED   ARC
-------------- --------- ---
             3 IN-MEMORY YES
             7 YES       YES

(six)
If the standby SCN is smaller than the main resetlogs, do you need to flash back?
Unwanted.
Consider a case where the standby has stopped synchronizing before the main library fails, then the application process of the standby log can be restarted directly after the main library restores and resetlogs.