Recover standby database

Our primary linux 10g db is in standard edition and we would like to manually create a standby database
After copying the control and datafiles from primary to standby database, started the standby instance ..
SQL> startup nomount pfile=/path/to/pfile/initSID.standby
SQL> alter database mount standby database;
SQL> recover standby database;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00308: cannot open archived log
'/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
How do I resolve this problem? Log sequence 833 is the current log on the primary db, archive log haven't been written yet. When I try to "alter database open read only" on the standby db, I get an error "ORA-01156: recovery in progress may need access to file".
I then went back to my primary database, which already had another log switch to 834, log 833 is now available, I then moved that archive log file to the standby db. Try to recover standby database again, but still got errors..
SQL> startup nomount pfile=/path/to/pfile/initSID.standby
SQL> alter database mount standby database;
SQL> recover standby database;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: '/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
SQL> alter database open read only;
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
Would something please explain this to me? What am I doing wrong? Thanks in advance.

I copied the missing archive log over to standby db, still got the same error.
1) SQL> recover standby database;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: '/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
I also tried..
2) SQL> recover standby database using backup controlfile until cancel;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: '/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
Edited by: user10427867 on Aug 28, 2009 5:56 AM

Similar Messages

  • Recover Standby Database suggests wrong filename

    Hi,
    I am running Oracle Database 10g Release 10.2.0.3.0 - 64bit Production Standard Edition on Linux version 2.6.9-42.0.8.ELsmp ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3))
    I've created a physical standby database, but since I am running Standard Edition, I am not using the DataGuard features. I use the rsync utility to copy over the archivelogs to the standby database, and I apply them periodically to the standby database.
    The standby database is started this way :
    startup nomount pfile='/u01/oradata/orcl/initorcl.stdby';
    alter database mount standby database;
    And the archives are applied this way :
    recover standby database;
    AUTO
    (AUTO for the command to apply all available archive logs automatically, using the suggested paths and filenames)
    My problem is that once in a while (maybe once every 2-3 weeks), the suggested filename does not have the same format as the rest of the time. I then have to manually specify the correct filename and it goes fine after that.
    Example :
    In this example, you will see that it is first looking for sequence 22907 (o1_mf_1_22907_5n3m1xrf_.arc), then 22908 (o1_mf_1_22908_5n3m4kf0_.arc) [Notice the format of the file name] and then tries to look for sequence 22909, but looks for filename ".o1_mf_1_22909_5n3md1h5_.arc.qXMz5s"
    Mon Jan 4 06:22:01 2010
    ALTER DATABASE RECOVER standby database
    Media Recovery Start
    Managed Standby Recovery not using Real Time Apply
    ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
    Mon Jan 4 06:22:02 2010
    ALTER DATABASE RECOVER CONTINUE DEFAULT
    Mon Jan 4 06:22:02 2010
    Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/o1_mf_1_22907_5n3m1xrf_.arc
    Mon Jan 4 06:24:20 2010
    ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
    Mon Jan 4 06:24:20 2010
    ALTER DATABASE RECOVER CONTINUE DEFAULT
    Mon Jan 4 06:24:20 2010
    Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/o1_mf_1_22908_5n3m4kf0_.arc
    Mon Jan 4 06:24:46 2010
    ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
    Mon Jan 4 06:24:46 2010
    ALTER DATABASE RECOVER CONTINUE DEFAULT
    Mon Jan 4 06:24:46 2010
    Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/.o1_mf_1_22909_5n3md1h5_.arc.qXMz5s
    Errors with log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/.o1_mf_1_22909_5n3md1h5_.arc.qXMz5s
    ORA-308 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
    Mon Jan 4 06:24:46 2010
    ALTER DATABASE RECOVER CANCEL
    Mon Jan 4 06:24:46 2010
    Media Recovery Canceled
    Completed: ALTER DATABASE RECOVER CANCEL
    Can someone explain to me why is this happening please ?
    Thanks a lot,
    Mat

    @fjfranken
    Yes. If I manually enter the name of the file for the sequence requested instead of passing the suggested fielname, it works fine.
    And the log_archive_format is not defined, I am using the flash_recovery_area and let Oracle manage this automatically.
    @Hemant K Chitale
    Unfortunately, those sequences are not listed anymore in the V$ARCHIVED_LOG view.
    Well, I think the the problem might be related to files that are being written to at some time...
    Thanks,
    Mat

  • Auto specified any value after ran RECOVER STANDBY DATABASE;

    Dear all,
    When i ran the RECOVER STANDBY DATABASE command.It 's will prompt as
    below :
    SQL> RECOVER STANDBY DATABASE;
    ORA-00279: change 302927 generated at 09/10/2007 14:08:24 needed for thread 1
    ORA-00289: suggestion : D:\ORACLE\ORADATA\DB817\ARCHIVE\DB817T001S00021.ARC
    ORA-00280: change 302927 for thread 1 is in sequence #21
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    Is there anyway to force specified "AUTO" automatically ?
    Because i will to create a scripts file for run automatic .
    Thanks for advance !
    Chara

    ORA-00289: suggestion : D:\ORACLE\ORADATA\DB817\ARCHIVE\DB817T001S00021.ARCFirst check if the required Archive / Redo log is present on your system under the directory "D:\ORACLE\ORADATA\DB817\ARCHIVE".
    For automatic recovery use:
    ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE;
    or
    RECOVER AUTOMATIC STANDBY DATABASE;
    Cheers!

  • Recover standby database error

    Hi
    here is the error message i got when i run this command
    09:30:35 SYS@MOZAI> alter database recover standby database until cancel;
    alter database recover standby database until cancel
    ERROR at line 1:
    ORA-00279: change 126425376421 generated at 02/26/2012 09:26:00 needed for thread 2
    ORA-00289: suggestion : +ARCH
    ORA-00280: change 126425376421 for thread 2 is in sequence #312362
    Any suggestion is highly apprciated .
    Thanks

    Hello;
    You probably started the recovery ( to apply redo from the Primary )
    Cancel this before doing the command you trying :
    alter database recover managed standby database cancel;Then issue your command again.
    Best Regards
    mseberg

  • Recover standby database apply archivelog slow

    1.recover managed standby database disconnect from session;
    2.view alert file,find apply a achivelog last block need 10m
    3.view metalink MAA - Data Guard Redo Apply and Media Recovery Best Practices 10gR1
    modify database parameter,still is slow
    3.view v$managed_standby
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:49:09
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:56
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:57
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:57
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
    SQL>
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
    SQL> /
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
    SQL> //
    PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
    MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
    4. dump mrp
    SO: 0xc103c9b58, type: 4, owner: 0xc172b7820, flag: INIT/-/-/0x00
    (session) sid: 1087 trans: (nil), creator: 0xc172b7820, flag: (51) USR/- BSY/-/-/-/-/-
    DID: 0001-0013-00000002, short-term DID: 0000-0000-00000000
    txn branch: (nil)
    oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS
    service name: SYS$BACKGROUND
    waiting for 'PX Deq: Par Recov Reply' blocking sess=0x(nil) seq=6397 wait_time=0 seconds since wait started=3
    sleeptime/senderid=10010000, passes=19f, =0
    Dumping Session Wait History
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1953964
    sleeptime/senderid=10010000, passes=19e, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954140
    sleeptime/senderid=10010000, passes=19d, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954066
    sleeptime/senderid=10010000, passes=19c, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954065
    sleeptime/senderid=10010000, passes=19b, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954129
    sleeptime/senderid=10010000, passes=19a, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954061
    sleeptime/senderid=10010000, passes=199, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1953991
    sleeptime/senderid=10010000, passes=198, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954123
    sleeptime/senderid=10010000, passes=197, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954120
    sleeptime/senderid=10010000, passes=196, =0
    for 'PX Deq: Par Recov Reply' count=1 wait_time=1954073
    sleeptime/senderid=10010000, passes=195, =0
    5.how to read dump process file
    Edited by: 852786 on 2011-4-16 上午1:46

    SO: 0xbf34d65b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4990d0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000001A-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426408, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426418
    SO: 0xbf34d6570, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f499020, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000019-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426380, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426390
    SO: 0xbf34d6530, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498f88, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000018-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174262f8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426308
    SO: 0xbf34d64f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498ef0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000017-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426270, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426280
    SO: 0xbf34d64b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498e58, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000016-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174261e8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174261f8
    SO: 0xbf34d6470, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498dc0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000015-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426160, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426170
    SO: 0xbf34d6430, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498d28, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000014-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174260d8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174260e8
    SO: 0xbf34d63f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498c90, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000013-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17426050, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426060
    SO: 0xbf34d63b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498bf8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000012-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425fc8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425fd8
    SO: 0xbf34d6370, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498b60, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000011-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425f40, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425f50
    SO: 0xbf34d6330, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498ac8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000010-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425eb8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425ec8
    SO: 0xbf34d62f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498a30, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000F-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425e30, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425e40
    SO: 0xbf34d62b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498998, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000E-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425da8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425db8
    SO: 0xbf34d6270, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498900, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000D-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425d20, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425d30
    SO: 0xbf34d6230, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498868, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000C-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425c80, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425c90
    SO: 0xbf34d61f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4987d0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000B-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425bf8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425c08
    SO: 0xbf34d61b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498738, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-0000000A-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425b70, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425b80
    SO: 0xbf34d6170, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498688, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000009-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425ae8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425af8
    SO: 0xbf34d6130, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4985f0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000008-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425a60, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425a70
    SO: 0xbf34d60f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498558, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000007-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174259d8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174259e8
    SO: 0xbf34d60b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4984c0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000006-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425950, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425960
    SO: 0xbf34d6070, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498428, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000005-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174258c8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174258d8
    SO: 0xbf34d6030, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498390, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000004-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425840, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425850
    SO: 0xbf34d5ff0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4982f8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000003-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174257b8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174257c8
    SO: 0xbf34d5fb0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f498260, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000002-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425730, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425740
    SO: 0xbf34d5f70, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    SO: 0xc0f4981c8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000001-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc174256a8, mode: SSX, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174256b8
    SO: 0xc0f498130, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) FS-00000000-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425510, mode: S, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425520
    SO: 0xc0f498000, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
    (enqueue) MR-00000000-00000000     DID: 0001-0016-00000002
    lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
    res: 0xc17425488, mode: S, lock_flag: 0x0
    own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425498
    SO: 0xc13fe20e8, type: 61, owner: 0xc0e403c70, flag: INIT/-/-/0x00
    Process Queue--kxfpq: 0x0xc13fe20e8, serial: 513, # of qrefs: 16,
    inc: 0
    client 2, detached proc: 0x(nil), QC qref 0x(nil), flags: FEML
    Queue Descriptor--kxfpqd: 0x0xc13fe2140, remote queue addr: 0x0xc1
    3fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdd200, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdd200, ser: 513, seq: 1123, err
    or: 0
    opp qref: 0x0xc13fdbb50, process: 0x0xc0e2c33e8, bufs: {0x(nil),
    0x0xb3fe124f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdd310, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdd248, remote queue addr: 0x
    0xc13fdfb40
    instance id: 1, server id: 15, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fe124f8, 0x0xb3fe224f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fe124f8, type: DTA, bufnum: 1
    ser: 513, seq: 1117, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdbb50, from qref: 0x0xc13fdd200, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fe12550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdd410, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdd410, ser: 513, seq: 936, erro
    r: 0
    opp qref: 0x0xc13fdbd60, process: 0x0xc172b8fd8, bufs: {0x(nil),
    0x0xb3fe024f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdd520, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdd458, remote queue addr: 0x
    0xc13fdfd98
    instance id: 1, server id: 14, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fe024f8, 0x0xb3fdf24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fe024f8, type: DTA, bufnum: 1
    ser: 513, seq: 926, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdbd60, from qref: 0x0xc13fdd410, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fe02550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdd620, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdd620, ser: 513, seq: 1076, err
    or: 0
    opp qref: 0x0xc13fdc5a0, process: 0x0xc0f28aa28, bufs: {0x0xb3fd
    d24f8, 0x0xb3fdc24f8}
    state: 10010, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdd730, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdd668, remote queue addr: 0x
    0xc13fdfff0
    instance id: 1, server id: 13, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fdd24f8, 0x0xb3fdc24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fdd24f8, type: DTA, bufnum: 0
    ser: 513, seq: 1069, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdc5a0, from qref: 0x0xc13fdd620, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fdd2550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    Message Buffer--kxfpmh: 0x0xb3fdc24f8, type: DTA, bufnum: 1
    ser: 513, seq: 1076, flags: DIAL, status: RCV, err: 0
    to qref: 0x0xc13fdd620, from qref: 0x0xc13fdc5a0, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fdc2550, remote queue addr:
    0x0xc13fdfff0
    instance id: 1, server id: 13, flags: INIT
    can't dump contents, client unknown
    SO: 0xc13fdda40, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdda40, ser: 513, seq: 1209, err
    or: 0
    opp qref: 0x0xc13fdc7b0, process: 0x0xc102860a8, bufs: {0x(nil),
    0x0xb3fe324f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fddb50, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdda88, remote queue addr: 0x
    0xc13fe0248
    instance id: 1, server id: 12, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fe324f8, 0x0xb3fda24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fe324f8, type: DTA, bufnum: 1
    ser: 513, seq: 1203, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdc7b0, from qref: 0x0xc13fdda40, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fe32550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fddc50, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fddc50, ser: 513, seq: 822, erro
    r: 0
    opp qref: 0x0xc13fdc180, process: 0x0xc0c28be50, bufs: {0x(nil),
    0x0xb3fd924f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fddd60, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fddc98, remote queue addr: 0x
    0xc13fe04a0
    instance id: 1, server id: 11, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fd924f8, 0x0xb3f069230}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fd924f8, type: DTA, bufnum: 1
    ser: 513, seq: 816, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdc180, from qref: 0x0xc13fddc50, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fd92550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdde60, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdde60, ser: 513, seq: 829, erro
    r: 0
    opp qref: 0x0xc13fdbf70, process: 0x0xc0d2a44f8, bufs: {0x(nil),
    0x0xb3f456dc8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fddf70, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fddea8, remote queue addr: 0x
    0xc13fe06f8
    instance id: 1, server id: 10, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3f456dc8, 0x0xb3fd724f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3f456dc8, type: DTA, bufnum: 1
    ser: 513, seq: 823, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdbf70, from qref: 0x0xc13fdde60, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3f456e20, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fde070, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fde070, ser: 513, seq: 1321, err
    or: 0
    opp qref: 0x0xc13fdb940, process: 0x0xc0e2c2c00, bufs: {0x(nil),
    0x0xb3fd424f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fde180, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fde0b8, remote queue addr: 0x
    0xc13fe0950
    instance id: 1, server id: 9, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fd424f8, 0x0xb3f854960}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fd424f8, type: DTA, bufnum: 1
    ser: 513, seq: 1315, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdb940, from qref: 0x0xc13fde070, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fd42550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fde490, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fde490, ser: 513, seq: 1002, err
    or: 0
    opp qref: 0x0xc13fdd830, process: 0x0xc172b87f0, bufs: {0x(nil),
    0x0xb3fde24f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fde5a0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fde4d8, remote queue addr: 0x
    0xc13fe0ba8
    instance id: 1, server id: 8, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fde24f8, 0x0xb3fd224f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fde24f8, type: DTA, bufnum: 1
    ser: 513, seq: 995, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdd830, from qref: 0x0xc13fde490, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fde2550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fde6a0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fde6a0, ser: 513, seq: 1198, err
    or: 0
    opp qref: 0x0xc13fdcbd0, process: 0x0xc0f28a240, bufs: {0x(nil),
    0x0xb3fd024f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fde7b0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fde6e8, remote queue addr: 0x
    0xc13fe0e00
    instance id: 1, server id: 7, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fd024f8, 0x0xb3f059230}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3fd024f8, type: DTA, bufnum: 1
    ser: 513, seq: 1191, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdcbd0, from qref: 0x0xc13fde6a0, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3fd02550, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdeac0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdeac0, ser: 513, seq: 1080, err
    or: 0
    opp qref: 0x0xc13fdcde0, process: 0x0xc102858c0, bufs: {0x(nil),
    0x0xb3f436dc8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdebd0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdeb08, remote queue addr: 0x
    0xc13fe1058
    instance id: 1, server id: 6, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3f436dc8, 0x0xb3fce24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3f436dc8, type: DTA, bufnum: 1
    ser: 513, seq: 1074, flags: STRE, status: FRE, err: 0
    to qref: 0x0xc13fdcde0, from qref: 0x0xc13fdeac0, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3f436e20, remote queue addr:
    0x0xc13fe20e8
    instance id: 1, server id: 65535, flags: ISQC
    SO: 0xc13fdeee0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdeee0, ser: 513, seq: 1418, err
    or: 0
    opp qref: 0x0xc13fde280, process: 0x0xc0c28b668, bufs: {0x(nil),
    0x0xb3f824960}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdeff0, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdef28, remote queue addr: 0x
    0xc13fe12b0
    instance id: 1, server id: 5, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3f824960, 0x0xb3fcc24f8}, sta
    te: 10011
    Message Buffer--kxfpmh: 0x0xb3f824960, type: NUL, bufnum: 1
    ser: 513, seq: 1407, flags: DIAL, status: FRE, err: 0
    to qref: 0x0xc13fdeee0, from qref: 0x0xc13fde280, inc: 0, send
    er:
    Queue Descriptor--kxfpqd: 0x0xb3f8249b8, remote queue addr:
    0x0xc13fe12b0
    instance id: 1, server id: 5, flags: INIT
    SO: 0xc13fdf0f0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
    Queue Reference--kxfpqr: 0x0xc13fdf0f0, ser: 513, seq: 949, erro
    r: 0
    opp qref: 0x0xc13fdc390, process: 0x0xc0d2a3d10, bufs: {0x(nil),
    0x0xb3fc924f8}
    state: 00000, flags: SMEM, nulls 0, hint 0x1
    latch 0x0xc13fdf200, remote descriptor:
    Queue Descriptor--kxfpqd: 0x0xc13fdf138, remote queue addr: 0x
    0xc13fe1508
    instance id: 1, server id: 4, flags: INIT
    recovery info--opr: 0, bufs: {0x0xb3fc924f8, 0x0xb3fca24f8}, sta
    te: 10011
    ---------------------------------------

  • Recovered standby database, still it is looking for gap sequence

    I have lost archive logs in both primary and standby database(deleted due to low space).
    So folloed the below steps.
    1.Identified minimum SCN from standby database.
    2.Took inremental backup from primary database according this SCN(nnnnn)
    3.Transfer this backup file to standby side
    4. Cataloged database backups and recovered the database.
    But medial recovery is searching for missing archived logs. Please advice.

    957905 wrote:
    I have lost archive logs in both primary and standby database(deleted due to low space).
    So folloed the below steps.
    1.Identified minimum SCN from standby database.
    2.Took inremental backup from primary database according this SCN(nnnnn)
    3.Transfer this backup file to standby side
    4. Cataloged database backups and recovered the database.
    But medial recovery is searching for missing archived logs. Please advice.Probably you have not restored new standby controlfile before performing recovery.

  • Recover standby database after primary failed

    Hi,
    I'm having 11g setup with 2 standby databases.  My scenario is i'm doing failover on one standby[new primary] and converting old primary as a standby.  Question is what is the status of another standby? have to create new standby or can recover using flash option?
    regards,
    jp

    '11g' is not a version, it is a marketing label. You need to post your version in the format <x>.<x>.<x>.<x>
    Yes, I know this is asked much.
    Also your question sadly lacks on details, as in this version of Oracle you can cascade standby databases (standby 1 can cascade to standby 2)
    This begs the simple question:
    Did you try?
    If so, what happened?
    If you didn't try, why didn't you try? What can happen?
    Sybrand Bakker
    Senior Oracle DBA

  • Problem in recover physical standby database(Data Guard) by rman

    Hello to all
    I have created a physical standby database ,I want make backup of it by rman and when I lose it's datafile I can restore it ,making backup and restore is fine but in recovery I encounter some problem
    scenarios is follow
    1- In rman I create a backup of standby database by this command:
    backup database plus archivelog delete all input;
    2- I run this comman in rman for recover standby database
    run{
    2> set until scn 1392701;
    3> restore database;
    4> recover database;
    5> }
    (1392701 is extracted from this query "SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH,
    V$DATABASE DB WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE# AND LH.RESETLOGS_TIME =
    DB.RESETLOGS_TIME;" "http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/rman.htm")
    but RMAN result is like this:
    executing command: SET until clause
    Starting restore at 13-DEC-08
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backupset restore
    channel ORA_DISK_1: specifying datafile(s) to restore from
    backup set
    restoring datafile 00001 to /u01/app/oracle/oradata/sari/system01.dbf
    restoring datafile 00002 to /u01/app/oracle/oradata/sari/undotbs01.dbf
    restoring datafile 00003 to /u01/app/oracle/oradata/sari/sysaux01.dbf
    restoring datafile 00004 to /u01/app/oracle/oradata/sari/users01.dbf
    restoring datafile 00005 to /u01/app/oracle/oradata/sari/example01.dbf
    restoring datafile 00006 to /u01/app/oracle/oradata/sari/users02.dbf
    channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0ek24dt4_1_1
    channel ORA_DISK_1: restored backup piece 1
    piece handle=/home/oracle/backup/0ek24dt4_1_1
    tag=TAG20081213T042506
    channel ORA_DISK_1: restore complete, elapsed time: 00:01:07
    Finished restore at 13-DEC-08
    Starting recover at 13-DEC-08
    using channel ORA_DISK_1
    starting media recovery
    archive log thread 1 sequence 116 is already on disk as file /u01/app/oracle/oradata/archive/1_116_666786084.arc
    archive log thread 1 sequence 117 is already on disk as file /u01/app/oracle/oradata/archive/1_117_666786084.arc
    archive log filename=/u01/app/oracle/oradata/archive/1_116_666786084.arc thread=1 sequence=116
    archive log filename=/u01/app/oracle/oradata/archive/1_117_666786084.arc thread=1 sequence=117
    unable to find archive log
    archive log thread=1 sequence=118
    RMAN-03002: failure of recover command at 12/13/2008 05:14:13
    RMAN-06054: media recovery requesting unknown log: thread 1
    seq 118 lowscn 1392700
    3- then I decline 1392701 to 1392700 and i run this command
    run{
    2> set until scn 1392700;
    3> restore database ;
    4> recover database;
    5> }
    executing command: SET until clause
    Starting restore at 13-DEC-08
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backupset restore
    channel ORA_DISK_1: specifying datafile(s) to restore from
    backup set
    restoring datafile 00001 to /u01/app/oracle/oradata/sari/system01.dbf
    restoring datafile 00002 to /u01/app/oracle/oradata/sari/undotbs01.dbf
    restoring datafile 00003 to /u01/app/oracle/oradata/sari/sysaux01.dbf
    restoring datafile 00004 to /u01/app/oracle/oradata/sari/users01.dbf
    restoring datafile 00005 to /u01/app/oracle/oradata/sari/example01.dbf
    restoring datafile 00006 to /u01/app/oracle/oradata/sari/users02.dbf
    channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0ek24dt4_1_1
    channel ORA_DISK_1: restored backup piece 1
    piece handle=/home/oracle/backup/0ek24dt4_1_1 tag=TAG20081213T042506
    channel ORA_DISK_1: restore complete, elapsed time: 00:01:08
    Finished restore at 13-DEC-08
    Starting recover at 13-DEC-08
    using channel ORA_DISK_1
    starting media recovery
    archive log thread 1 sequence 116 is already on disk as
    file /u01/app/oracle/oradata/archive/1_116_666786084.arc
    archive log thread 1 sequence 117 is already on disk as
    file /u01/app/oracle/oradata/archive/1_117_666786084.arc
    archive log filename=/u01/app/oracle/oradata/archive/1_116_666786084.arc thread=1
    sequence=116archive log
    filename=/u01/app/oracle/oradata/archive/1_117_666786084.arc
    thread=1 sequence=117Oracle Error:
    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/sari/system01.dbf'
    media recovery complete, elapsed time: 00:00:10
    Finished recover at 13-DEC-08
    4- if I run
    run{
    restore database;
    recover database;
    I will recieve that error of step 2 (RMAN-06054: media recovery requesting unknown log: thread 1
    seq 118 lowscn 1392700)
    5- if I just restore the database and I don't perform recovery by rman and I restart redo apply all thing seem fine
    but in opening database I'll recieve ORA-01152: file 1 was not restored from a sufficiently old backup
    ORA-01110: data file 1: '/u01/app/oracle/oradata/sari/system01.dbf' error)
    do you know what is problem
    thanks
    Edited by: ARKH on Dec 12, 2008 11:06 PM

    hi
    I myself have found the solution , when I recover the standby database
    it do recovery but at the end of recovery it raise the error(RMAN-06054: media recovery requesting unknown log: thread 1
    seq 118 lowscn 1392700) but if I begain redo apply before open the database
    and I wait till all redo apply process start and communication between the
    standby database and the primary database start, then I can
    open the standby database and no error will raise
    but if befor restarting redo apply I open the database I'll recieve the
    ORA-01152: file 1 was not restored from a sufficiently old backup
    ORA-01110: data file 1: '/u01/app/oracle/oradata/sari/system01.dbf' error
    thanks

  • ERROR in creating a Physical Standby Database

    Hello all,
    I am using a Windows Vista O/S and Oracle 10g Enterprise Edition. Both my primary and standby are on the same host. Created standby instance using oradim.
    I have followed instruction in the documentation and created a manual standby database.
    primary database is 'orcl'
    standby database is 'stby'
    My primary archives is not being copied to the the stby location as confirmed by an error shown:
    SQL> select dest_name, status from v$archive_dest_status
    DEST_NAME
    STATUS
    LOG_ARCHIVE_DEST_1
    VALID
    LOG_ARCHIVE_DEST_2
    ERROR
    Also my standby does not open in read only mode, error:
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
    ERROR at line 1:
    ORA-01153: an incompatible media recovery is active
    SQL> ALTER DATABASE open read only;
    ALTER DATABASE open read only
    ERROR at line 1:
    ORA-01154: database busy. Open, close, mount, and dismount not allowed now
    I have copied both my prim and stby init.ora here for your reference
    PRIMARY INIT
    ============================================
    orcl.__db_cache_size=394264576
    orcl.__java_pool_size=20971520
    orcl.__large_pool_size=4194304
    orcl.__shared_pool_size=184549376
    orcl.__streams_pool_size=0
    *.audit_file_dest='E:\oracle\product\10.2.0\admin\orcl\adump'
    *.background_dump_dest='E:\oracle\product\10.2.0\admin\orcl\bdump'
    *.compatible='10.2.0.3.0'
    *.control_files='E:\oracle\product\10.2.0\oradata\orcl\control01.ctl'
    *.core_dump_dest='E:\oracle\product\10.2.0\admin\orcl\cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_name='orcl'
    *.db_unique_name=orcl
    *.db_recovery_file_dest_size=2147483648
    *.db_recovery_file_dest='E:\oracle\product\10.2.0\flash_recovery_area'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
    *.job_queue_processes=10
    *.nls_language='ENGLISH'
    *.nls_territory='UNITED KINGDOM'
    *.open_cursors=300
    *.pga_aggregate_target=203423744
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=611319808
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='E:\oracle\product\10.2.0\admin\orcl\udump'
    *.standby_file_management=AUTO
    *.log_archive_dest_1='location=E:\oracle\product\10.2.0\flash_recovery_area\orcl\archivelog valid_for=(all_logfiles,primary_role) db_unique_name=orcl'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_2='SERVICE=stby LGWR ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=stby'
    *.log_archive_dest_state_2='ENABLE'
    *.log_archive_config='DG_CONFIG=(orcl,stby)'
    *.db_file_name_convert='orcl','stby'
    *.fal_client='orcl'
    *.fal_server='stby'
    *.db_file_name_convert='E:\oracle\product\10.2.0\oradata\stby', 'E:\oracle\product\10.2.0\oradata\orcl'
    *.log_file_name_convert='E:\oracle\product\10.2.0\oradata\stby', 'E:\oracle\product\10.2.0\oradata\orcl'
    *.standby_file_management=AUTO
    ======================================
    STANDBY INIT.ora
    stby.__db_cache_size=423624704
    stby.__java_pool_size=4194304
    tby.__large_pool_size=4194304
    stby.__large_pool_size=4194304
    stby.__shared_pool_size=171966464
    stby.__streams_pool_size=0
    *.audit_file_dest='E:\oracle\product\10.2.0\admin\stby\adump'
    *.background_dump_dest='E:\oracle\product\10.2.0\admin\stby\bdump'
    *.compatible='10.2.0.3.0'
    *.control_files='E:\oracle\product\10.2.0\oradata\stby\CONTROL_SB01.CTL'
    *.core_dump_dest='E:\oracle\product\10.2.0\admin\stby\cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_file_name_convert='orcl','stby'
    *.db_name='orcl'
    *.db_recovery_file_dest_size=2147483648
    *.db_recovery_file_dest='E:\oracle\product\10.2.0\flash_recovery_area\STBY'
    *.db_unique_name='stby'
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
    *.fal_client='stby'
    *.fal_server='orcl'
    *.job_queue_processes=10
    *.log_archive_config='DG_CONFIG=(orcl,stby)'
    *.log_archive_dest_1='location=E:\oracle\product\10.2.0\flash_recovery_area\stby valid_for=(all_logfiles,primary_role) db_unique_name=stby'
    *.log_archive_dest_2='SERVICE=stby LGWR ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=orcl'
    *.log_archive_dest_state_1='ENABLE'
    *.log_archive_dest_state_2='ENABLE'
    *.log_file_name_convert='E:\oracle\product\10.2.0\oradata\orcl','E:\oracle\product\10.2.0\oradata\stby'
    *.nls_language='ENGLISH'
    *.nls_territory='UNITED KINGDOM'
    *.open_cursors=300
    *.pga_aggregate_target=203423744
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=611319808
    *.standby_archive_dest='USE_DB_RECOVERY_FILE_DEST'
    *.standby_file_management='AUTO'
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='E:\oracle\product\10.2.0\admin\stby\udump'
    =================================================
    Any help would be much appreciated. Apologies for my ignorance!
    Thanks!
    null
    null

    OK that solves part of the problem.
    Now this is very strange error I am getting. The path it looks to recover from archive is not right, it should point as per my actual archive log dest. See below.
    Standby:
    =================
    SQL> alter database open;
    alter database open
    ERROR at line 1:
    ORA-16004: backup database requires recovery
    ORA-01152: file 1 was not restored from a sufficiently old backup
    ORA-01110: data file 1: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\SYSTEM01.DBF'
    SQL> recover standby database until cancel;
    ORA-00279: change 619067 generated at 06/22/2008 13:20:14 needed for thread 1
    ORA-00289: suggestion :
    E:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00006_0658028298.001
    ORA-00280: change 619067 for thread 1 is in sequence #6
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    ORA-00308: cannot open archived log
    'E:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00006_0658028298.001'
    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-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: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\SYSTEM01.DBF'
    ==================================================
    Why is not pointing to the destination below, where the above archives reside??
    =====================================
    SQL> archive log list
    Database log mode Archive Mode
    Automatic archival Enabled
    Archive destination E:\oracle\product\10.2.0\flash_recovery_area\stby
    Oldest online log sequence 12
    Next log sequence to archive 0
    Current log sequence 14
    =================

  • Error while trying to setup a standby database.

    While tring to setup a standby database (with version 8.1.7.0.0) i am running the command:
    recover managed standby database timeout 20;
    Here is the errors i'm getting:
    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: '/data/syndicate/standby/system/dup75_system01.dbf'
    ORA-16016: archived log for thread 1 sequence# 6518 unavailable
    Although it says that file 1 was not restored from sufficiently old backup I've copied all the datafiles from the primary database at once - using a script.
    The archived log sequence it asks for is non-existant - the last one i have is # 6517.
    Thank you guys in advance for any ideas.
    Greg

    I am having the same problem as you are when I am applying the current logs after successfully mounting standby database as seen below:
    SVRMGR> alter database mount standby database;
    Statement processed.
    SVRMGR> recover standby database ;
    ORA-00279: change 2939586 generated at 07/28/2002 01:09:33 needed for thread 5718
    ORA-00289: suggestion : C:\ORACLE\ORADATA\STANDBY\ARCHIVE\STANDBYT571S00362.ARC
    ORA-00280: change 2939586 for thread 5718 is in sequence #362
    Specify log: {=suggested | filename | AUTO | CANCEL}
    CANCEL
    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: 'C:\ORACLE\ORADATA\STANDBY\SYSTEM01.DBF'
    SVRMGR>
    Just before copying the datafiles from the primary database I did the following:
    Connected to the primary database:
    1. alter database create standby controlfile as .....
    2. alter system switch logfile
    3. shutdown normal
    4. took a cold backup (including archived redo logs)
    Copied the data files, redolog files, archived redo logs and standby controlfile to standby database:
    1. made copies of standby controlfile over current standby ones.
    2. startup nomount (the standby database)
    3. alter database mount standby database;
    4. recover standby database;
    That's when it asks for an archived redo log that does'nt exist and when I enter cancel, that's when I get the above error?
    Am I not applying the latest redo logs to the latest cold backup of the primary database?
    Your help would be much appreciated!

  • How to find the timestamp and SCN in the standby database?

    Hai,
    I have Oracle 9.2.0.4 RAC with 2 nodes in the production. The logs generated at these servers will be manully moved to my standby database and will be applied. To know what isthe maximum log files applied in the standby database, i am using the below mentioned query in the standby database,
    Select thread#,max(sequence#) from v$log_history group by thread#
    In general i am using "recover standby database until cancel" command and then checking the database with the above mentioned query whether all the logs are applied or not.
    If i use time based or scn based recovery in standby database i.e., "recover standby database until time <time>" or "recover standby database until change <scn number>" , after completion of the recovery, apart from the message "Media recovery complete" or by seeing the alert log, is there any way to query the standby database, so that i can identify the time or scn upto which the archived redo log files got applied.

    Hi Sridhar,
    There should be some view which will have applied_scn information. There is one more option i can suggest, you can create a heart beat table in production with 2 column like scn and timestamp. Update this table every minute. From standby db you can query this table and get fair idea on applied_scn and timestamp.
    While exporting you can export using flashback_scn by taking the value from heartbeat table of standby.
    This heartbeat table is used very common in streams environment. Just see if this helps you.
    hth,
    http://borndba.com

  • Issue on physical standby database

    Hi
    I've a problem on standby database.
    I recently added a datafile on primary database, then I scp'ed the data file to physical standby database.On physical standby database I tried performing recovery.
    I get following message in my alert log
    WARNING! Recovering data file 88 from a fuzzy file. If not the current file
    it might be an online backup taken without entering the begin backup command.
    ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
    how can I fix this now.
    We keep physical standby database 2 day behind, and apply logs manually.
    Physical standby database is maintained manually.
    Could someone help me in getting out of this problem.
    Oracle 9.2.0.7
    solaris

    Versus keeping it in manual mode, you can specify a time "delay" for the application of the logs:
    From http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_apply.htm#i1022811
    6.2.2 Specifying a Time Delay for the Application of Archived Redo Log Files
    In some cases, you may want to create a time lag between the time when redo data is received from the primary site and when it is applied to the standby database. You can specify a time interval (in minutes) to protect against the application of corrupted or erroneous data to the standby database. When you set a DELAY interval, it does not delay the transport of the redo data to the standby database. Instead, the time lag you specify begins when the redo data is completely archived at the standby destination.
    Note:
    If you define a delay for a destination that has real-time apply enabled, the delay is ignored.
    Specifying a Time Delay
    You can set a time delay on primary and standby databases using the DELAY=minutes attribute of the LOG_ARCHIVE_DEST_n initialization parameter to delay applying archived redo log files to the standby database. By default, there is no time delay. If you specify the DELAY attribute without specifying a value, then the default delay interval is 30 minutes.
    Canceling a Time Delay
    You can cancel a specified delay interval as follows:
    For physical standby databases, use the NODELAY keyword of the RECOVER MANAGED STANDBY DATABASE clause:
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
    For logical standby databases, specify the following SQL statement:
    SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
    These commands result in log apply services immediately beginning to apply archived redo log files to the standby database, before the time interval expires. Also, see:
    Section 12.8, "Using a Physical Standby Database with a Time Lag"
    Oracle Database SQL Reference for the DELAY attribute of the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement

  • ORA-279 signalled during recovery of standby database

    Hi All,
    I am preparing standby database after taking hot backup and copying those datafiles to standby,
    taken controlfile standby controlfile backup from primary
    mounted the standby database using standby controlfile using
    startup nomount pfile='/u01/stand.ora'
    alter database mount standby database;
    Now I have started applying archives on standby database after copying all archives from primary to standby box the archives generated during backup using..
    recover standby database;
    But I am getting the below warning on the recovery screen...
    ORA-00279: change 51667629050 generated at 07/02/2009 00:59:43 needed for
    thread 1
    ORA-00289: suggestion : /nodal-archive/archive/1_55118_652209172.arc
    ORA-00280: change 51667629050 for thread 1 is in sequence #55118
    ORA-00278: log file '/nodal-archive/archive/1_55117_652209172.arc' no longer
    needed for this recovery
    ORA-00279: change 51667703096 generated at 07/02/2009 01:06:04 needed for
    thread 1
    ORA-00289: suggestion : /nodal-archive/archive/1_55119_652209172.arc
    ORA-00280: change 51667703096 for thread 1 is in sequence #55119
    ORA-00278: log file '/nodal-archive/archive/1_55118_652209172.arc' no longer
    needed for this recovery
    ORA-00279: change 51667767649 generated at 07/02/2009 01:12:28 needed for
    thread 1
    ORA-00289: suggestion : /nodal-archive/archive/1_55120_652209172.arc
    ORA-00280: change 51667767649 for thread 1 is in sequence #55120
    ORA-00278: log file '/nodal-archive/archive/1_55119_652209172.arc' no longer
    needed for this recovery
    ORA-00279: change 51667831821 generated at 07/02/2009 01:19:40 needed for
    thread 1
    ORA-00289: suggestion : /nodal-archive/archive/1_55121_652209172.arc
    ORA-00280: change 51667831821 for thread 1 is in sequence #55121
    ORA-00278: log file '/nodal-archive/archive/1_55120_652209172.arc' no longer
    needed for this recovery
    and I am getting the below warning on the alert log..........
    Sun Jul 5 18:37:36 2009
    ALTER DATABASE RECOVER CONTINUE DEFAULT
    Sun Jul 5 18:37:36 2009
    Media Recovery Log /nodal-archive/archive/1_55256_652209172.arc
    Sun Jul 5 18:40:31 2009
    ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
    Sun Jul 5 18:40:31 2009
    ALTER DATABASE RECOVER CONTINUE DEFAULT
    Sun Jul 5 18:40:31 2009
    Media Recovery Log /nodal-archive/archive/1_55257_652209172.arc
    Please suggest what to do now.............
    Thanks in Advance,
    Sukanta Paul.

    Hi Sukanta,
    I didn't really understand what the problem is...
    Let me explain, hope it will be clear.
    You created a standby control file, and backed up the database (it doesn't matter in which order). Now, you have a standby database that is ready to apply logs. It will be able to apply log forever, until we will stop it.
    The messages you see say the following:
    ORA-00279: change 51667831821 generated at 07/02/2009 01:19:40 needed for thread 1 {color:blue} - this says that the recovery process is now at scn 51667831821 {color}
    ORA-00289: suggestion : /nodal-archive/archive/1_55121_652209172.arc {color:blue} - the information needed for the recover is in this file (this is only the default name, you can choose other name if the file is called differently) {color}
    ORA-00280: change 51667831821 for thread 1 is in sequence #55121 {color:blue} - same here, the needed archive is sequence 55121 {color}
    ORA-00278: log file '/nodal-archive/archive/1_55120_652209172.arc' no longer needed for this recovery {color:blue} - this message is after Oracle has applied the log, and it means that this log is no longer needed {color}
    Now it will wait for the next log. Again, this process is endless, this is how it is made to allow the standby database to be always synched with the primary.
    Liron Amitzi
    Senior DBA consultant
    [www.dbsnaps.com]
    [www.orbiumsoftware.com]

  • ORA-10458: standby database requires recovery

    hi
    kindly help me... i got error when standby open in read only mode
    SQL*Plus: Release 11.2.0.3.0 Production on Sat Jan 19 14:37:46 2013
    Copyright (c) 1982, 2011, Oracle. All rights reserved.
    Connected to an idle instance.
    SQL> startup mount
    ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
    ORACLE instance started.
    Total System Global Area 5344731136 bytes
    Fixed Size 2237776 bytes
    Variable Size 1275071152 bytes
    Database Buffers 4060086272 bytes
    Redo Buffers 7335936 bytes
    Database mounted.
    SQL> Alter Database Recover Managed Standby Database Disconnect;
    Database altered.
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    Database altered.
    SQL> ALTER DATABASE OPEN READ ONLY;
    ALTER DATABASE OPEN READ ONLY
    ERROR at line 1:
    ORA-10458: standby database requires recovery
    ORA-01152: file 22 was not restored from a sufficiently old backup
    ORA-01110: data file 22: '/archive/data/undo01.dbf'

    hi CKPT
    I executed the action plan as you recommend and got below information;
    SQL> recover standby database;
    ORA-00279: change 5983485554580 generated at 01/01/2013 19:27:17 needed for
    thread 1
    ORA-00289: suggestion : /archive/PROD_1_750568044_45027.ARC
    ORA-00280: change 5983485554580 for thread 1 is in sequence #45027
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    '/archive/PROD_1_750568044_45400.ARC'
    ORA-00310: archived log contains sequence 45400; sequence 45027 required
    ORA-00334: archived log: '/archive/PROD_1_750568044_45400.ARC'
    ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
    ORA-01152: file 22 was not restored from a sufficiently old backup
    ORA-01110: data file 22: '/archive/data/undo01.dbf'
    SQL> alter database open resetlogs;
    alter database open resetlogs
    ERROR at line 1:
    ORA-01666: control file is for a standby database
    SQL> alter system switch logfile;
    alter system switch logfile
    ERROR at line 1:
    ORA-01109: database not open
    ---------------------------------- and some other activity but still not found any solution-------------
    RMAN> recover database until sequence
    2> 45026;
    Starting recover at 23-JAN-13
    using channel ORA_DISK_1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 01/23/2013 16:42:47
    RMAN-06556: datafile 1 must be restored from backup older than SCN 5983484595990
    RMAN> recover database until sequence 45027;
    Starting recover at 23-JAN-13
    using channel ORA_DISK_1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 01/23/2013 16:42:59
    RMAN-06556: datafile 22 must be restored from backup older than SCN 5983485554580
    RMAN> recover database until sequence 45025;
    Starting recover at 23-JAN-13
    using channel ORA_DISK_1
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of recover command at 01/23/2013 16:43:09
    RMAN-06556: datafile 1 must be restored from backup older than SCN 5983484160276
    RMAN> alter database open resetlogs;
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of alter db command at 01/23/2013 16:43:25
    ORA-01666: control file is for a standby database

  • Standby database config

    Hi everybody
    when i m configuring standby server
    using these command
    export ORACLE_SID=kk
    sqlplus /nolog
    conn / as sysdba
    create spfile from pfile='/u03/oracle/admin//initkk.ora' /*standby spfile*/
    startup nomount force
    alter database mount standby database ;
    alter database recover managed standby database disconnect from session;
    AND Next
    when i am using the command RECOVER STANDBY DATABASE ;
    Then the error will be occur
    ora 00283 recovery session cancelled due to errors
    ora 01110 '/u01/oracle/k/system .dbf'
    ora 01157 cannot identify/lock data file 1 - see DBWR trace file
    ora 01110 data file 'u01/oracle/k/system .dbf'
    but /u01/oracle/k/system.dbf path of the prod server and standby server path is /u03/oracle/oradata/kk/system.dbf'
    so pls help me

    hi aman
    another error will be occur at the time of reocvery of standby database ,
    when i fired the statement
    recover standby database ;
    then he want latest archive for recover ,then i make the latest archive destination
    but the last of the datafile will not be recover
    the error is
    ora 01547 waring recover succeded but OPEN RESETLOGSwould get error below
    ora 01152 file 12 is not restore from the sufficiently old backup
    ora 01110 data file /u03/abd.dbf'
    so what should i do for this
    thanks

Maybe you are looking for