When performing a rebuild from primary server it still complained about missing logs. Below article explains how to resolve this issue.
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 1Once 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
Comments