Resetlogs operation is sometimes inevitable. 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 there was some 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 Database with Resetlogs
I used following commands to open database with resetlogs option:
ORACLE instance shut down.
ORACLE instance started.
Total System Global Area 2147483648 bytes
Fixed Size 2926472 bytes
Variable Size 603981944 bytes
Database Buffers 1526726656 bytes
Redo Buffers 13848576 bytes
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 (18.104.22.16845) (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)
Tracefile from server: primarydb (PID:24398)
Let's Fix Resetlogs Problem
As I wrote, Oracle itself is able to handle the resetlogs automatically through normal recovery. So 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 databasecommand 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 serveroracle@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 incarnationoracle@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.