Applying Logs

Hi,
I'm cloning a database (oracle 9i) in the same server. When I apply archive logs using 'recover database until cancel ' option, it has applied all the archive logs and finally it has issued the following error. When I checked using v$log, the status arch_8998.arc is in active. This is the log it is archiving currently. Can I copy this log to the cloning databse archive directory to apply or what is the option?
ORA-00308: cannot open archived log '/oracle/archive/arch_8998.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
regards
bala

Hi,
I tried with applying 8998.arc log and issued CANCEL when it has asked for 8999.arc log. The messages are as follows.
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/oracle/archive/arch_8998.arc
ORA-00279: change 2259623367316 generated at 06/15/2006 06:00:22 needed for
thread 1
ORA-00289: suggestion : /oracle/archive/arch_18999.arc
ORA-00280: change 2259623367316 for thread 1 is in sequence #8999
ORA-00278: log file /oracle/archive/arch_8998.arc' no longer needed for
this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
Next when I tried to open the database using resetlogs options, it gives error as mentioned below
SQL> alter database open resetlogs;
alter database open resetlogs
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/oracle/data/system01.dbf'
Please advice me.
regards,
bala

Similar Messages

  • Logical standby apply won't apply logs

    RDBMS Version: Oracle 10.2.0.2
    Operating System and Version: Red Hat Enterprise Linux ES release 4
    Error Number (if applicable):
    Product (i.e. SQL*Loader, Import, etc.): Oracle Dataguard (Logical Standby)
    Product Version:
    Hi!!
    I have problem logical standby apply won't apply logs.
    SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
    TYPE HIGH_SCN
    STATUS
    COORDINATOR 288810
    ORA-16116: no work available
    READER 288810
    ORA-16240: Waiting for logfile (thread# 1, sequence# 68)
    BUILDER 288805
    ORA-16116: no work available
    TYPE HIGH_SCN
    STATUS
    PREPARER 288804
    ORA-16116: no work available
    ANALYZER 288805
    ORA-16116: no work available
    APPLIER 288805
    ORA-16116: no work available
    TYPE HIGH_SCN
    STATUS
    APPLIER
    ORA-16116: no work available
    APPLIER
    ORA-16116: no work available
    APPLIER
    ORA-16116: no work available
    TYPE HIGH_SCN
    STATUS
    APPLIER
    ORA-16116: no work available
    10 rows selected.
    SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
    SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
    66 11-JAN-07 11-JAN-07 YES YES
    67 11-JAN-07 11-JAN-07 NO NO
    SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
    NAME
    VALUE
    coordinator state
    IDLE
    SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
    APPLIED_SCN NEWEST_SCN
    288803 288809
    INITPRIMARY.ORA
    DB_NAME=primary
    DB_UNIQUE_NAME=primary
    REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
    service_names=primary
    instance_name=primary
    UNDO_RETENTION=3600
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standy)'
    LOG_ARCHIVE_DEST_1=
    'LOCATION=/home/oracle/primary/arch1/
    VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
    DB_UNIQUE_NAME=primary'
    LOG_ARCHIVE_DEST_2=
    'SERVICE=standy LGWR ASYNC
    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
    DB_UNIQUE_NAME=standy'
    LOG_ARCHIVE_DEST_3=
    'LOCATION=/home/oracle/primary/arch2/
    VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
    DB_UNIQUE_NAME=primary'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    LOG_ARCHIVE_DEST_STATE_3=ENABLE
    LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
    LOG_ARCHIVE_MAX_PROCESSES=30
    FAL_SERVER=standy
    FAL_CLIENT=primary
    DB_FILE_NAME_CONVERT='standy','primary'
    LOG_FILE_NAME_CONVERT=
    '/home/oracle/standy/oradata','home/oracle/primary/oradata'
    STANDBY_FILE_MANAGEMENT=AUTO
    INITSTANDY.ORA
    db_name='standy'
    DB_UNIQUE_NAME='standy'
    REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE'
    SERVICE_NAMES='standy'
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standy)'
    DB_FILE_NAME_CONVERT='/home/oracle/primary/oradata','/home/oracle/standy/oradata'
    LOG_FILE_NAME_CONVERT=
    '/home/oracle/primary/oradata','/home/oracle/standy/oradata'
    LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
    LOG_ARCHIVE_DEST_1=
    'LOCATION=/home/oracle/standy/arc/
    VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
    DB_UNIQUE_NAME=standy'
    LOG_ARCHIVE_DEST_2=
    'SERVICE=primary LGWR ASYNC
    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
    DB_UNIQUE_NAME=primary'
    LOG_ARCHIVE_DEST_3=
    'LOCATION=/home/oracle/standy/arch2/
    VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
    DB_UNIQUE_NAME=standy'
    LOG_ARCHIVE_DEST_STATE_1=ENABLE
    LOG_ARCHIVE_DEST_STATE_2=ENABLE
    LOG_ARCHIVE_DEST_STATE_3=ENABLE
    STANDBY_FILE_MANAGEMENT=AUTO
    FAL_SERVER=primary
    FAL_CLIENT=standy
    Alert Log Banco "Standy" desde a inicialização do SQL Apply
    Thu Jan 11 15:00:54 2007
    ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
    Thu Jan 11 15:01:00 2007
    alter database add supplemental log data (primary key, unique index) columns
    Thu Jan 11 15:01:00 2007
    SUPLOG: Updated supplemental logging attributes at scn = 289537
    SUPLOG: minimal = ON, primary key = ON
    SUPLOG: unique = ON, foreign key = OFF, all column = OFF
    Completed: alter database add supplemental log data (primary key, unique index) columns
    LOGSTDBY: Unable to register recovery logfiles, will resend
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    Thu Jan 11 15:01:04 2007
    ALTER DATABASE START LOGICAL STANDBY APPLY (standy)
    with optional part
    IMMEDIATE
    Attempt to start background Logical Standby process
    LSP0 started with pid=21, OS id=12165
    Thu Jan 11 15:01:05 2007
    LOGSTDBY Parameter: DISABLE_APPLY_DELAY =
    LOGSTDBY Parameter: REAL_TIME =
    Completed: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
    Thu Jan 11 15:01:07 2007
    LOGSTDBY status: ORA-16111: log mining and apply setting up
    Thu Jan 11 15:01:07 2007
    LOGMINER: Parameters summary for session# = 1
    LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
    LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
    LOGMINER: session# = 1, reader process P000 started with pid=22 OS id=12167
    LOGMINER: session# = 1, builder process P001 started with pid=23 OS id=12169
    LOGMINER: session# = 1, preparer process P002 started with pid=24 OS id=12171
    Thu Jan 11 15:01:17 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:01:17 2007
    LOGMINER: Turning ON Log Auto Delete
    Thu Jan 11 15:01:26 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:01:26 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Thu Jan 11 15:01:26 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_ATTRCOL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_CCOL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_CDEF$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_COL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_COLTYPE$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_ICOL$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_IND$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDCOMPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDSUBPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_LOB$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_LOBFRAG$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_OBJ$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TAB$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABCOMPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABSUBPART$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TS$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TYPE$ have been marked unusable
    Thu Jan 11 15:01:33 2007
    Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_USER$ have been marked unusable
    Thu Jan 11 15:02:05 2007
    Indexes of table SYSTEM.LOGMNR_ATTRCOL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_ATTRIBUTE$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_CCOL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_CDEF$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_COL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_COLTYPE$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_DICTIONARY$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_ICOL$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_IND$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_INDCOMPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_INDPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_INDSUBPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_LOB$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_LOBFRAG$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_OBJ$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TAB$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TABCOMPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TABPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TABSUBPART$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TS$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_TYPE$ have been rebuilt and are now usable
    Indexes of table SYSTEM.LOGMNR_USER$ have been rebuilt and are now usable
    LSP2 started with pid=25, OS id=12180
    LOGSTDBY Analyzer process P003 started with pid=26 OS id=12182
    LOGSTDBY Apply process P008 started with pid=20 OS id=12192
    LOGSTDBY Apply process P007 started with pid=30 OS id=12190
    LOGSTDBY Apply process P005 started with pid=28 OS id=12186
    LOGSTDBY Apply process P006 started with pid=29 OS id=12188
    LOGSTDBY Apply process P004 started with pid=27 OS id=12184
    Thu Jan 11 15:02:48 2007
    Redo Shipping Client Connected as PUBLIC
    -- Connected User is Valid
    RFS[1]: Assigned to RFS process 12194
    RFS[1]: Identified database type as 'logical standby'
    Thu Jan 11 15:02:48 2007
    RFS LogMiner: Client enabled and ready for notification
    Thu Jan 11 15:02:49 2007
    RFS LogMiner: RFS id [12194] assigned as thread [1] PING handler
    Thu Jan 11 15:02:49 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:02:49 2007
    LOGMINER: Turning ON Log Auto Delete
    Thu Jan 11 15:02:51 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
    Thu Jan 11 15:02:51 2007
    LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Thu Jan 11 15:02:51 2007
    LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
    Please, help me more time!!!!
    Thanks.

    Hello!
    thank you for the reply.
    The archive 1_68_608031954.arc that error of reading occurred, did not exist in the date of the error sees below:
    $ ls -lh /home/oracle/standy/arch2/
    total 108M
    -rw-r----- 1 oracle oinstall 278K Jan 11 15:00 1_59_608031954.arc
    -rw-r----- 1 oracle oinstall 76K Jan 11 15:00 1_60_608031954.arc
    -rw-r----- 1 oracle oinstall 110K Jan 11 15:00 1_61_608031954.arc
    -rw-r----- 1 oracle oinstall 1.0K Jan 11 15:00 1_62_608031954.arc
    -rw-r----- 1 oracle oinstall 2.0K Jan 11 15:00 1_63_608031954.arc
    -rw-r----- 1 oracle oinstall 96K Jan 11 15:00 1_64_608031954.arc
    -rw-r----- 1 oracle oinstall 42K Jan 11 15:00 1_65_608031954.arc
    -rw-r----- 1 oracle oinstall 96M Jan 13 06:10 1_68_608031954.arc
    -rw-r----- 1 oracle oinstall 12M Jan 13 13:29 1_69_608031954.arc
    $ ls -lh /home/oracle/primary/arch1/
    total 112M
    -rw-r----- 1 oracle oinstall 278K Jan 11 14:21 1_59_608031954.arc
    -rw-r----- 1 oracle oinstall 76K Jan 11 14:33 1_60_608031954.arc
    -rw-r----- 1 oracle oinstall 110K Jan 11 14:46 1_61_608031954.arc
    -rw-r----- 1 oracle oinstall 1.0K Jan 11 14:46 1_62_608031954.arc
    -rw-r----- 1 oracle oinstall 2.0K Jan 11 14:46 1_63_608031954.arc
    -rw-r----- 1 oracle oinstall 96K Jan 11 14:55 1_64_608031954.arc
    -rw-r----- 1 oracle oinstall 42K Jan 11 14:55 1_65_608031954.arc
    -rw-r----- 1 oracle oinstall 4.2M Jan 11 14:56 1_66_608031954.arc
    -rw-r----- 1 oracle oinstall 5.5K Jan 11 14:56 1_67_608031954.arc
    -rw-r----- 1 oracle oinstall 96M Jan 13 06:09 1_68_608031954.arc
    -rw-r----- 1 oracle oinstall 12M Jan 13 13:28 1_69_608031954.arc
    Alert log
    hu Jan 11 15:01:00 2007
    SUPLOG: Updated supplemental logging attributes at scn = 289537
    SUPLOG: minimal = ON, primary key = ON
    SUPLOG: unique = ON, foreign key = OFF, all column = OFF
    Completed: alter database add supplemental log data (primary key, unique index) columns
    LOGSTDBY: Unable to register recovery logfiles, will resend
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    Thu Jan 11 15:01:04 2007
    LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
    You it would know as to help me?
    Would be a BUG of the Oracle 10g?
    Thanks.

  • Dataguard - Primary not applying logs to Standby

    Having an issue applying logs to the standby, seemingly it's not setup correctly. I am sure I'm missing something simple here, but would love any input or help. Thanks in advance.
    Background:
    Primary: CDPMTSB (Single Stand alone)
    Standby: CDPMT (RAC)
    Error Message on Primary (Alert Log):
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_arc6_9571.trc:
    ORA-16014: log 3 sequence# 4071 not archived, no available destinations
    ORA-00312: online log 3 thread 2: '+FRA_DG_01/cdpmtsb/onlinelog/group_3.291.799379949'
    ARCH: Archival error occurred on a closed thread. Archiver continuing
    ORACLE Instance CDPMTSB - Archival Error. Archiver continuing.
    Mon Nov 19 19:54:24 2012
    Changing destination 4 from remote to local during archival of log#: 3 sequence#: 4071 thread#: 2
    Changing destination 4 from remote to local during archival of log#: 3 sequence#: 4071 thread#: 2
    ARC6: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
    ARC6: Archive log rejected (thread 2 sequence 4071) at host 'CDPMT'
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_arc6_9571.trc:
    ORA-16401: archivelog rejected by RFS
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_arc6_9571.trc:
    ORA-16014: log 3 sequence# 4071 not archived, no available destinations
    ORA-00312: online log 3 thread 2: '+FRA_DG_01/cdpmtsb/onlinelog/group_3.291.799379949'
    ARCH: Archival error occurred on a closed thread. Archiver continuing
    ORACLE Instance CDPMTSB - Archival Error. Archiver continuing.
    Mon Nov 19 19:59:24 2012
    Changing destination 4 from remote to local during archival of log#: 3 sequence#: 4071 thread#: 2
    Changing destination 4 from remote to local during archival of log#: 3 sequence#: 4071 thread#: 2
    ARC6: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
    ARC6: Archive log rejected (thread 2 sequence 4071) at host 'CDPMT'
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_arc6_9571.trc:
    ORA-16401: archivelog rejected by RFS
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_arc6_9571.trc:
    ORA-16014: log 3 sequence# 4071 not archived, no available destinations
    ORA-00312: online log 3 thread 2: '+FRA_DG_01/cdpmtsb/onlinelog/group_3.291.799379949'
    ARCH: Archival error occurred on a closed thread. Archiver continuing
    ORACLE Instance CDPMTSB - Archival Error. Archiver continuing.
    Mon Nov 19 20:00:00 2012
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_j001_17473.trc:
    ORA-12012: error on auto execute of job 72620
    ORA-06502: PL/SQL: numeric or value error: character to number conversion error
    ORA-06512: at "CD_ADMIN.UTDCD_SURVEY_PKG", line 4926
    Standby Alert Log:
    ORA-16401: archivelog rejected by RFS
    Mon Nov 19 19:32:15 2012
    RFS[6]: Assigned to RFS process 4248
    RFS[6]: Identified database type as 'physical standby': Client is ARCH pid 9561
    Mon Nov 19 19:32:22 2012
    RFS[1]: Selected log 6 for thread 1 sequence 4073 dbid 1629723947 branch 769881773
    Mon Nov 19 19:32:22 2012
    Archived Log entry 1097 added for thread 1 sequence 4072 ID 0x62e7f5cf dest 1:
    Archived Log entry 1098 added for thread 1 sequence 4072 ID 0x62e7f5cf dest 3:
    Mon Nov 19 19:34:23 2012
    Errors in file /opt/app/oracle/diag/rdbms/cdpmt/CDPMT1/trace/CDPMT1_rfs_24994.trc:
    ORA-16401: archivelog rejected by RFS
    Mon Nov 19 19:38:12 2012
    RFS[1]: Selected log 5 for thread 1 sequence 4074 dbid 1629723947 branch 769881773
    Mon Nov 19 19:38:12 2012
    Archived Log entry 1099 added for thread 1 sequence 4073 ID 0x62e7f5cf dest 1:
    Archived Log entry 1100 added for thread 1 sequence 4073 ID 0x62e7f5cf dest 3:
    Mon Nov 19 19:39:23 2012
    Errors in file /opt/app/oracle/diag/rdbms/cdpmt/CDPMT1/trace/CDPMT1_rfs_24994.trc:
    ORA-16401: archivelog rejected by RFS
    Mon Nov 19 19:44:24 2012
    Errors in file /opt/app/oracle/diag/rdbms/cdpmt/CDPMT1/trace/CDPMT1_rfs_24994.trc:
    ORA-16401: archivelog rejected by RFS
    Mon Nov 19 19:49:24 2012
    Errors in file /opt/app/oracle/diag/rdbms/cdpmt/CDPMT1/trace/CDPMT1_rfs_24994.trc:
    ORA-16401: archivelog rejected by RFS
    Mon Nov 19 19:54:24 2012
    Errors in file /opt/app/oracle/diag/rdbms/cdpmt/CDPMT1/trace/CDPMT1_rfs_24994.trc:
    ORA-16401: archivelog rejected by RFS
    Mon Nov 19 19:59:24 2012
    Errors in file /opt/app/oracle/diag/rdbms/cdpmt/CDPMT1/trace/CDPMT1_rfs_24994.trc:
    ORA-16401: archivelog rejected by RFS
    Primary Parameters:
    NAME TYPE VALUE
    log_archive_config string DG_CONFIG=(CDPMT,CDPMTSB)
    log_archive_dest string
    log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_
    DEST VALID_FOR=(ONLINE_LOGFIL
    ES,ALL_ROLES) DB_UNIQUE_NAME=C
    DPMTSB
    log_archive_dest_10 string
    log_archive_dest_2 string SERVICE=CDPMT VALID_FOR=(ONLIN
    E_LOGFILES,PRIMARY_ROLE) DB_UN
    IQUE_NAME=CDPMT
    log_archive_dest_3 string location="+FRA_DG_01/cdpmtsb/s
    tandbylog", valid_for=(STANDB
    Y_LOGFILE,STANDBY_ROLE)
    log_archive_dest_4 string
    log_archive_dest_5 string
    log_archive_dest_6 string
    log_archive_dest_7 string
    log_archive_dest_8 string
    log_archive_dest_9 string
    log_archive_dest_state_1 string enable
    log_archive_dest_state_10 string enable
    log_archive_dest_state_2 string ENABLE
    log_archive_dest_state_3 string ENABLE
    log_archive_dest_state_4 string defer
    log_archive_dest_state_5 string enable
    log_archive_dest_state_6 string enable
    log_archive_dest_state_7 string enable
    log_archive_dest_state_8 string enable
    log_archive_dest_state_9 string enable
    log_archive_duplex_dest string
    log_archive_format string %t_%s_%r.dbf
    log_archive_local_first boolean TRUE
    log_archive_max_processes integer 7
    log_archive_min_succeed_dest integer 2
    log_archive_start boolean FALSE
    log_archive_trace integer 0
    Standby Parameters:
    NAME TYPE VALUE
    log_archive_config string dg_config=(CDPMT,CD PMTSB)
    log_archive_dest string
    log_archive_dest_1 string location="USE_DB_RE COVERY_FILE
    _DEST", valid_for= (ALL_LOGFIL
    ES,ALL_ROLES)
    log_archive_dest_10 string
    log_archive_dest_2 string SERVICE=cdpmtsb LGW R ASYNC VAL
    ID_FOR=(ONLINE_LOGF ILES,PRIMAR
    Y_ROLE) DB_UNIQUE_N AME=cdpmtsb
    log_archive_dest_3 string LOCATION=+FRA_DG_01 /CDPMT/STAN
    DBYLOG VALID_FOR=( STANDBY_LOG
    NAME TYPE VALUE
    FILES,STANDBY_ROLE) DB_UNIQUE_
    NAME=CDPMT
    log_archive_dest_4 string
    log_archive_dest_5 string
    log_archive_dest_6 string
    log_archive_dest_7 string
    log_archive_dest_8 string
    log_archive_dest_9 string
    log_archive_dest_state_1 string ENABLE
    log_archive_dest_state_10 string enable
    log_archive_dest_state_2 string ENABLE
    NAME TYPE VALUE
    log_archive_dest_state_3 string enable
    log_archive_dest_state_4 string enable
    log_archive_dest_state_5 string enable
    log_archive_dest_state_6 string enable
    log_archive_dest_state_7 string enable
    log_archive_dest_state_8 string enable
    log_archive_dest_state_9 string enable
    log_archive_duplex_dest string
    log_archive_format string %t_%s_%r.dbf
    log_archive_local_first boolean TRUE
    log_archive_max_processes integer 30
    NAME TYPE VALUE
    log_archive_min_succeed_dest integer 1
    log_archive_start boolean FALSE
    log_archive_trace integer 0
    SQL> show parameter log_ar
    NAME TYPE VALUE
    log_archive_config string dg_config=(CDPMT,CDPMTSB)
    log_archive_dest string
    log_archive_dest_1 string location="USE_DB_RECOVERY_FILE
    _DEST", valid_for=(ALL_LOGFIL
    ES,ALL_ROLES)
    log_archive_dest_10 string
    log_archive_dest_2 string SERVICE=cdpmtsb LGWR ASYNC VAL
    ID_FOR=(ONLINE_LOGFILES,PRIMAR
    Y_ROLE) DB_UNIQUE_NAME=cdpmtsb
    log_archive_dest_3 string LOCATION=+FRA_DG_01/CDPMT/STAN
    DBYLOG VALID_FOR=(STANDBY_LOG
    NAME TYPE VALUE
    FILES,STANDBY_ROLE) DB_UNIQUE_
    NAME=CDPMT
    log_archive_dest_4 string
    log_archive_dest_5 string
    log_archive_dest_6 string
    log_archive_dest_7 string
    log_archive_dest_8 string
    log_archive_dest_9 string
    log_archive_dest_state_1 string ENABLE
    log_archive_dest_state_10 string enable
    log_archive_dest_state_2 string ENABLE
    NAME TYPE VALUE
    log_archive_dest_state_3 string enable
    log_archive_dest_state_4 string enable
    log_archive_dest_state_5 string enable
    log_archive_dest_state_6 string enable
    log_archive_dest_state_7 string enable
    log_archive_dest_state_8 string enable
    log_archive_dest_state_9 string enable
    log_archive_duplex_dest string
    log_archive_format string %t_%s_%r.dbf
    log_archive_local_first boolean TRUE
    log_archive_max_processes integer 30
    NAME TYPE VALUE
    log_archive_min_succeed_dest integer 1
    log_archive_start boolean FALSE
    log_archive_trace integer 0
    SQL>
    DGMGRL> show configuration verbose;
    Configuration
    Name: cdpmtqa
    Enabled: YES
    Protection Mode: MaxPerformance
    Databases:
    cdpmtsb - Primary database
    cdpmt - Physical standby database
    Fast-Start Failover: DISABLED
    Current status for "cdpmtqa":
    Warning: ORA-16608: one or more databases have warnings
    DGMGRL> show database verbose CDPMT
    Database
    Name: cdpmt
    Role: PHYSICAL STANDBY
    Enabled: YES
    Intended State: APPLY-ON
    Instance(s):
    CDPMT1
    CDPMT2 (apply instance)
    Properties:
    DGConnectIdentifier = 'cdpmt'
    ObserverConnectIdentifier = ''
    LogXptMode = 'ASYNC'
    DelayMins = '0'
    Binding = 'OPTIONAL'
    MaxFailure = '0'
    MaxConnections = '1'
    ReopenSecs = '300'
    NetTimeout = '30'
    RedoCompression = 'DISABLE'
    LogShipping = 'ON'
    PreferredApplyInstance = ''
    ApplyInstanceTimeout = '0'
    ApplyParallel = 'AUTO'
    StandbyFileManagement = 'AUTO'
    ArchiveLagTarget = '0'
    LogArchiveMaxProcesses = '4'
    LogArchiveMinSucceedDest = '1'
    DbFileNameConvert = ''
    LogFileNameConvert = ''
    FastStartFailoverTarget = ''
    StatusReport = '(monitor)'
    InconsistentProperties = '(monitor)'
    InconsistentLogXptProps = '(monitor)'
    SendQEntries = '(monitor)'
    LogXptStatus = '(monitor)'
    RecvQEntries = '(monitor)'
    HostName(*)
    SidName(*)
    StaticConnectIdentifier(*)
    StandbyArchiveLocation(*)
    AlternateLocation(*)
    LogArchiveTrace(*)
    LogArchiveFormat(*)
    LatestLog(*)
    TopWaitEvents(*)
    (*) - Please check specific instance for the property value
    Current status for "cdpmt":
    Warning: ORA-16809: multiple warnings detected for the database
    Any help would be really appreciated. Thanks!
    Edited by: 972075 on Nov 19, 2012 3:09 PM

    Thanks MSEBERG,
    Here's what I found. FRA seems to have enough space on ASM and there are other logs there, not sure what the issue is:
    14:31:58 SYS: CDPMTSB> show parameter db_recovery
    NAME TYPE VALUE
    db_recovery_file_dest string +FRA_DG_01
    db_recovery_file_dest_size big integer 60G
    DGMGRL> show database CDPMTSB logxptstatus;
    LOG TRANSPORT STATUS
    PRIMARY_INSTANCE_NAME STANDBY_DATABASE_NAME STATUS
    CDPMTSB cdpmt
    DGMGRL> SHOW DATABASE CDPMTSB InconsistentProperties;
    INCONSISTENT PROPERTIES
    INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE SPFILE_VALUE BROKER_VALUE
    DGMGRL> show database CDPMTSB InconsistentLogXptProps;
    INCONSISTENT LOG TRANSPORT PROPERTIES
    INSTANCE_NAME STANDBY_NAME PROPERTY_NAME MEMORY_VALUE BROKER_VALUE
    DGMGRL> show database CDPMT logxptstatus;
    Error: ORA-16757: unable to get this property's value
    DGMGRL> SHOW DATABASE CDPMT InconsistentProperties;
    INCONSISTENT PROPERTIES
    INSTANCE_NAME PROPERTY_NAME MEMORY_VALUE SPFILE_VALUE BROKER_VALUE
    CDPMT2 DbFileNameConvert DG_01/cdpmtsb, DG_01/cdpmt
    CDPMT2 LogFileNameConvert FRA_DG_01/cdpmtsb, FRA_DG_01/cdpmt, DG_01/cdpmtsb, DG_01/cdpmt
    CDPMT1 LogArchiveMaxProcesses 4 30 4
    CDPMT1 DbFileNameConvert DG_01/cdpmtsb, DG_01/cdpmt DG_01/cdpmtsb,DG_01/cdpmt
    CDPMT1 LogFileNameConvert FRA_DG_01/cdpmtsb, FRA_DG_01/cdpmt, DG_01/cdpmtsb, DG_01/cdpmt FRA_DG_01/cdpmtsb,FRA_DG_01/cdpmt,+DG_01/cdpmtsb,+DG_01/cdpmt
    DGMGRL> show database CDPMT InconsistentLogXptProps;
    Error: ORA-16757: unable to get this property's value
    Errors in the Alert (from Primary):
    ARCH: Archival error occurred on a closed thread. Archiver continuing
    ORACLE Instance CDPMTSB - Archival Error. Archiver continuing.
    Tue Nov 20 14:34:43 2012
    Changing destination 4 from remote to local during archival of log#: 3 sequence#: 4071 thread#: 2
    Changing destination 4 from remote to local during archival of log#: 3 sequence#: 4071 thread#: 2
    ARC6: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
    ARC6: Archive log rejected (thread 2 sequence 4071) at host 'cdpmt'
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_arc6_9571.trc:
    ORA-16401: archivelog rejected by RFS
    Errors in file /data/oracle/app/oracle/diag/rdbms/cdpmtsb/CDPMTSB/trace/CDPMTSB_arc6_9571.trc:
    ORA-16014: log 3 sequence# 4071 not archived, no available destinations
    ORA-00312: online log 3 thread 2: '+FRA_DG_01/cdpmtsb/onlinelog/group_3.291.799379949'
    ARCH: Archival error occurred on a closed thread. Archiver continuing
    ORACLE Instance CDPMTSB - Archival Error. Archiver continuing.
    DGMGRL> DGMGRL> show database verbose CDPMT
    Database
    Name: cdpmt
    Role: PHYSICAL STANDBY
    Enabled: YES
    Intended State: APPLY-ON
    Instance(s):
    CDPMT1
    CDPMT2 (apply instance)
    Properties:
    DGConnectIdentifier = 'cdpmt'
    ObserverConnectIdentifier = ''
    LogXptMode = 'ASYNC'
    DelayMins = '0'
    Binding = 'OPTIONAL'
    MaxFailure = '0'
    MaxConnections = '1'
    ReopenSecs = '300'
    NetTimeout = '30'
    RedoCompression = 'DISABLE'
    LogShipping = 'ON'
    PreferredApplyInstance = ''
    ApplyInstanceTimeout = '0'
    ApplyParallel = 'AUTO'
    StandbyFileManagement = 'AUTO'
    ArchiveLagTarget = '0'
    LogArchiveMaxProcesses = '4'
    LogArchiveMinSucceedDest = '1'
    DbFileNameConvert = ''
    LogFileNameConvert = ''
    FastStartFailoverTarget = ''
    StatusReport = '(monitor)'
    InconsistentProperties = '(monitor)'
    InconsistentLogXptProps = '(monitor)'
    SendQEntries = '(monitor)'
    LogXptStatus = '(monitor)'
    RecvQEntries = '(monitor)'
    HostName(*)
    SidName(*)
    StaticConnectIdentifier(*)
    StandbyArchiveLocation(*)
    AlternateLocation(*)
    LogArchiveTrace(*)
    LogArchiveFormat(*)
    LatestLog(*)
    TopWaitEvents(*)
    (*) - Please check specific instance for the property value
    Current status for "cdpmt":
    Warning: ORA-16809: multiple warnings detected for the database
    DGMGRL> show database verbose CDPMTSB
    Database
    Name: cdpmtsb
    OEM Name: CDPMTSB_devdb40.utd.com
    Role: PRIMARY
    Enabled: YES
    Intended State: TRANSPORT-ON
    Instance(s):
    CDPMTSB
    Properties:
    DGConnectIdentifier = 'cdpmtsb'
    ObserverConnectIdentifier = ''
    LogXptMode = 'ASYNC'
    DelayMins = '0'
    Binding = 'OPTIONAL'
    MaxFailure = '0'
    MaxConnections = '1'
    ReopenSecs = '300'
    NetTimeout = '30'
    RedoCompression = 'DISABLE'
    LogShipping = 'ON'
    PreferredApplyInstance = ''
    ApplyInstanceTimeout = '0'
    ApplyParallel = 'AUTO'
    StandbyFileManagement = 'AUTO'
    ArchiveLagTarget = '0'
    LogArchiveMaxProcesses = '7'
    LogArchiveMinSucceedDest = '2'
    DbFileNameConvert = '+DG_01/cdpmt, +DG_01/cdpmtsb'
    LogFileNameConvert = '+FRA_DG_01/cdpmt, FRA_DG_01/cdpmtsb, DG_01/cdpmt, +DG_01/cdpmtsb'
    FastStartFailoverTarget = ''
    StatusReport = '(monitor)'
    InconsistentProperties = '(monitor)'
    InconsistentLogXptProps = '(monitor)'
    SendQEntries = '(monitor)'
    LogXptStatus = '(monitor)'
    RecvQEntries = '(monitor)'
    HostName = 'devdb40.utd.com'
    SidName = 'CDPMTSB'
    StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=devdb40.utd.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=CDPMTSB_DGMGRL)(INSTANCE_NAME=CDPMTSB)(SERVER=DEDICATED)))'
    StandbyArchiveLocation = '+FRA_DG_01/cdpmtsb/standbylog'
    AlternateLocation = ''
    LogArchiveTrace = '0'
    LogArchiveFormat = '%t_%s_%r.dbf'
    LatestLog = '(monitor)'
    TopWaitEvents = '(monitor)'
    Current status for "cdpmtsb":
    SUCCESS
    Thanks for your help btw, I'm really at a loss here as to what is going on with this.

  • In standby db, can't find sequence number of Last Applied Log.

    Hello,
    Standby database is behind the primary database for over 200 hours, to repaire this, we are using a incremental backup from primary database and a restored control file.
    after starting up standby database, in Grid Control (OEM), can't find "last applied log" sequence number,
    go to that standby, do
    standby> select max(sequence#) from v$archived_log where applied='YES';
    MAX(SEQUENCE#)
    go to primary,
    do
    SQL> select max(sequence#) from v$archived_log where applied='YES';
    MAX(SEQUENCE#)
    83833
    then using OEM grid control, to Verify checks various standby database settings.
    Initializing
    Connected to instance standby_server:standby
    Starting alert log monitor...
    Updating Data Guard link on database homepage...
    Skipping verification of fast-start failover static services check.
    Data Protection Settings:
    Protection mode : Maximum Performance
    Redo Transport Mode settings:
    primary.com: ASYNC
    standby.com: ASYNC
    Checking standby redo log files.....OK
    Checking Data Guard status
    primary.com : Normal
    standby.com : Normal
    Checking inconsistent properties
    Checking agent status
    Checking applied log on standby........WARNING:
    Timed out after 60 seconds waiting for log to be applied.
    Processing completed.
    so how to fix this?
    thanks you very much.
    Edited by: 951932 on Oct 18, 2012 7:44 AM

    Hello;
    Probably nothing to fix. This is a common warning message.
    It even occurs in this example :
    http://www.databasejournal.com/features/oracle/article.php/10893_3826706_2/Oracle-11g-Data-Guard-Grid-Control-Management.htm
    Best Regards
    mseberg

  • ORA-326/ORA-334 Physical Standby DB - Not applying logs

    Hi, all, I have a Dataguard, the primary db is a RAC with three nodes, the standby db is a physical standby. the dataguard are all oracle 10.2.0.3 on solaris 9 sparc system
    Now, my standby db did not apply the archivelogs,there are some errors in standby alert log :
    Thu Jan 8 15:44:31 2009
    Errors in file /oracle/admin/xxxx/bdump/whut_mrp0_12863.trc:
    ORA-00326:log begins at change 2984028173, need earlier change 2984013192
    ORA-00334:archived log '+DGARCH/whut/3_22648_611942629.dbf'
    Managed Standby Recovery not using Real Time Apply
    Recovery interrupted!
    Thu Jan 8 15:44:34 2009
    Errors in file /export/home/oracle/admin/whut/bdump/whut_mrp0_12863.trc:
    ORA-00326:log begins at change 2984028173, need earlier change 2984013192
    ORA-00334:archived log '+DGARCH/whut/3_22648_611942629.dbf'
    Thu Jan 8 15:44:34 2009
    MRP0: Background Media Recovery process shutdown (whut)
    and the archivelogs on the standby db like this :
    NAME APP DEL
    +DGARCH/whut/3_22651_611942629.dbf                           NO  NO
    +DGARCH/whut/3_22650_611942629.dbf                           NO  NO
    +DGARCH/whut/3_22649_611942629.dbf                           NO  NO
    +DGARCH/whut/3_22648_611942629.dbf                           NO  NO
    +DGARCH/whut/3_22648_611942629.dbf                           NO  NO
    +DGARCH/whut/3_22648_611942629.dbf                           NO  YES
    +DGARCH/whut/3_22291_611942629.dbf                           YES YES
    +DGARCH/whut/2_62553_611942629.dbf                           NO  NO
    +DGARCH/whut/2_62552_611942629.dbf                           NO  NO
    +DGARCH/whut/2_62551_611942629.dbf                           NO  NO
    +DGARCH/whut/2_62550_611942629.dbf                           NO  NO
    query the first_change# on the standby db like this :
    SEQUENCE# FIRST_CHANGE# APP ARC
    22646 2983721221 NO YES
    22647 2983911304 NO YES
    22648 2984028173 NO YES
    23813 2984013365 NO YES
    23814 2984118027 NO YES
    62546 2984027708 NO YES
    SEQUENCE# FIRST_CHANGE# APP ARC
    62547 2984163823 NO YES
    23815 2984132128 NO YES
    23816 2984312713 NO YES
    62548 2984255538 NO YES
    62549 2984312692 NO YES
    22649 2984028196 NO YES
    23817 2984351070 NO YES
    then ,how to fix the dataguard and apply the archivelog on standby db ?
    why I can found 2984028173 with 22648,but can not found 2984013192 ??
    and why there have three 22648 with different applied status and deleted status on standby db ???
    Thanks all.

    Thank you for your reply.
    the trc file like this:
    /oracle/admin/xxx/bdump/xxx_mrp0_12863.trc
    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
    With the Partitioning, OLAP and Data Mining options
    ORACLE_HOME = /oracle/product/10.2.0/database
    System name:     SunOS
    Node name:     stdb
    Release:     5.9
    Version:     Generic_122300-25
    Machine:     sun4u
    Instance name: xxx
    Redo thread mounted by this instance: 1
    Oracle process number: 27
    Unix process pid: 12863, image: oracle@stdb (MRP0)
    *** SERVICE NAME:() 2009-01-08 15:44:24.179
    *** SESSION ID:(197.3) 2009-01-08 15:44:24.179
    ARCH: Connecting to console port...
    *** 2009-01-08 15:44:24.180 61287 kcrr.c
    MRP0: Background Managed Standby Recovery process started
    *** 2009-01-08 15:44:29.191 1103 krsm.c
    Managed Recovery: Initialization posted.
    *** 2009-01-08 15:44:29.192 61287 kcrr.c
    Managed Standby Recovery starting Real Time Apply
    Recovery target incarnation = 5, activation ID = 721050634
    Influx buffer limit = 152383 (50% x 304766)
    Successfully allocated 3 recovery slaves
    Using 367 overflow buffers per recovery slave
    Start recovery at thread 3 ckpt scn 2984013192 logseq 22648 block 2
    *** 2009-01-08 15:44:31.181
    Media Recovery add redo thread 3
    *** 2009-01-08 15:44:31.181
    Media Recovery add redo thread 1
    *** 2009-01-08 15:44:31.182
    Media Recovery add redo thread 2
    *** 2009-01-08 15:44:31.184 1103 krsm.c
    Managed Recovery: Active posted.
    *** 2009-01-08 15:44:31.838
    Media Recovery Log +DGARCH/whut/3_22648_611942629.dbf
    *** 2009-01-08 15:44:31.851 61287 kcrr.c
    MRP0: Background Media Recovery terminated with error 326
    ORA-00326: log begin at 2984028173, need earlier 2984013192
    ORA-00334: archivelog: '+DGARCH/whut/3_22648_611942629.dbf'
    *** 2009-01-08 15:44:31.851 61287 kcrr.c
    Managed Standby Recovery not using Real Time Apply
    *** 2009-01-08 15:44:31.851
    Media Recovery drop redo thread 3
    *** 2009-01-08 15:44:31.851
    Media Recovery drop redo thread 1
    *** 2009-01-08 15:44:31.851
    Media Recovery drop redo thread 2
    *** 2009-01-08 15:44:34.269 1103 krsm.c
    Managed Recovery: Not Active posted.
    ORA-00326: log begin at 2984028173,need earlier 2984013192
    ORA-00334: archivelog: '+DGARCH/whut/3_22648_611942629.dbf'
    ARCH: Connecting to console port...
    *** 2009-01-08 15:44:34.359 61287 kcrr.c
    MRP0: Background Media Recovery process shutdown
    *** 2009-01-08 15:44:34.359 1103 krsm.c

  • Standby not applying log - DATAGUARD

    Hi pros and gurus,
    I have encountered a problem which is i don't know how to solve it is since every single log working just fine. I already done creating RMAN files and instantiate it later. But after i bring up standy for receiving logs from primary and apply it, nothing is happening. At the end of instantiate standby database, i got this error:
    RMAN 03015 error occurred in stored script Memory Script
    RMAN 06136 ORACLE error from auxiliary database
    ora-01180 cannot create data file 1
    ora-01110 data file 1 '.../system_1.dbf
    is this error affecting my replication? Please help me.

    syns wrote:
    Hi pros and gurus,
    I have encountered a problem which is i don't know how to solve it is since every single log working just fine. I already done creating RMAN files and instantiate it later. But after i bring up standy for receiving logs from primary and apply it, nothing is happening. At the end of instantiate standby database, i got this error:
    RMAN 03015 error occurred in stored script Memory Script
    RMAN 06136 ORACLE error from auxiliary database
    ora-01180 cannot create data file 1
    ora-01110 data file 1 '.../system_1.dbf
    is this error affecting my replication? Please help me.Can u paste the command which you are running on rman prompt with error message?
    Check alert log file ?
    Post the steps u are following ...
    --neeraj                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • 7.5 Standby apply log issue - Cold backup of standby

    We are in the process of migrating to 7.8 from 7.5 and have a 7.5 standby. Needed to test the time is takes to backup from the standby once we go-live on the 7.8 64bit server. Logs have been applied to the 7.5 standby for more than a month just fine prior to doing a "cold" backup test on the standby. Now the logs will not apply to the standby.
    ERR 20039 Log 
    Logrecovery is not allowed, because state of log volume is 'HistoryLost' (log must be cleared)
    2014-05-04 10:02:16 
    0xF28 WRN 20026 Admin
    Initialization of log for 'restore log' failed with 'LogAndDataIncompatible'
    First - backing up the standby in ADMIN mode / cold backup on the standby database, right?  The source and target (standby) have different server names.
    Is it possible to clear the log area or some other process to fix the issue?

    Hi Mike,
    You may need to restore the database with re-intialization and clear the logs
    Refer to the copy steps described in the thread
    Error while recover logs
    Hope this helps.
    Regards,
    Deepak Kori

  • Error in standby db while applying logs

    Hi,
    we have a manual standby db of version 9.2.0.6 on sun solaris
    in alert log file i found error in one og the log i.e Errors with log /arch/log/1_1817.dbf
    ALTER DATABASE RECOVER    CONTINUE DEFAULT
    Wed Oct 22 18:33:03 2008
    Media Recovery Log /arch/log/2_1616.dbf
    Wed Oct 22 18:35:47 2008
    ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
    Wed Oct 22 18:35:47 2008
    ALTER DATABASE RECOVER    CONTINUE DEFAULT
    Wed Oct 22 18:35:47 2008
    Media Recovery Log /arch/log/2_1617.dbf
    Wed Oct 22 18:36:50 2008
    ORA-279 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
    Wed Oct 22 18:36:50 2008
    ALTER DATABASE RECOVER    CONTINUE DEFAULT
    Wed Oct 22 18:36:50 2008
    Media Recovery Log /arch/log/1_1817.dbf
    Errors with log /arch/log/1_1817.dbf
    ORA-308 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
    Wed Oct 22 18:36:50 2008
    ALTER DATABASE RECOVER CANCEL
    Wed Oct 22 18:36:50 2008
    Media Recovery Cancelled
    Completed: ALTER DATABASE RECOVER CANCEL
    Wed Oct 22 18:37:38 2008
    alter database open read only
    Wed Oct 22 18:37:38 2008
    SMON: enabling cache recovery
    Wed Oct 22 18:37:38 2008
    Database Characterset is WE8ISO8859P1
    replication_dependency_tracking turned off (no async multimaster replication fo
    nd)
    Completed: alter database open read only
    Wed Oct 22 18:39:33 2008
    Errors in file /arch/dump/udump/icai_ora_25288.trc:
    ORA-00600: internal error code, arguments: [2662], [0], [1823949223], [0], [197
    003713], [4194306], [], []
    Wed Oct 22 18:39:45 2008
    Errors in file /arch/dump/udump/icai_ora_25288.trc:
    ORA-00600: internal error code, arguments: [2662], [0], [1823949225], [0], [197
    003713], [4194306], [], []
    ORA-00600: internal error code, arguments: [2662], [0], [1823949223], [0], [197
    003713], [4194306], [], []
    003713], [4194306], [], []i want to konw the whether the system had applied the 1_1817.dbf logs or not if db server generates an error on one of the logs...
    looking for your reply...

    SQL> select * from v$log_history;
         RECID      STAMP    THREAD#  SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE#
          3421  668092912          2       1613    1821523608 08-OCT-08   1822019922
          3422  668092971          1       1809    1821576072 08-OCT-08   1821777080
          3423  668093151          1       1810    1821777080 10-OCT-08   1822019918
          3424  668093340          1       1811    1822019918 11-OCT-08   1822282436
          3425  668284338          2       1614    1822019922 11-OCT-08   1822677394
          3426  668284525          1       1812    1822282436 13-OCT-08   1822526199
          3427  668284721          1       1813    1822526199 14-OCT-08   1822781536
          3428  668801898          2       1615    1822677394 15-OCT-08   1823381495
          3429  668801993          1       1814    1822781536 15-OCT-08   1823106551
          3430  668802398          1       1815    1823106551 17-OCT-08   1823381490
          3431  668802577          1       1816    1823381490 18-OCT-08   1823923486
         RECID      STAMP    THREAD#  SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE#
          3432  668802783          2       1616    1823381495 18-OCT-08   1823814529
          3433  668802947          2       1617    1823814529 20-OCT-08   1824079514
    453 rows selected.
    SQL>so here we can see that there is not recid for 1817 sequence that has been corrupted ,so now does it mean that archived have not been applied to the stanby database.....
    SQL> SELECT MAX(R.SEQUENCE#) LAST_SEQ_RECD, MAX(L.SEQUENCE#) LAST_SEQ_SENT FROM
      2  V$ARCHIVED_LOG R, V$LOG L WHERE
      3  R.DEST_ID=1 AND L.ARCHIVED='YES';
    LAST_SEQ_RECD LAST_SEQ_SENT
    ------------- -------------Edited by: user00726 on Oct 23, 2008 3:21 AM

  • Standby db doesn't apply logs

    hi all,
    my problem is that none archive logs are actually applied to the standby database
    Background Managed Standby Recovery process started
    Starting datafile 1 recovery in thread 1 sequence 15536
    Datafile 1: '/oracle/ean1/database/data/EAN1_SYSTEM01.dbf'
    Starting datafile 2 recovery in thread 1 sequence 15536
    Datafile 2: '/oracle/ean1/database/data/EAN1_UNDO01.dbf'
    Starting datafile 3 recovery in thread 1 sequence 15536
    Datafile 3: '/oracle/ean1/database/data/EAN1_D01_DATA01.dbf'
    Starting datafile 4 recovery in thread 1 sequence 15536
    Datafile 4: '/oracle/ean1/database/data/EAN1_I01_DATA01.dbf'
    Thu Sep 7 15:36:12 2006
    Completed: alter database recover managed standby database di
    Thu Sep 7 15:36:12 2006
    Media Recovery Waiting for thread 1 seq# 15536
    the actual log file on the stdb is 15535 and on the prd-db 15549
    can someone help me?

    Due to some error archive gap occurred in your setup. V$ARCHIVE_GAP can help you. Copy the missing archive logs to standby database and register them as follows.
    SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE /disk1/oracle/dbs/log-1292880008_10.arc;
    After you register these logs on the logical standby database, you can restart log apply services.
    -aijaz

  • Applying logs in a semi-standby instance

    Oracle Version: 10.2.0.3 Standard Edition
    OS: Windows 2003 Server
    I setup oracle standby (followed the steps in metalink doc 432514.1)..
    I am running 10.2.0.3 standard edition.. so teh standby have to be done manually (which is fine)..
    I shutdown production last night with shutdown immediate.. copy all the logs, datafiles, pfile..etc to the standby server.. I recreated the controlfile on the standby (NORESETLOGS and NOARCHIVELOGS).. the database is mounted and it's ok:
    SQL> select status from v$instance;
    STATUS
    MOUNTED
    SQL>
    SQL> select * from v$log;
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6764 52428800 2 NO INACTIVE 2437870303 07-MAY-09
    3 1 6765 52428800 2 NO INACTIVE 2437871111 07-MAY-09
    2 1 6766 52428800 2 NO CURRENT 2437886254 07-MAY-09
    SQL>
    then after that I restarted production, after a while, I did a couple of switch logs and generated 2 archive logs of which I transferred to the standby to apply them.. now at this stage prod redo logs are:
    SQL> select * from v$log
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6767 52428800 2 YES INACTIVE 2438366118 08-MAY-09
    2 1 6766 52428800 2 YES INACTIVE 2437886254 07-MAY-09
    3 1 6768 52428800 2 NO CURRENT 2438369450 08-MAY-09
    SQL>
    On the standby, I logged in as sysdba and tried to just apply the logs as you do normally:
    C:\scheduled_scripts>sqlplus "/as sysdba"
    SQL*Plus: Release 10.2.0.3.0 - Production on Fri May 8 08:58:03 2009
    Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
    Connected to:
    Oracle Database 10g Release 10.2.0.3.0 - Production
    SQL> select status from v$instance;
    STATUS
    MOUNTED
    SQL>
    SQL>
    SQL> recover database using backup controlfile until cancel;
    ORA-00279: change 2438369450 generated at 05/08/2009 07:45:07 needed for thread
    1
    ORA-00289: suggestion :
    D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6768_%U_.ARC
    ORA-00280: change 2438369450 for thread 1 is in sequence #6768
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6767_508KCMM0_.ARC
    ORA-00310: archived log contains sequence 6767; sequence 6768 required
    ORA-00334: archived log:
    'D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6767_508KCMM0_.ARC'
    SQL>
    So my question is why isn't it applying the 6767 change? (keep in mind that at this stage production has not yet generated archive log 6768).. shouldn't it be applying 6767? or is it bcoz it's Inactive, it doesn't need to do that?
    More over, I did the following:
    I did a switch log on production to create the 6768 archive log:
    SQL> select * from v$log
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6767 52428800 2 YES INACTIVE 2438366118 08-MAY-09
    2 1 6766 52428800 2 YES INACTIVE 2437886254 07-MAY-09
    3 1 6768 52428800 2 NO CURRENT 2438369450 08-MAY-09
    SQL>
    SQL>
    SQL> alter system switch logfile;
    System altered.
    SQL> select * from v$log;
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6767 52428800 2 YES INACTIVE 2438366118 08-MAY-09
    2 1 6769 52428800 2 NO CURRENT 2438387289 08-MAY-09
    3 1 6768 52428800 2 YES ACTIVE 2438369450 08-MAY-09
    this generated teh archive log: O1_MF_1_6768_508VGSS5_.ARC
    I copied the archive log to the standby serve.. checked teh current sequence (database only mounted on standby):
    SQL> select * from v$log
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6764 52428800 2 NO INACTIVE 2437870303 07-MAY-09
    3 1 6765 52428800 2 NO INACTIVE 2437871111 07-MAY-09
    2 1 6766 52428800 2 NO CURRENT 2437886254 07-MAY-09
    C:\scheduled_scripts>sqlplus "/as sysdba"
    SQL*Plus: Release 10.2.0.3.0 - Production on Fri May 8 10:46:38 2009
    Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
    Connected to:
    Oracle Database 10g Release 10.2.0.3.0 - Production
    SQL> recover database using backup controlfile until cancel;
    ORA-00279: change 2438369450 generated at 05/08/2009 07:45:07 needed for thread1
    ORA-00289: suggestion :
    D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6768_%U_.ARC
    ORA-00280: change 2438369450 for thread 1 is in sequence #6768
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    AUTO
    ORA-00279: change 2438387289 generated at 05/08/2009 10:37:29 needed for thread1
    ORA-00289: suggestion :
    D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6769_%U_.ARC
    ORA-00280: change 2438387289 for thread 1 is in sequence #6769
    ORA-00278: log file
    'D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6768_508VGSS5_.ARC' no longer needed for this recovery
    ORA-00308: cannot open archived log
    'D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6769_%U_.ARC'
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 2) The system cannot find the file specified.
    and as you can see.. now that it has 6768, it's doing the same thing by not wanting it anymore and wanting the next one in teh sequence which is 6769 (which has not been generated on production yet).. I'm just not making any sense out of this!!
    now afer few changes, the production sequence is:
    SQL> select * from v$log;
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6773 52428800 2 YES ACTIVE *2438396976* 08-MAY-09
    2 1 6772 52428800 2 YES INACTIVE 2438394852 08-MAY-09
    3 1 6774 52428800 2 NO CURRENT 2438398862 08-MAY-09
    standby sequence is:
    SQL> SELECT * FROM V$LOG;
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6764 52428800 2 NO INACTIVE 2437870303 07-MAY-09
    3 1 6765 52428800 2 NO INACTIVE 2437871111 07-MAY-09
    2 1 6766 52428800 2 NO CURRENT 2437886254 07-MAY-09
    If I try to do the following on standby (archived has been shipped to standby at this stage) and do the AUTO option, it doesnt like the file:
    SQL> RECOVER DATABASE using backup controlfile UNTIL CHANGE 2438396976;
    ORA-00279: change 2438396976 generated at 05/08/2009 11:45:02 needed for thread 1
    ORA-00289: suggestion : D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6773_%U_.ARC
    ORA-00280: change 2438396976 for thread 1 is in sequence #6773
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    AUTO
    ORA-00308: cannot open archived log 'D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6773_%U_.ARC'
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 2) The system cannot find the file specified.
    ORA-00308: cannot open archived log 'D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6773_%U_.ARC'
    ORA-27041: unable to open file
    OSD-04002: unable to open file
    O/S-Error: (OS 2) The system cannot find the file specified.
    but when i try to do the same and I actuially give it the proper file name (no _%U) then it's ok and does the recovery.. Is there a way of telling Oracle to grab the acual file name, not O1_MF_1_6773_50909L7L_.ARC instead of O1_MF_1_6773_%U_.ARC?
    SQL> RECOVER DATABASE using backup controlfile UNTIL CHANGE *2438396976*;
    ORA-00279: change 2438396976 generated at 05/08/2009 11:45:02 needed for thread 1
    ORA-00289: suggestion : D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6773_%U_.ARC
    ORA-00280: change 2438396976 for thread 1 is in sequence #6773
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    D:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\EBCP01\ARCHIVELOG\2009_05_08\O1_MF_1_6773_50909L7L_.ARC
    Log applied.
    Media recovery complete.
    hmm.. now when would it actually update the sequence numbers on the logs, I am asking this bcoz the sequence on teh standby still reads:
    SQL> SELECT * FROM V$LOG;
    GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
    1 1 6764 52428800 2 NO INACTIVE 2437870303 07-MAY-09
    3 1 6765 52428800 2 NO INACTIVE 2437871111 07-MAY-09
    2 1 6766 52428800 2 NO CURRENT 2437886254 07-MAY-09
    I am lost here!!! and I'm not sure what to do about this! Your help is really appreciated.
    Thanks

    The "readme" for Patch 9369783 (which covers the AprilCPU for our 11.1.0.7 HPUX-IA64 environment) includes this short reference to DataGuard:
    If you are using a Data Guard Physical Standby database, you must first install this patch on the primary database before installing the patch on the physical standby database. It is not supported to install this patch on the physical standby database before installing the patch on the primary database. For more information, see My Oracle Support Note 278641.1.
    When checking that note 278641.1 we see that it also appears to only cover 10.2. Although this note has more detail, it is clearly the same procedure as discussed in 813445.1. Therefore, the conclusion that I make is: OPatch works exactly the same with DataGuard in 11g as it did in 10g.
    We will be upgrading our DataGuard enviornment to 11g in one-month. At this point, I am completely expecting our OPatch procedures to remain unchanged from what we have done for years with 9i and 10g. I would also note that the upgrade procedures we have tested (involving DG from 10.2.0.4 to 11.1.0.7) are nearly identical to the above mentioned support notes.
    Hope that helps,
    Stan

  • 10gR2 Logical Standby database not applying logs

    No errors are appearing in the logs and I've started the apply process :ALTER DATABASE START LOGICAL STANDBY APPLY but when I query dba_logstdby_log, none of the logs for the last 4 days shows as applied and the first SCN is still listed as current. Any thoughts on where I should start looking?
    the latest event in DBA_LOGSTDBY_EVENTS is the startup of the log mining and apply.
    I do not have standby redo logs so I cannot do real time apply, though I am looking to implementing this. Obviously, this is pretty new to me.

    Sorry I didn't mention this before, the logs are being transferred, I verified their location on the os and it matches the location in the dba_logstdby_log view.

  • Problem for applying logs automatically to Standby

    DBAz,
    In my Dataguard , The primary database is archiving to the standby location.
    But after that when we are verifying using following queries Its showing
    that, the recently archived log is not applied.
    Also From the primary it looks like the log were shipped twice.
    I am using Maximum Performance protection mode . Is it necessary to run the
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
    command each and every time to
    synchronize the standby with primary ?
    Will it be automatically updated when ever a SCN changed ?
    More specifically. How Could i automatically update a standby database based
    on primary.
    I think the rodo logs are not perfectly applying to the standby.
    Iam sure that I have configuared that as per documentation.
    can anybody suggest a solution....
    I can show u the status of logs too-
    Primary =>
    SQL> select SEQUENCE# ,FIRST_TIME , NEXT_TIME ,ARCHIVED,APPLIED,CREATOR
    2 from v$archived_log;
    SEQUENCE# FIRST_TIM NEXT_TIME ARC APP CREATOR
    139 26-FEB-07 26-FEB-07 YES NO ARCH
    140 26-FEB-07 26-FEB-07 YES NO ARCH
    141 26-FEB-07 26-FEB-07 YES NO ARCH
    142 26-FEB-07 27-FEB-07 YES NO ARCH
    143 27-FEB-07 07-APR-07 YES NO ARCH
    144 07-APR-07 16-MAR-07 YES NO ARCH
    145 16-MAR-07 20-MAR-07 YES NO ARCH
    146 20-MAR-07 20-MAR-07 YES NO ARCH
    147 20-MAR-07 21-MAR-07 YES NO FGRD
    148 21-MAR-07 21-MAR-07 YES NO ARCH
    149 21-MAR-07 21-MAR-07 YES NO ARCH
    SEQUENCE# FIRST_TIM NEXT_TIME ARC APP CREATOR
    150 21-MAR-07 21-MAR-07 YES NO FGRD
    151 21-MAR-07 22-MAR-07 YES NO ARCH
    152 22-MAR-07 22-MAR-07 YES NO ARCH
    152 22-MAR-07 22-MAR-07 YES NO ARCH
    153 22-MAR-07 22-MAR-07 YES NO FGRD
    153 22-MAR-07 22-MAR-07 YES YES FGRD
    154 22-MAR-07 22-MAR-07 YES NO ARCH
    154 22-MAR-07 22-MAR-07 YES YES ARCH
    155 22-MAR-07 24-MAR-07 YES NO FGRD
    155 22-MAR-07 24-MAR-07 YES NO FGRD
    156 24-MAR-07 24-MAR-07 YES NO ARCH
    SEQUENCE# FIRST_TIM NEXT_TIME ARC APP CREATOR
    156 24-MAR-07 24-MAR-07 YES YES ARCH
    157 24-MAR-07 26-MAR-07 YES NO ARCH
    157 24-MAR-07 26-MAR-07 YES NO ARCH
    158 26-MAR-07 26-MAR-07 YES NO FGRD
    158 26-MAR-07 26-MAR-07 YES NO FGRD
    27 rows selected.
    Standby =>
    SQL> select SEQUENCE# ,FIRST_TIME , NEXT_TIME ,ARCHIVED,APPLIED,CREATOR
    2 from v$archived_log;
    SEQUENCE# FIRST_TIM NEXT_TIME ARC APP CREATOR
    152 22-MAR-07 22-MAR-07 YES YES ARCH
    153 22-MAR-07 22-MAR-07 YES YES FGRD
    154 22-MAR-07 22-MAR-07 YES YES ARCH
    155 22-MAR-07 24-MAR-07 YES YES FGRD
    156 24-MAR-07 24-MAR-07 YES YES ARCH
    157 24-MAR-07 26-MAR-07 YES NO ARCH
    158 26-MAR-07 26-MAR-07 YES NO FGRD
    7 rows selected.
    SQL> select sequence#, archived, applied
    2 from v$archived_log order by sequence#;
    SEQUENCE# ARC APP
    152 YES YES
    153 YES YES
    154 YES YES
    155 YES YES
    156 YES YES
    157 YES NO
    158 YES NO
    7 rows selected.
    Regards,
    Raj

    Iam facing this problem at the very next moment after Dataguard configuration. because when i created some objects there in primary and when iam checking it on standby..its missing there.So i have queried all the above.
    Here is the last few lines from 'Alert log ' but i think its normal
    Primary =>
    Sat Mar 24 15:03:36 2007
    ARCH: Beginning to archive log 1 thread 1 sequence 155
    Creating archive destination LOG_ARCHIVE_DEST_2: 'stby4'
    Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/admin/mudra/arch/arch_155.arc'
    ARCH: Completed archiving log 1 thread 1 sequence 155
    Sat Mar 24 15:21:31 2007
    Thread 1 advanced to log sequence 157
    Current log# 3 seq# 157 mem# 0: /oracle/oradata/mudra/redo03.log
    Sat Mar 24 15:21:31 2007
    ARC0: Evaluating archive log 2 thread 1 sequence 156
    ARC0: Beginning to archive log 2 thread 1 sequence 156
    Creating archive destination LOG_ARCHIVE_DEST_2: 'stby4'
    Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/admin/mudra/arch/arch_156.arc'
    ARC0: Completed archiving log 2 thread 1 sequence 156
    Mon Mar 26 14:49:06 2007
    Thread 1 advanced to log sequence 158
    Current log# 1 seq# 158 mem# 0: /oracle/oradata/mudra/redo01.log
    Mon Mar 26 14:49:06 2007
    ARC1: Evaluating archive log 3 thread 1 sequence 157
    ARC1: Beginning to archive log 3 thread 1 sequence 157
    Creating archive destination LOG_ARCHIVE_DEST_2: 'stby4'
    Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/admin/mudra/arch/arch_157.arc'
    ARC1: Completed archiving log 3 thread 1 sequence 157
    Mon Mar 26 17:16:15 2007
    Thread 1 advanced to log sequence 159
    Current log# 2 seq# 159 mem# 0: /oracle/oradata/mudra/redo02.log
    Mon Mar 26 17:16:15 2007
    ARCH: Evaluating archive log 1 thread 1 sequence 158
    Mon Mar 26 17:16:15 2007
    ARC0: Evaluating archive log 1 thread 1 sequence 158
    ARC0: Unable to archive log 1 thread 1 sequence 158
    Log actively being archived by another process
    Mon Mar 26 17:16:15 2007
    ARCH: Beginning to archive log 1 thread 1 sequence 158
    Creating archive destination LOG_ARCHIVE_DEST_2: 'stby4'
    Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/admin/mudra/arch/arch_158.arc'
    ARCH: Completed archiving log 1 thread 1 sequence 158
    Standby =>
    also when iam giving the query -
    select SEQUENCE# from v$log_history;
    Primary got SEQUENCE# => 1....158
    Standby got SEQUENCE# = > 1...156

  • Check actual apply log time on standby database after synchronization

    Hi All,
    I want to check the date and time stamp of applied archived logs on stanby database. How should I check that??
    My dataguard link was broken for sometime and meanwhile lot of transactions happened on primary database. Now When the link came up the synchronisation happened within few hours and ultimatly transport and appliy lag became 0. But now I want to check actual time taken for tranporting the logs and applying them on standby database. Is there any way I could do that easily..
    Thanks

    This script written by Yousef Rifai I found here http://www.dba-village.com/village/dvp_forum.OpenThread?ThreadIdA=34772&DestinationA=RSS might be just what you need (run on standby database):
    set ver off
    alter session set nls_date_format='dd-mon-yy hh24:mi:ss'
    select app_thread, seq_app, tm_applied,
    nvl(seq_rcvd,seq_app) seq_rcvd, nvl(tm_rcvd,tm_applied) tm_rcvd
    from
    (select sequence# seq_app, FIRST_TIME tm_applied, thread# app_thread
    from v$archived_log where applied = 'YES'
    and (first_time, thread#) in (
    select max(FIRST_TIME ), thread#
    from v$archived_log where applied = 'YES'
    group by thread# )
    (select sequence# seq_rcvd, FIRST_TIME tm_rcvd, thread# rcvd_thread
    from v$archived_log where applied = 'NO'
    and (first_time, thread#) in (
    select max(FIRST_TIME ), thread#
    from v$archived_log where applied = 'NO'
    group by thread# )
    where rcvd_thread(+)= app_thread
    Best regards,
    Robert
    http://robertvsoracle.blogspot.com

  • Standby DB not applying logs

    Hi,
    i opened my primary DB using "alter database open resetlogs" after recovering from a power failure crash.
    this caused the log sequence number to reset to 1.
    when i check the standby DB for maximum log sequence applied, it is showing the last log applied before the crash whereas the primary DB has since the recovery, produced over 200 logs.
    how can i get the standby DB to start applying the new log sequence?
    regards,
    Michael

    If you had opened the Primary with a RESETLOGS to a point earlier than the highest log applied on the standby and you cannot flashback the standby, you have to rebuild the standby.
    For example, the Standby has applied Sequence#1411 but the Primary was opened with RECOVER upto Sequence#1409 and RESETLOGS. The Primary has diverged from the Standby so the standby has to be rebuilt.
    If however, the last redo applied to the Standby was lower than the RECOVER and RESETLOGS point on the primary, the Standby should be automatically able to continue. In your case, you say that the Standby hasn't continued. Therefore, I suspect the former (Primary RECOVER and RESETLOGS to a lower SCN/SEQUENCE#).
    See "9.4 Recovering Through the OPEN RESETLOGS Statement" at http://docs.oracle.com/cd/E11882_01/server.112/e25608/manage_ps.htm#i1026480
    Hemant K Chitale

  • Logical stopped applying logs after install STATSPACK

    Pl. help urgent
    Oracle 10.2.0.1.0
    After installing statspack @spcreate installed sucessfully
    @spauto create job sucessfully
    But the Logical stdby stopped applying the logs with the following error message
    alert.log
    ================
    LOGSTDBY stmt: grant execute on dbms_shared_pool to execute_catalog_role
    LOGSTDBY status: ORA-04042: procedure, function, package, or package body does not exist
    LOGSTDBY id: XID 0x000d.01b.00009d72, hSCN 0x0000.20c7cf14, lSCN 0x0000.20c7cf14, Thread 1, RBA
    0x6642.0000433b.138, txnCscn 0x0000.20c7cf17, PID 5544, ORACLE.EXE
    (P006)
    LOGSTDBY Apply process P006 pid=45 OS id=5544 stopped
    Wed Dec 19 16:13:10 2007
    ================
    Please help if anyone has any idea on this forum, how do i start the logs applying the to logical standby.
    Thanks

    Hi,
    Will the below steps clear the above error:
    Sql > alter database stop logical standby apply;
    Sql> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;
    Sql> alter database guard all;
    Sql> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 3000);
    Sql> Exec dbms_logstdby.apply_set('MAX_SERVERS',25);
    Sql> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS',12);
    Sql > alter database start logical standby apply;
    Please advice

Maybe you are looking for