Resetlogs operation is sometimes inevitable even on primary database. In cases like Incomplete Media Recovery after restoring and recovering backups and archived logs, you must open the database with resetlogs.

When you do this using normal Oracle Standby, the Standby database does everything itself. It finds is archived logs, that were created before resetlogs change and then it changes incarnation to the new one and starts recovering from archived log sequence 1.

Dbvisit Standby is not able to do this alone. You must help it manually to get past the resetlogs change. 

Here is a short guide of how to pass the resetlogs with Dbvisit Standby. 

Open Primary Database with Resetlogs

This part is just to simulate openning primary database with resetlogs. DO NOT do it on production database, it is only meant for testing purposes.

I used following commands to simulate openning database with resetlogs option:

SYS@DBVTWO>shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@DBVTWO>startup mount
ORACLE instance started.

Fixed Size 2926472 bytes
Variable Size 603981944 bytes
Database Buffers 1526726656 bytes
Redo Buffers 13848576 bytes
Database mounted.
SYS@DBVTWO>alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01139: RESETLOGS option only valid after an incomplete database recovery

SYS@DBVTWO>recover database until cancel;
Media recovery complete.
SYS@DBVTWO>alter database open resetlogs;

Now you can see, that the normal dbvisit synchronization job does not work at all:

oracle@czlin01:/usr/dbvisit8/standby> dbvctl -d DBVTWO
=============================================================
Dbvisit Standby Database Technology (8.0.10.18545) (pid 24398)
dbvctl started on primarydb: Tue May 9 15:28:34 2017
=============================================================
>>> Obtaining information from standby database (RUN_INSPECT=Y)... failed

Error Code=772 201705091528 - 201705091528 - Unable to obtain last archived log
sequence from database. Please increase the LOG_SWITCH_WAIT_IN_SEC parameter in Dbvisit
Database configuration (DDC) file dbv_DBVTWO.env


Note FORCE_LOGGING is disabled in the primary database.

Dbvisit Standby terminated...
Error Code: 772
201705091528 - Unable to obtain last archived log sequence from database. Please
increase the LOG_SWITCH_WAIT_IN_SEC parameter in Dbvisit Database configuration (DDC)
file dbv_DBVTWO.env

Tracefile from server: primarydb (PID:24398)
24398_dbvctl_DBVTWO_201705091528.trc

Let's Fix Resetlogs Problem

As I wrote, Oracle itself is able to handle the resetlogs automatically through normal recovery. With Dbvisit Standby, the only thing we have to do to fix the problem is pass the point of resetlogs using Oracle internal mechanisms. The steps are following:

• STANDBY: run recover standby database command on standby database - this will give you what archived log it is looking for and it gives you archived log sequence, from which you need the recovery to continue:

  SYS@DBVTWO>recover standby database;ORA-00279: change 2219448 generated at 05/09/2017 15:21:38 needed for thread 1
  ORA-00289: suggestion : /u01/app/oracle/dbvisit_arch/DBVTWO/o1_mf_1_549_dk3jvqf2_.arc
  ORA-00280: change 2219448 for thread 1 is in sequence #549

• PRIMARY: copy/restore all archived logs needed from previous point until the resetlogs change to the standby server

  oracle@czlin01> scp o1_mf_1_549_dk3jvqf2_.arc o1_mf_1_550_ddf3ig3x_.arc secondarydb:/u01/app/oracle/dbvisit_arch/DBVTWO

• PRIMARY: copy FIRST archived log from the new incarnation to the standby server - this is necessary to let the standby database know about the new incarnation

  oracle@czlin01> scp o1_mf_1_1_dk3kdl0h_.arc secondarydb:/u01/app/oracle/dbvisit_arch/DBVTWO

• STANDBY: catalog all these archived logs on the standby database: `catalog start with '<PATH_TO_ARCHLOGS>'

  RMAN> catalog start with '/u01/app/oracle/dbvisit_arch/DBVTWO/';

• STANDBY: Now you can check, that the incarnation branch appeared in the output of the list incarnation command of RMAN. You can check this on both databases on source as well as on standby.
  

  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 DBVTWO 3940696123 PARENT 1 29-NOV-16
  2 2 DBVTWO 3940696123 PARENT 2041634 05-MAY-17
  3 3 DBVTWO 3940696123 CURRENT 2219665 09-MAY-17

• STANDBY: recover standby database using any tool - sqlplus/rman eg. SQL> RECOVER AUTOMATIC STANDBY DATABASE - make sure, that it passed the point of the resetlogs change - that it took 1st archived log of the newly opened database
  

  SQL> recover automatic standby database;

• run dbvisit jobs as usual on primary and then on standby server. Now everything should work fine.