We're here to help!

No New Logs to Apply After Standby Rebuild(Version 6.0)

Follow
Problem Description

When performing  a rebuild from primary server  it still complained about missing logs. Below article explains how to resolve this issue.

Solution

The standby datafile #1 SYSTEM.DBF is on SNV=8866113 (from 18/3/2013):

20131230 14:19:11 main::cmn_cat-> cmn_cat catfile=G:\dbvisit-temp\1816.dbvisit.201312301418.ora_list_dictionary.dbv logger_category=Dbvisit::info
20131230 14:19:11 main::cmn_cat->
20131230 14:19:11 main::cmn_cat-> SQL*Plus: Release 10.2.0.1.0 - Production on Mon Dec 30 14:19:01 2013
20131230 14:19:11 main::cmn_cat->
20131230 14:19:11 main::cmn_cat-> Copyright (c) 1982, 2005, Oracle. All rights reserved.
20131230 14:19:11 main::cmn_cat->
20131230 14:19:11 main::cmn_cat-> SQL> Connected.
20131230 14:19:11 main::cmn_cat-> SQL> columns cleared
20131230 14:19:11 main::cmn_cat-> SQL> SQL> SQL> SQL>
20131230 14:19:11 main::cmn_cat-> SOURCE
20131230 14:19:11 main::cmn_cat-> ----------
20131230 14:19:11 main::cmn_cat-> V_DATABASE
20131230 14:19:11 main::cmn_cat->
20131230 14:19:11 main::cmn_cat-> SQL> 2 3 4 5 6
20131230 14:19:11 main::cmn_cat-> DBID NAME CHECKPOINT_CHANGE# CONTROL RESETLOGS_CHANGE# RESETLOGS_TI
20131230 14:19:11 main::cmn_cat-> ---------- --------- ------------------------------- ------- ------------------------------- ------------
20131230 14:19:11 main::cmn_cat-> 2686756923 XE 467823342 STANDBY 193066 250113 11:50
20131230 14:19:11 main::cmn_cat->
20131230 14:19:11 main::cmn_cat-> SQL>
20131230 14:19:11 main::cmn_cat-> SOURCE
20131230 14:19:11 main::cmn_cat-> -----------------
20131230 14:19:11 main::cmn_cat-> V_DATAFILE_HEADER
20131230 14:19:11 main::cmn_cat->
20131230 14:19:11 main::cmn_cat-> SQL> 2 3 4 5 6 7
20131230 14:19:11 main::cmn_cat-> FILE# NAME BYTES CHECKPOINT_CHANGE# CHECKPOINT_T RESETLOGS_CHANGE#
20131230 14:19:11 main::cmn_cat-> ---------- -------------------------------------------------------------------------------- -------------- ------------------------------- ------------ -------------------------------
20131230 14:19:11 main::cmn_cat-> 1 D:\ORACLEXE\ORADATA\XE\SYSTEM.DBF 387973120 8866113 180313 10:58 193066
20131230 14:19:11 main::cmn_cat-> 2 D:\ORACLEXE\ORADATA\XE\UNDO.DBF 131072000 467901233 301213 11:37 193066
20131230 14:19:11 main::cmn_cat-> 3 D:\ORACLEXE\ORADATA\XE\SYSAUX.DBF 440401920 467901676 301213 11:37 193066
20131230 14:19:11 main::cmn_cat-> 4 D:\ORACLEXE\ORADATA\XE\USERS.DBF 1426063360 467902261 301213 11:38 193066
20131230 14:19:11 main::cmn_cat-> 5 D:\ORACLEXE\ORADATA\XE\MOBILE.DBF 113246208 467903536 301213 11:40 193066

Note: you can obtain this info by running dbv_functions -a xe list_dictionary on the standby. This is the SCN Oracle requested for recovery:

20131230 14:19:17 main::cmn_cat-> SQL> SQL> SQL> SQL> ORA-00279: change 8866113 generated at 03/18/2013 10:58:07 needed for thread 1
20131230 14:19:17 main::cmn_cat-> ORA-00289: suggestion : F:\ORADATA\ARCHIVE\ARC00134_0805636221.001
20131230 14:19:17 main::cmn_cat-> ORA-00280: change 8866113 for thread 1 is in sequence #134
20131230 14:19:17 main::cmn_cat->
20131230 14:19:17 main::cmn_cat->
20131230 14:19:17 main::cmn_cat-> Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
20131230 14:19:17 main::cmn_cat-> ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
20131230 14:19:17 main::cmn_cat-> ORA-01194: file 1 needs more recovery to be consistent
20131230 14:19:17 main::cmn_cat-> ORA-01110: data file 1: 'D:\ORACLEXE\ORADATA\XE\SYSTEM.DBF'

What method did you use to rebuild the standby? Did you run dbvisit_setup option 7) Create Standby Database, or did you rebuild the standby manually? In the first case we can take a look at the trace file generated by Dbvisit (it will have a string "csd" in its name), if it is still available on the standby.

I suggest that you first try to copy datafile #1 from the primary to the standby. From the primary run:

dbv_functions -a xe refresh_datafile 1

Once completed, run dbv_functions -a xe list_dictionary on the standby and check checkpoint_change and checkpoint_time for the datafile #1. Then run dbvisit on the standby once again and see if the issue has been resolved.

Arjen Visser December 31, 2013 10:23

Have more questions? Submit a request

Comments