APPLY_DELAY_LAG_MINUTES=120 set to keep the standby 2 hours behind. Standby control file has been recreated to reflect structural changes in the primary database. Once the standby ctl file has been recreated, Dbvisit on the standby fails with the error:
201310111413 - Dbvisit Standby has detected an endless loop in recovering standby database XYZ. Please check alert.log, else please contact Dbvisit support. Dbvisit Standby terminated. Return code = 5031
When APPLY_DELAY_LAG_MINUTES is set, Dbvisit issues the recover standby database until time command. Say current time is 18:30, the standby ctl file was recreated at 18:15, and the standby datafile headers are at 16:00. Dbvisit will take the lag into account and runs the recover standby database until time 2013-10-16:16:30:00 command. The changes in the supplied log will be applied up to 16:30, however the recover command will fail:
16:47:36 SQL> recover standby database until time '2013-10-16:16:30:00'
ORA-00279: change 23239414 generated at 10/16/2013 16:21:42 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/fast_recovery_area/TESTDB/archivelog/2013_10_16/o1_mf_1_1183_%u_.arc
ORA-00280: change 23239414 for thread 1 is in sequence #1183
16:48:23 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/archive/testdb/o1_mf_1_1183_95w2bz3f_.arc
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/testdb/system01.dbf'From the output of the recovery session Dbvisit cannot obtain the next required thread and sequence, and goes into an endless loop trying to apply the same log over and over again, until it times out.
The solution is just to turn Dbvisit off on the standby until the lag "catches up" with the time of the standby ctl file recreation. In this example Dbvisit will resume applying logs at 20:15 (2 hours later).
Anna MacNaughtan October 17, 2013 12:13
Comments