Physica standby recovery problem

Hi,
I am trying to recover physical standby database manually
I am getting below error:
alter database recover standby database parallel (degree 32);
alter database recover standby database parallel (degree 32)
ERROR at line 1:
ORA-01153: an incompatible media recovery is active
I have tried to cancel managed recovery, but no managed recovery is active.
alter database recover managed standby database cancel;
alter database recover managed standby database cancel
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
select distinct recovery_mode from v$archive_dest_status;
RECOVER
IDLE
Please help me to resolve this. Thanks in advance.
regards,
Narendra

Apparently this is bug 5084496, related to parallel recovery on 10.1 and below (ML note 361883.1). You may avoid this bug if you don't use parallel recovery. It looks like there are no one-off patches available, so you are stuck with either serial recovery or upgrade to 10.2 or higher :-(
Regards,
Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net

Similar Messages

  • Standby recovery problem

    i have a production and standby db
    9i release 2 on oralinux
    on my production database
    select name from v$datafile;
    NAME
    /oracle/oradata/eims/system01.dbf
    /oracle/oradata/eims/undotbs01.dbf
    /oracle/oradata/eims/cwmlite01.dbf
    /oracle/oradata/eims/drsys01.dbf
    /oracle/oradata/eims/example01.dbf
    /oracle/oradata/eims/indx01.dbf
    /oracle/oradata/eims/odm01.dbf
    /oracle/oradata/eims/tools01.dbf
    /oracle/oradata/eims/users01.dbf
    /oracle/oradata/eims/xdb01.dbf
    /oracle/oradata/eims/INVENTORY01.dbf
    NAME
    /oracle/oradata/eims/APR_DATA11.dbf
    /oracle/oradata/eims/APR_DATA21.dbf
    /oracle/oradata/eims/APR_MMS1.dbf
    /oracle/oradata/eims/APR_MVIEWS1.dbf
    /oracle/oradata/eims/HR_DATA21.dbf
    /oracle/oradata/eims/DTS_DATA11.dbf
    /oracle/oradata/eims/dts_data12.dbf
    /oracle/oradata/eims/undotbs0.dbf2.dbf
    /oracle/oradata/eims/APR_DATA22.dbf
    /oracle/oradata/eims/INVENTORY11.dbf ( this file not present on standby db)
    21 rows selected.
    on my standby db:
    select name from v$datafile;
    NAME
    /oracle/oradata/eims/system01.dbf
    /oracle/oradata/eims/undotbs01.dbf
    /oracle/oradata/eims/cwmlite01.dbf
    /oracle/oradata/eims/drsys01.dbf
    /oracle/oradata/eims/example01.dbf
    /oracle/oradata/eims/indx01.dbf
    /oracle/oradata/eims/odm01.dbf
    /oracle/oradata/eims/tools01.dbf
    /oracle/oradata/eims/users01.dbf
    /oracle/oradata/eims/xdb01.dbf
    /oracle/oradata/eims/INVENTORY01.dbf
    NAME
    /oracle/oradata/eims/APR_DATA11.dbf
    /oracle/oradata/eims/APR_DATA21.dbf
    /oracle/oradata/eims/APR_MMS1.dbf
    /oracle/oradata/eims/APR_MVIEWS1.dbf
    /oracle/oradata/eims/HR_DATA21.dbf
    /oracle/oradata/eims/DTS_DATA11.dbf
    /oracle/oradata/eims/dts_data12.dbf
    /oracle/oradata/eims/undotbs0.dbf2.dbf
    /oracle/oradata/eims/APR_DATA22.dbf ( the recovery error come with this datafile)
    20 rows selected.
    but when I
    SQL> recover standby database;
    ORA-00283: recovery session canceled due to errors
    ORA-01110: data file 20: '/oracle/oradata/eims/APR_DATA22.dbf'
    ORA-01157: cannot identify/lock data file 20 - see DBWR trace file
    ORA-01110: data file 20: '/oracle/oradata/eims/APR_DATA22.dbf'
    the diffrence in both primary and standby db is
    /oracle/oradata/eims/INVENTORY11.dbf (present on primary) but not on standby db. the error message when i recover standby database should with this datafile
    however in recovery the error message is (data file 20: '/oracle/oradata/eims/APR_DATA22.dbf') not with
    (/oracle/oradata/eims/INVENTORY11.dbf)
    how i can over come with this
    regards
    rehan
    Edited by: user10204771 on Feb 6, 2009 12:18 AM

    /oracle/oradata/eims/APR_DATA22.dbf this also created in standby and production db at 15-jan-09.
    /oracle/oradata/eims/INVENTORY11.dbf this file is created on primary db on 15-jan-09 but not on standby.
         /oracle/oradata/eims/system01.dbf system
    /oracle/oradata/eims/undotbs01.dbf RECOVER
         /oracle/oradata/eims/cwmlite01.dbf
         /oracle/oradata/eims/drsys01.dbf
         /oracle/oradata/eims/example01.dbf
         /oracle/oradata/eims/indx01.dbf
         /oracle/oradata/eims/odm01.dbf
         /oracle/oradata/eims/tools01.dbf
         /oracle/oradata/eims/users01.dbf
         /oracle/oradata/eims/xdb01.dbf
         /oracle/oradata/eims/INVENTORY01.dbf
         /oracle/oradata/eims/APR_DATA11.dbf      /oracle/oradata/eims/APR_DATA21.dbf
         /oracle/oradata/eims/APR_MMS1.dbf
         /oracle/oradata/eims/APR_MVIEWS1.dbf
         /oracle/oradata/eims/HR_DATA21.dbf
         /oracle/oradata/eims/DTS_DATA11.dbf
         /oracle/oradata/eims/dts_data12.dbf
         /oracle/oradata/eims/undotbs0.dbf2.dbf
    /oracle/oradata/eims/APR_DATA22.dbf RECOVER
    the staus of these two files is recover , all other datafile status is onlline.
    regards rehan

  • Physical Standby - Recovery error

    Hi,
    Windows XP, 10.2.0.1.0
    I m getting the error like
    SQL> alter database mount standby database;
    alter database mount standby database
    ERROR at line 1:
    ORA-01103: database name 'PRIM' in control file is not 'STBY'
    Please suggest me
    Thanks
    KSG
    Edited by: KSG on Jun 15, 2010 1:15 PM

    Hi,
    Hope I have some issue with the parameter file. Please find my parameter files
    initPRIM.ora
    PRIM.__db_cache_size=411041792
    PRIM.__java_pool_size=4194304
    PRIM.__large_pool_size=4194304
    PRIM.__shared_pool_size=163577856
    PRIM.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0/admin/PRIM/adump'
    *.background_dump_dest='C:\oracle\product\10.2.0/admin/PRIM/bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\product\10.2.0\oradata\PRIM\control01.ctl','C:\oracle\product\10.2.0\oradata\PRIM\control02.ctl','C:\oracle\product\10.2.0\oradata\PRIM\control03.ctl'
    *.core_dump_dest='C:\oracle\product\10.2.0/admin/PRIM/cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_name='PRIM'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0/flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=PRIMXDB)'
    *.job_queue_processes=10
    *.open_cursors=300
    *.pga_aggregate_target=197132288
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=591396864
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0/admin/PRIM/udump'
    *.log_archive_dest_1='location=C:\oracle\archiveprim'
    *.log_archive_format='ARCH_%r_%t_%s.ARC'
    initstby.ora
    stby.__db_cache_size=411041792
    stby.__java_pool_size=4194304
    stby.__large_pool_size=4194304
    stby.__shared_pool_size=163577856
    stby.__streams_pool_size=0
    *.audit_file_dest='C:\oracle\product\10.2.0/admin/stby/adump'
    *.background_dump_dest='C:\oracle\product\10.2.0/admin/stby/bdump'
    *.compatible='10.2.0.1.0'
    *.control_files='C:\oracle\CONTROL_SB01.CTL'
    *.core_dump_dest='C:\oracle\product\10.2.0/admin/stby/cdump'
    *.db_block_size=8192
    *.db_domain=''
    *.db_file_multiblock_read_count=16
    *.db_name='stby'
    *.db_recovery_file_dest='C:\oracle\product\10.2.0/flash_recovery_area'
    *.db_recovery_file_dest_size=2147483648
    *.dispatchers='(PROTOCOL=TCP) (SERVICE=stbyXDB)'
    *.job_queue_processes=10
    *.open_cursors=300
    *.pga_aggregate_target=197132288
    *.processes=150
    *.remote_login_passwordfile='EXCLUSIVE'
    *.sga_target=591396864
    *.undo_management='AUTO'
    *.undo_tablespace='UNDOTBS1'
    *.user_dump_dest='C:\oracle\product\10.2.0/admin/stby/udump'
    *.log_archive_dest_1='location=C:\oracle\archivestby'
    *.log_archive_format='ARCH_%r_%t_%s.ARC'
    *.standby_archive_dest='C:\oracle\archiveprim'
    *.db_file_name_convert='C:\oracle\product\10.2.0\oradata\PRIM','C:\oracle\product\10.2.0\oradata\stby'
    *.log_file_name_convert='C:\oracle\product\10.2.0\oradata\PRIM','C:\oracle\product\10.2.0\oradata\stby'
    *.standby_file_management=AUTO
    *.remote_archive_enable=TRUE

  • Problems while creating a physical Standby

    Hi,
    I am trying to setup a physical standby database with oracle 10g.
    I configured a specific log archive destination:
    LOG_ARCHIVE_DEST_3 = 'SERVICE=ORAMPSEC REOPEN=60 MAX_FAILURE=3 LGWR SYNC
    VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORAMPSEC'
    The service is reachable via network.
    To establish the standby database I copied all datafiles from the primary database using scp. I also created a standby controlfile and a modified pfile. In addition I added a standby redo logfile which has the same size as the online redo log files on the primary database.
    After starting the standby database in open read only mode I receive the following error message:
    Database mounted.
    ORA-16004: backup database requires recovery
    ORA-01194: file 1 needs more recovery to be consistent
    ORA-01110: data file 1: '/oradata/ORAMPPRD/data/system01.dbf'
    I tried to recover using "recover standby database" I receive the following message:
    ORA-00279: change 884348 generated at 07/18/2006 17:08:07 needed for thread 1
    ORA-00289: suggestion : /oradata/ORAMPPRD/archive/1_30_595767954.dbf
    ORA-00280: change 884348 for thread 1 is in sequence #30
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    Although I transmitted all archived log files from the primary database the archived log file mentioned above is not available. After hitting RETURN I get this message:
    ORA-00308: cannot open archived log
    '/oradata/ORAMPPRD/archive/1_30_595767954.dbf'
    ORA-27037: unable to obtain file status
    SVR4 Error: 2: No such file or directory Additional information: 3
    ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
    ORA-01194: file 1 needs more recovery to be consistent
    ORA-01110: data file 1: '/oradata/ORAMPPRD/data/system01.dbf'
    Here is a listing of all archived logfiles from the primary database:
    bash-3.00$ ls -latr
    total 494144
    drwxr-xr-x 6 oracle oinstall 512 Jul 14 11:03 ..
    -rw-r----- 1 oracle oinstall 20732928 Jul 17 11:47 1_6_595767954.dbf
    -rw-r----- 1 oracle oinstall 86013440 Jul 17 13:56 1_7_595767954.dbf
    -rw-r----- 1 oracle oinstall 214016 Jul 17 13:57 1_8_595767954.dbf
    -rw-r----- 1 oracle oinstall 1986560 Jul 17 14:10 1_9_595767954.dbf
    -rw-r----- 1 oracle oinstall 150016 Jul 17 14:10 1_10_595767954.dbf
    -rw-r----- 1 oracle oinstall 504320 Jul 17 14:17 1_11_595767954.dbf
    -rw-r----- 1 oracle oinstall 1807872 Jul 17 14:22 1_12_595767954.dbf
    -rw-r----- 1 oracle oinstall 589824 Jul 17 14:25 1_13_595767954.dbf
    -rw-r----- 1 oracle oinstall 1190912 Jul 17 14:37 1_14_595767954.dbf
    -rw-r----- 1 oracle oinstall 584704 Jul 17 14:42 1_15_595767954.dbf
    -rw-r----- 1 oracle oinstall 80896 Jul 17 14:45 1_16_595767954.dbf
    -rw-r----- 1 oracle oinstall 6050816 Jul 17 15:08 1_17_595767954.dbf
    -rw-r----- 1 oracle oinstall 4238848 Jul 17 16:04 1_18_595767954.dbf
    -rw-r----- 1 oracle oinstall 4920832 Jul 17 17:21 1_19_595767954.dbf
    -rw-r----- 1 oracle oinstall 1520128 Jul 17 17:30 1_20_595767954.dbf
    -rw-r----- 1 oracle oinstall 360960 Jul 17 17:35 1_21_595767954.dbf
    -rw-r----- 1 oracle oinstall 89186304 Jul 18 10:52
    1_22_595767954.dbf
    -rw-r----- 1 oracle oinstall 16216576 Jul 18 14:18
    1_23_595767954.dbf
    -rw-r----- 1 oracle oinstall 12288 Jul 18 14:18 1_24_595767954.dbf
    -rw-r--r-- 1 oracle oinstall 2073 Jul 18 14:26 sqlnet.log
    -rw-r----- 1 oracle oinstall 14387200 Jul 18 16:56
    1_25_595767954.dbf
    -rw-r----- 1 oracle oinstall 116736 Jul 18 16:58 1_26_595767954.dbf
    -rw-r----- 1 oracle oinstall 1536000 Jul 18 17:04 1_27_595767954.dbf
    -rw-r----- 1 oracle oinstall 156672 Jul 18 17:05 1_28_595767954.dbf
    drwxr-xr-x 2 oracle oinstall 1024 Jul 18 17:08 .
    -rw-r----- 1 oracle oinstall 65536 Jul 18 17:08 1_29_595767954.dbf
    Nothing known about the *30*dbf file.
    Although there still seems to be something wrong, the archived log file transmission seems to work since there is no error reported on the log archive destination:
    SQL> select status, error from v$archive_dest where dest_id = 3;
    STATUS ERROR
    VALID
    And after I manually force a log switch I see that archived redo logs were applied on the standby database:
    select sequence#, applied from v$archived_log order by sequence#;
    SEQUENCE# APPLIED
    27 YES
    28 NO
    28 YES
    29 NO
    29 YES
    Unfortunately because of the recovering problem I cannot open the database to see if the changes were applied. So my first question is, how can I get the standby database completely recovered ??
    In addition to this I was expecting that the changes to the standby database were made immediately since I choosed LGWR sync but I have to manually force the logfile switch. As I already mentioned a standby redo log file is available as well.
    Thanks for your help,
    Philipp.

    Hi,
    since it does not seem to work with just copying the datafiles I switched to RMAN. I created a full database backup from Enterprise Manager. Similiar to http://dizwell.com/main/content/view/81/122/1/1/ I tried to duplicate the database to the standby instance (running on a different server). But unfortunately I receive error messages that the files, previously created, cannot be found:
    channel d1: starting datafile backupset restore channel d1: specifying datafile(s) to restore from backup set restoring datafile 00001 to /oradata/ORAMPPRD/data/1.dbf restoring datafile 00002 to /oradata/ORAMPPRD/data/2.dbf restoring datafile 00003 to /oradata/ORAMPPRD/data/3.dbf restoring datafile 00004 to /oradata/ORAMPPRD/data/4.dbf channel d1: reading from backup piece /opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1
    ORA-19870: error reading backup
    piece /opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1
    ORA-19505: failed to identify file
    "/opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1"
    ORA-27037: unable to obtain file status
    SVR4 Error: 2: No such file or directory Additional information: 3 failover to previous backup
    But when I crosscheck my backup inside RMAN it clearly shows the backup files:
    RMAN> crosscheck backup;
    backup piece
    handle=/opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1 recid=7
    stamp=596207811
    crosschecked backup piece: found to be 'AVAILABLE'
    I already checked the file permissions, everybody on the system is able to access this file.
    Do you know what is going wrong here ??
    Cheers,
    Philipp.

  • 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

  • Physical standby database standby redo log problem

    Hello
    We have a physical standby database , I've created some standby redo log files but my problem is that they aren't used,
    their status in v$stanby_log view is UNASSIGNED
    and I see this message (ORA-16086: standby database does not contain available standby log files) in primary database alert_log file
    while when I run "alter system switch logfile" in the primary database it transfer redo logs to the physsical standby database
    and archive log file will be created in standby database
    I've even recreated the standby redo log files and I added new ones to them but the problem wasn't solved
    Do you know what is problem ?
    elect group#,THREAD#,BYTES,STATUS from V$STANDBY_LOG;
    group#     THREAD#      BYTES       STATUS
    1                   0                   524288000                   UNASSIGNED                  
    2                   0                   524288000                   UNASSIGNED                  
    3                   0                   524288000                   UNASSIGNED                  
    8                   0                   524288000                   UNASSIGNED                  
    9                   0                   524288000                   UNASSIGNED                  
    10                   0                   524288000                   UNASSIGNED                  
    select group#,THREAD#,BYTES,MEMBERS,STATUS from v$log;
    group#                    THREAD#                    BYTES                    MEMBERS                    STATUS
    4                   1                   524288000                   2                   CLEARING                  
    7                   1                   524288000                   2                   CLEARING_CURRENT                  
    6                   1                   524288000                   2                   CLEARING                  
    5                   1                   524288000                   2                   CLEARING                  
    thanks

    Hello Anurag
    Thank you for your reply
    I have found some issue in the standby database alert_log too , in the standby database alert_log it has been written:
    RFS[782]: Assigned to RFS process 3919
    RFS[782]: Identified database type as 'physical standby'
    Primary database is in MAXIMUM AVAILABILITY mode
    Standby controlfile consistent with primary
    Primary database is in MAXIMUM AVAILABILITY mode
    Standby controlfile consistent with primary
    RFS[782]: No standby redo logfiles selected (reason:6)
    Sun Jan 31 13:59:43 2010
    Errors in file /u01/app/oracle/admin/tehrep/udump/tehrep_rfs_3919.trc:
    ORA-16086: standby database does not contain available standby log files
    Sun Jan 31 13:59:48 2010
    RFS[781]: Archived Log: '/disks/sda/tehrep/archivelogs/1_6516_670414641.dbf'
    Sun Jan 31 13:59:50 2010
    and the context "/u01/app/oracle/admin/tehrep/udump/tehrep_rfs_3919.trc"  is below :
    +/u01/app/oracle/admin/tehrep/udump/tehrep_rfs_3919.trc+
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
    With the Partitioning, OLAP and Data Mining options
    ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
    System name:    Linux
    Node name:      linserver2.com
    Release:        2.6.9-42.ELsmp
    Version:        #1 SMP Wed Jul 12 23:27:17 EDT 2006
    Machine:        i686
    Instance name: tehrep
    Redo thread mounted by this instance: 1
    Oracle process number: 58
    Unix process pid: 3919, image: [email protected]
    *** SERVICE NAME:() 2010-01-31 13:59:43.865
    *** SESSION ID:(109.1225) 2010-01-31 13:59:43.865
    KCRRFLAS
    KCRRSNPS
    No space in recovery area for active standby redo logs
    The primary database is operating in MAXIMUM PROTECTION
    or MAXIMUM AVAILABILITY mode, and the standby database
    does not contain adequate disk space in the recovery area
    to safely archive the contents of the standby redo logfiles.
    ORA-16086: standby database does not contain available standby log files
    when I saw this line "No space in recovery area for active standby redo logs" I thought that STANDBY_ARCHIVE_DEST parameter points where that there is no enough space , but when I consider I found out that points a directory on disk a "sda" that has enough space , I don't know what that means
    by the way, at below I've written a section of the primary database alert_log context and "lgwr" trace file around Sun Jan 31 13:30:34 2010
    alert_log :
    ORA-16086: standby database does not contain available standby log files
    Sun Jan 31 13:30:34 2010
    LGWR: Failed to archive log 7 thread 1 sequence 6512 (16086)
    Thread 1 advanced to log sequence 6512
    Current log# 7 seq# 6512 mem# 0: /disks/sdb/tehrep/redo71.log
    Current log# 7 seq# 6512 mem# 1: /disks/sdd/tehrep/redo72.log
    LNSc started with pid=53, OS id=11451
    Sun Jan 31 13:36:34 2010
    Errors in file /u01/app/oracle/admin/tehrep/bdump/tehrep_lgwr_3692.trc:
    ORA-16086: standby database does not contain available standby log files
    Sun Jan 31 13:36:34 2010
    LGWR: Failed to archive log 5 thread 1 sequence 6513 (16086)
    Thread 1 advanced to log sequence 6513
    Current log# 5 seq# 6513 mem# 0: /disks/sdb/tehrep/redo51.log
    Current log# 5 seq# 6513 mem# 1: /disks/sdd/tehrep/redo52.log
    */u01/app/oracle/admin/tehrep/bdump/tehrep_lgwr_3692.trc file :*
    Error 16086 creating standby archive log file at host '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com
    +)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated)))'+
    *** 2010-01-31 13:30:34.712 60679 kcrr.c
    LGWR: Attempting destination LOG_ARCHIVE_DEST_3 network reconnect (16086)
    *** 2010-01-31 13:30:34.712 60679 kcrr.c
    LGWR: Destination LOG_ARCHIVE_DEST_3 network reconnect abandoned
    ORA-16086: standby database does not contain available standby log files
    *** 2010-01-31 13:30:34.712 60679 kcrr.c
    LGWR: Error 16086 creating archivelog file '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com)(PORT=1521
    +)))(CONNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated)))'+
    *** 2010-01-31 13:30:34.712 58941 kcrr.c
    kcrrfail: dest:3 err:16086 force:0 blast:1
    Receiving message from LNSc
    *** 2010-01-31 13:30:34.718 55444 kcrr.c
    Making upidhs request to LNSc (ocis 0x0xb648db48). Begin time is <01/31/2010 13:30:30> and NET_TIMEOUT <180> seconds
    NetServer pid:11196
    *** 2010-01-31 13:30:38.718 55616 kcrr.c
    upidhs done status 0
    *** 2010-01-31 13:36:31.062
    LGWR: Archivelog for thread 1 sequence 6513 will NOT be compressed
    *** 2010-01-31 13:36:31.062 53681 kcrr.c
    +Initializing NetServer[LNSc] for dest=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com)(PORT=1521)))(CO+
    NNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated))) mode SYNC
    LNSc is not running anymore.
    New SYNC LNSc needs to be started
    Waiting for subscriber count on LGWR-LNSc channel to go to zero
    Subscriber count went to zero - time now is <01/31/2010 13:36:31>
    Starting LNSc ...
    Waiting for LNSc to initialize itself
    *** 2010-01-31 13:36:34.116 53972 kcrr.c
    +Netserver LNSc [pid 11451] for mode SYNC has been initialized+
    Performing a channel reset to ignore previous responses
    +Successfully started LNSc [pid 11451] for dest (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=linserver2.com)(PORT=1+
    +521)))(CONNECT_DATA=(SERVICE_NAME=tehrep_XPT.com)(INSTANCE_NAME=tehrep)(SERVER=dedicated))) mode SYNC ocis=0x0xb648db48+
    *** 2010-01-31 13:36:34.116 54475 kcrr.c
    +Making upiahm request to LNSc [pid 11451]: Begin Time is <01/31/2010 13:36:31>. NET_TIMEOUT = <180> seconds+
    Waiting for LNSc to respond to upiahm
    *** 2010-01-31 13:36:34.266 54639 kcrr.c
    upiahm connect done status is 0
    Receiving message from LNSc
    Receiving message from LNSc
    Destination LOG_ARCHIVE_DEST_3 is in STANDBY RESYNCHRONIZATION mode
    Receiving message from LNSc

  • Recovery very very slow on the physical standby recently

    The standby was running fine for over a year. But recently the recovery became very slow. It took over an hour to apply one archivelog causing the standby falling behind. What could be the cause and solution?
    Thanks!

    Before I go further with my comment, I would recommend to open a SR with Oracle and have them help you to resolve the problem.
    You said that the archive logs are being applied, however the apply rate is slow? Is this true?
    Since you are applying the archive logs, it looks like your protection mode is set to ASYNC Maximum Performance.
    Can you check if all the logs are being shipped to the standby without any problem?
    There are couple of DG healthcheck scripts available on Metalink.
    Metalink Note 241438.1 Script to Collect Data Guard Physical Standby Diagnostic Information
    Metalink Note 241374.1 Script to Collect Data Guard Primary Site Diagnostic Information
    Can you run those scripts? If you feel comfortable, publish the output of the scripts on this tread, otherwise review them. They may give you some clue on what might be going on.
    Also check v$dataguard_status view.
    select *
    from v$dataguard_status
    where severity in ('Error','Fatal')
    order by timestamp; If you are not able to run the scripts due to database hanging state, as you described in your last post, try to determine why the database is hanging.
    In this kind of situations I usually use HANGANALYZE that will generate trace files for all the running processes. It may take a while until you review these files. Especially pay attention to the RFS process.
    SQL>oradebug setmypid
    SQL>oradebug unlimit;
    SQL>oradebug hanganalyze 266For more information on how to use HANGANALYZE refer to Metalink Notes: 175006.1, 452358.1 and 61552.1
    However, if you haven't used oradebug before or don't feel comfortable using it, you better don't do that and wait on instructions from Oracle.
    Also, as always, check the alert log file and the data guard log file (drc<sid>.log).
    Cheers,
    Edited by: tekicora on Dec 31, 2008 10:22 AM

  • Cancelling recovery on Physical standby.

    Hi ALL,
    recovery is cancel and i am looking following error in alert log file
    how can solve this problem
    database version 11gr2
    aix 6.1 64 bit
    physical standby datbase
    ORA-03170: deadlocked on readable physical standby (undo segment 65535)
    Tue Jun 05 12:25:27 2012
    Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
    c:
    ORA-03170: deadlocked on readable physical standby (undo segment 65535)
    Tue Jun 05 12:25:47 2012
    Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
    c:
    ORA-03170: deadlocked on readable physical standby (undo segment 65535)

    ORA-03170: deadlocked on readable physical standby (undo segment 65535)
    Tue Jun 05 12:25:27 2012
    Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
    c:
    ORA-03170: deadlocked on readable physical standby (undo segment 65535)
    Tue Jun 05 12:25:47 2012
    Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
    c:
    ORA-03170: deadlocked on readable physical standby (undo segment 65535)You cancelled recovery or it is terminated?
    Try to start once again, I have seen some listed bugs with the same error but those are applicable for 11gR1, but you are in 11gR2.
    Refer ORA-03170: Deadlocked on Readable Physical Standby [ID 846324.1], better you submit an SR to Support.
    Thanks.

  • Problem in identifying control file when creating physical standby

    hi there,
    (database version: 10.2.0.4
    plateform linux)
    I'm using the command as below to create physical standby database from backup:
    rman target / auxiliary sys/tiger@paceview
    Recovery Manager: Release 10.2.0.4.0 - Production on Tue Sep 4 18:05:53 2012
    Copyright (c) 1982, 2007, Oracle.  All rights reserved.
    connected to target database: PACEVIEW (DBID=2092349485)
    connected to auxiliary database: PACEVIEW (not mounted)
    run {
    allocate auxiliary channel c1 device type DISK;
    set until sequence 38;
    duplicate target database for standby dorecover nofilenamecheck;
    released channel: ORA_DISK_1
    allocated channel: c1
    channel c1: sid=35 devtype=DISK
    allocated channel: c2
    channel c2: sid=36 devtype=DISK
    executing command: SET until clause
    Starting Duplicate Db at 04-SEP-12
    contents of Memory Script:
       set until scn  138180211934;
       restore clone standby controlfile;
       sql clone 'alter database mount standby database';
    executing Memory Script
    executing command: SET until clause
    Starting restore at 04-SEP-12
    channel c1: restoring control file
    ORA-19625: error identifying file /backup/rman/paceview/DEL1_standby.ctl
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3
    ORA-19600: input file is control file  (/backup/rman/paceview/DEL1_standby.ctl)
    ORA-19601: output file is control file  (/PGHProdDB/oradata/paceview/control1.ctl)
    failover to previous backup
    released channel: c1
    released channel: c2
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of Duplicate Db command at 09/04/2012 18:01:44
    RMAN-03015: error occurred in stored script Memory Script
    RMAN-06026: some targets not found - aborting restore
    RMAN-06024: no backup or copy of the control file found to restorei have already tried crosscheck but still giving same error
    thanks

    Hello;
    So this is what I would do :
    Backup Primary ( change to your directory as need )
    RMAN RUN {
    allocate channel d1 type disk;
    backup format '/u01/backups/PRIMARY/df_t%t_s%s_p%p' database;
    sql 'alter system archive log current';
    backup format '/u01/backups/PRIMARY/al_t%t_s%s_p%p' archivelog all;
    backup current controlfile for standby format '/u01/backups/PRIMARY/sb_t%t_s%s_p%p';
    release channel d1;
    }Move the backup and duplicate like this :
    rman target sys/password@PRIMARY auxiliary /
    RMAN> run {
    allocate channel C1 device type disk;
    allocate auxiliary channel C2 device type disk;
    duplicate target database for standby nofilenamecheck;
    }For complete details of this method see :
    http://www.visi.com/~mseberg/duprman2.html
    Best Regards
    mseberg

  • Corrupting the block to continue recovery in physical standby

    Hi,
    Just like to inquire how I will be able to corrupt the block to be able to continue the recovery in the physical standby.
    DB Version: 11.1.0.7
    Database Type: Data Warehouse
    The setup we have is primary database and standby database, we are not using dataguard, and our standby setup is another physical copy of production which act as standby and being sync using script that being run from time to time to apply the archive log came from production (its not configured to sync using ARCH or LGWR and its corresponding configurations).
    Then, the standby database is not sync due to errors encountered while trying to apply the archive log, error is below:
    Fri Feb 11 05:50:59 2011
    ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
    ALTER DATABASE RECOVER CONTINUE DEFAULT
    Media Recovery Log /u01/archive/<sid>/1_50741_651679913.arch
    Fri Feb 11 05:52:06 2011
    Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0, kdr9ir2rst0()+326]
    Errors in file /u01/app/oracle/diag/rdbms/<sid>/<sid>/trace/<sid>pr0028085.trc (incident=631460):
    ORA-07445: exception encountered: core dump [kdr9ir2rst0()+326] [SIGSEGV] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0] [Address not mapped to object] []
    Incident details in: /u01/app/oracle/diag/rdbms/<sid>/<sid>/incident/incdir_631460/<sid>pr0028085_i631460.trc
    Fri Feb 11 05:52:10 2011
    Trace dumping is performing id=[cdmp_20110211055210]
    Fri Feb 11 05:52:14 2011
    Sweep Incident[631460]: completed
    Fri Feb 11 05:52:17 2011
    Slave exiting with ORA-10562 exception
    Errors in file /u01/app/oracle/diag/rdbms/<sid>/<sid>/trace/<sid>pr0028085.trc:
    ORA-10562: Error occurred while applying redo to data block (file# 36, block# 1576118)
    ORA-10564: tablespace <tablespace name>
    ORA-01110: data file 36: '/u02/oradata/<sid>/<datafile>.dbf'
    ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 14877145
    ORA-00607: Internal error occurred while making a change to a data block
    ORA-00602: internal programming exception
    ORA-07445: exception encountered: core dump [kdr9ir2rst0()+326] [SIGSEGV] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0] [Address not mapped to object] []
    Based on the error log it seems we are hitting some bug from metalink (document id 460169.1 and 882851.1)
    my question is, the datafile # is given, block# is known too and the data object is also identified. I just verified that object is not that important, is there a way to set the block# to corrupted to be able the recovery to continue? Then I will just drop the table from production so that will also happen in standby, and the block corrupted will be gone too. Is this feasible?
    If its not, can you suggest what's next I can do so the the physical standby will be able to sync again to prod aside from rebuilding the standby?
    Please take note that I also tried to dbv the file to confirm if there is marked as corrupted and the result for that datafile is also good:
    dbv file=/u02/oradata/<sid>/<datafile>_19.dbf logfile=dbv_file_36.log blocksize=16384
    oracle@<server>:[~] $ cat dbv_file_36.log
    DBVERIFY: Release 11.1.0.7.0 - Production on Sun Feb 13 04:35:28 2011
    Copyright (c) 1982, 2007, Oracle. All rights reserved.
    DBVERIFY - Verification starting : FILE = /u02/oradata/<sid>/<datafile>_19.dbf
    DBVERIFY - Verification complete
    Total Pages Examined : 3840000
    Total Pages Processed (Data) : 700644
    Total Pages Failing (Data) : 0
    Total Pages Processed (Index): 417545
    Total Pages Failing (Index): 0
    Total Pages Processed (Other): 88910
    Total Pages Processed (Seg) : 0
    Total Pages Failing (Seg) : 0
    Total Pages Empty : 2632901
    Total Pages Marked Corrupt : 0
    Total Pages Influx : 0
    Total Pages Encrypted : 0
    Highest block SCN : 3811184883 (1.3811184883)
    Any help is really appreciated. I hope to hear feedback from you.
    Thanks

    damorgan, i understand the opinion.
    just new with the organization and just inherit a data warehouse database without rman backup. I am still setting up the rman backup thats why i can't use rman to resolve the issue, the only i have is physical standby and its not a standby that automatically sync using dataguard or standard standby setup, i am just checking solution that is applicable in the current situation

  • Problem While Creating Physical Standby Using RMAN

    Hi Guru's
    May be this incidence you all face while creating physical standby DB. I try to create Physical standby database Using RMAN Duplicate Command from one server
    (pri machine) to Standby Machine.
    The steps i followed to create the above are as follows:
    Step 1:- Enable Forced Logging
    SQL> ALTER DATABASE FORCE LOGGING;
    Step 2:- Configure a Standby Redo Log
    SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10
      2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M;
    Step 3:- Set Primary Database Initialization Parameters
    SQL> create pfile='?/dbs/pfileorcl.ora' from spfile;
    Edit the pfile to add the standby parameters, here shown:
    db_unique_name='orcl'
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcldr)'
    LOG_ARCHIVE_DEST_2='SERVICE=orcldr LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcldr'
    *.fal_server=orcldr
    *.fal_client=orcl
    *.standby_file_management=auto
    Step 4:- Enable Archiving
    SQL> SHUTDOWN IMMEDIATE;
    SQL> STARTUP MOUNT;
    SQL> ALTER DATABASE ARCHIVELOG;
    SQL> ALTER DATABASE OPEN;
    Step 5:- Setup tnsnames for standby database
    This should be done on primary database by altering tnsnames.ora or using NetCA command, and create it by the name orcldr
    orcldr =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = standby-svr)(PORT = 1521))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = orcldr)
    Step 6:- Backup database and copy it to standby
    This backup script should be run on primary and copied to standby on the same mount point, running this scripts using RMAN, all files under /rman_backup should be copied to /rman_backup on standby server.
    $rman target /
    RMAN> run
    allocate channel c1 type disk;
    allocate channel c2 type disk;
    backup database format '/rman_backup/%U';
    backup archivelog all format '/rman_backup /%U';
    backup current controlfile for standby format '/rman_backup/%U';
    Step 7:- Standby Database Steps
    Installing Oracle Software
    This should be same release and patchset with exactly same ORACLE_HOME mount point.
    Setting Up listener
    Create and start a listener on standby database using NetCA, or creating listener.ora in $ORACLE_HOME/network/admin
    LISTENER =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = standby-svr)(PORT = 1521))
    Step 8:- Set Standby Database Initialization Parameters
    Copying the pfile created in primary database and renames it to initorcldr.ora, and changes these parameters:
    db_unique_name='orcldr'
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcldr,orcl)'
    LOG_ARCHIVE_DEST_2='SERVICE=orcl LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl'
    *.fal_server=orcl
    *.fal_client=orcldr
    *.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
    Step 9:- Setup tnsnames for primary database
    This should be done on standby database by altering tnsnames.ora or using NetCA command, and create it by the name orcl
    orcl =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = primary-svr)(PORT = 1521))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = orcl)
    Step 10:- Copy a Password File
    A password file must be created on the Primary and copied over to the Standby site. The sys password must be identical on both sites. Copy orapworcl to $ORACLE_HOME/dbs and rename file to orapworcldr
    Step 11:- Create mount points for Oracle
    Mount point should be created on standby server with the same convention used in primary, this includes the location for controlfiles, redo logs, datafiles, archive log destination and alert logs.
    $ mkdir -p /u01/app/oracle/oradata/orcl/
    $ mkdir -p /u01/app/oracle/flash_recovery_area/
    $ mkdir -p /u01/app/oracle/admin/orcl/adump
    $ mkdir -p /u01/app/oracle/admin/orcl/bdump
    $ mkdir -p /u01/app/oracle/admin/orcl/cdump
    $ mkdir -p /u01/app/oracle/admin/orcl/udump
    Step 12:- Use RMAN to restore backup and setup standby
    Connect to RMAN and execute the following command to create standby database, this should be performed on standby server after copying backup and setting tnsnames.
    $ export ORACLE_SID=orcldr
    $ rman target sys/tiger@orcl auxiliary sys/tiger@orcldr
    RMAN> duplicate target database for standby dorecover;
    Here i am getting problem as :
    While trying to connect to traget database and auxiliary database i notice that when RMAN is connect to both databases it shows
    orcl ( DBID xyz)
    orcl (not mounted)
    Here in my view the second database must be standby database name or auxiiary db name is standby db name which in my case is orcldr
    after this issue i am facing the second issues as :
    in command
    duplicate target database for standby dorecover;
    After modifying the command to
    RMAN> duplicate target database to "standby";
    rman-05520 database name mismatch
    Can u please let me know where i am mistaking

    ok for pri:
    db_name=orcl
    db_unique_name=orcl
    for standby:
    db_name=orcl 
    db_unique_name=sbyorcl ( i change orcldr to sbyorcl later)for new testing
    but now what i am getting on
      Verify connectivity
    On Primary Server:
    C:\> lsnrctl stop LISTENERI (working fine)
    C:\> lsnrctl start LISTENER (working fine)
    C:\> tnsping orcl (working fine)
    C:\> tnsping sbyorcl (working fine)
    C:\> sqlplus sys/xxxxx@orcl (working fine)
    C:\> sqlplus sys/xxxxx@sbyorcl (not working fine)
    ERROR:
    ORA-12514: TNS:listener does not currently know of service requested in connect
    descriptor
    On Standby Server:
    C:\>lsnrctl stop LISTENER
    C:\> lsnrctl start LISTENER
    C:\> tnsping orcl
    C:\> tnsping sbyorcl
    C:\> sqlplus sys/xxxxx@orcl
    C:\> sqlplus sys/xxxxx@sbyorcl
    My listner file for pri :-
    SID_LIST_LISTENER =
      (SID_LIST =
        (SID_DESC =
          (GLOBAL_DBNAME = orcl)
          (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)
          (SID_NAME = ORCL)
    LISTENER =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.202.129)(PORT = 1521))
    tnsnames.ora file on pri is:
    sbyorcl =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.202.128)(PORT = 1521))
        (CONNECT_DATA =
          (SERVICE_NAME = sbyorcl)
    ORCL =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.202.129)(PORT = 1521))
        (CONNECT_DATA =
          (SERVICE_NAME = orcl)
    and listener file on standby :
    SID_LIST_LISTENER =
      (SID_LIST =
        (SID_DESC =
          (SID_NAME = PLSExtProc)
          (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)
          (PROGRAM = extproc)
        (SID_DESC =
          (GLOBAL_DBNAME = orcl)
          (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)
          (SID_NAME = orcl)
    LISTENER =
      (DESCRIPTION_LIST =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.202.128)(PORT = 1521))
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    and tnsnames.ora file on standby:
    ORCL =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.202.128)(PORT = 1521))
        (CONNECT_DATA =
          (SERVICE_NAME = orcl)
    sbyorcl =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.202.129)(PORT = 1521))
    (CONNECT_DATA =
           SERVICE_NAME = sbyorcl)
    EXTPROC_CONNECTION_DATA =
      (DESCRIPTION =
        (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
        (CONNECT_DATA =
          (SID = PLSExtProc)
          (PRESENTATION = RO)
    Kinldy guide me where i am mistaking it's urgent

  • Related to recovery in Physical standby database in RAC

    In Physical Standby database all instance involved in recovery processes or any one instance will be their in in recovery mode
    If is like this another instance will be for high availabily can any one in forum explain me it will be help full

    With your Primary database being RAC, the Physical Standby does not have to be RAC, although, obviously it would be preferred to have scalability as required at a DR site.
    Whether your Standby is RAC or non-RAC, the automatic Recovery that is done at the Standby is done by one instance only. It would be applying the ArchiveLogs from all the threads (i.e. instances) of the Primary.
    Database Recovery is always done by a single instance.
    Hemant K Chitale
    http://hemantoracledba.blogspot.com

  • Problem in switchover to physical standby database

    Hi All,
    I am doing switchover from primary to physical standby database. Physical standby is in 'managed recovery' mode using real time apply and is in mount mode. I executed alter database commit to switchover to physical standby with session shutdown command. Now i am waiting for standby mrp to exit after processing eor record, but it seems mrp was hanged.
    Below is the content from standby database:
    Recovery of Online Redo Log: Thread 1 Group 5 Seq 620 Reading mem 0
    Mem# 0: /oracle/app/oracle/dbrac/th1-redo5a.log
    Resetting standby activation ID 749049115 (0x2ca5951b)
    Media Recovery End-Of-Redo indicator encountered
    Media Recovery Continuing
    Media Recovery Waiting for thread 1 sequence 621
    Archived Log entry 14 added for thread 1 sequence 620 ID 0x2ca5951b dest 1:
    Need some help to resolve.
    Thanks
    Sandy.

    Hello;
    After after you issue ( successfully ) a :
    alter database commit to switchover to physical standby with session shutdownYou need to :
    Shutdown the former primary and mount as a standby databaseCheck out my step by step :
    http://www.visi.com/~mseberg/data_guard/Data_Guard_switchover.html
    Read everything ( all the steps ) before you proceed.
    Best Regards
    mseberg

  • Problem creating physical Standby database with RMAN

    Hi All
    I am trying to learn oracle dataguard and as part of the process learning creating standby database.
    Platform : Sun-Fire-V250 Sparc, Solaris 10
    Database Version - Oracle 11R2
    I am creating standby database on same server, so directory structure is different.
    Following the instructions on Oracle site I managed to create a functional physical standby database. But I am not able to create standby database using RMAN. These are the steps that I followed-
    1.Set up all necessary parameters on primary database as done while creating physical standby database manually, eg setting force logging, creating standby logs etc.
    2.Edited parameter file on primary database as done while creating manual pysical standby database creation. Some of the changes done are-
    On Primary Database:
    *.FAL_CLIENT='orcl11020' #Primary database unique name
    *.FAL_SERVER='stdby_11' #Standby database unique name
    db_file_name_convert='/<dir>/oradata/stdby_11','/<dir>/oradata/orcl11020'
    log_file_name_convert='/<dir>/oradata/stdby_11','/<dir>/oradata/orcl11020','/<dir>/oradata/stdby_11/redo_mem','/<dir>/oradata/orcl11020/redo_mem'
    standby_file_management=auto
    *.log_archive_config='DG_CONFIG=(orcl11020,stdby_11)'
    *.log_archive_dest_1='LOCATION=/<dir>/flash_recovery_area/ORCL11020/archivelog
    VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=orcl11020'
    *.log_archive_dest_2='SERVICE=stdby_11 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=stdby_11'
    *.LOG_ARCHIVE_DEST_STATE_1='ENABLE'
    *.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
    *.LOG_ARCHIVE_FORMAT='%t_%s_%r.arc'
    *.LOG_ARCHIVE_MAX_PROCESSES=30
    Copied same pfile for standby database and modified following-
    *.control_files='/<dir>/oradata/stdby_11/stdby_11.ctl','/<dir>/fra_stdby/stdby_11/stdby_11.ctl'
    *.db_name='orcl1102'
    *.db_unique_name='stdby_11'
    *.FAL_CLIENT='stdby_11'
    *.FAL_SERVER='orcl11020'
    db_file_name_convert='/<dir>/oradata/orcl11020','/<dir>/oradata/stdby_11'
    log_file_name_convert='/<dir>/oradata/orcl11020','/<dir>/oradata/stdby_11','/<dir>/oradata/orcl11020/redo_mem','/<dir>/oradata/stdby_11/redo_mem'
    standby_file_management=auto
    *.log_archive_dest_1='LOCATION=/<dir>/fra_stdby/STDBY_11/archivelog
    VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=stdby_11'
    *.log_archive_dest_2='SERVICE=orcl11020 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
    db_unique_name=orcl11020'
    3. Add relevant information in tnsnames.ora and listener.ora files and then restart listener.
    3. Created password file with same credential as primary database.
    4.Up-to-date RMAN backup of primary database available.
    5.Create standby controlfile with rman
    While primary database s open (I tried with primary database in mount mode as well)-
    $>rman catalog rman/paswd@rman target /
    RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY;
    6. Open a new terminal and startup standby database in nomount mode using parameter file created -
    $>ORACLE_SID=stdby_11
    $>export ORACLE_SID
    $>sqlplus / as sysdba
    SQL>STARTUP NOMOUNT pfile='<location/initfilename.ora'
    SQL>quit
    $> rman AUXILIARY / target sys/passwd@orcl11020 catalog rman/passwd@rman
    RMAN>DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER;
    RMAN finishes without error but archive logs are not being tranported. Looking at the log, following caught my eye-
    Error 1017 received logging on to the standby
    Check that the primary and standby are using a password file
    and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
    and that the SYS password is same in the password files.
    returning error ORA-16191
    FAL[client, ARC2]: Error 16191 connecting to orcl11020 for fetching gap sequence
    Errors in file /<>dir>/diag/rdbms/stdby_11/stdby_11/trace/stdby_11_arc2_24321.trc:
    ORA-16191: Primary log shipping client not logged on standby
    Errors in file /<dir>/diag/rdbms/stdby_11/stdby_11/trace/stdby_11_arc2_24321.trc:
    ORA-16191: Primary log shipping client not logged on standby
    So on both primary and standby I confirmed
    SQL> show parameter remote_login_passwordfile
    NAME TYPE VALUE
    remote_login_passwordfile string EXCLUSIVE
    To make double sure that password files are same, I shutdown both databases, delete password files and recreated with same credentials.
    Password files are called - orapworcl11020 and orapwstdby_11
    Can someone guide me where thisngs are going wrong here please.

    Not sure if I understood it clearly.
    SELECT * FROM V$ARCHIVE_GAP;
    returns no rows so there is no gap.
    But could you please explain me the result of the previous query. To catch up again, on standby when I check
    SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG
    SEQUENCE# APPLIED
    75 NO
    74 NO
    76 NO
    77 NO
    I understand that though archive files have been copied across but they are not applied yet.
    On primary when I give your query -
    SELECT name as STANDBY,SEQUENCE#,applied, completion_time
    2 FROM v$archived_log
    3 where dest_id=2
    4 and sequence# BETWEEN 74 and 80;
    I get -
    STANDBY SEQUENCE# APPLIED COMPLETIO
    stdby_11 74 YES 28-JUN-11
    stdby_11 75 YES 28-JUN-11
    stdby_11 76 YES 29-JUN-11
    stdby_11 77 YES 29-JUN-11
    stdby_11 78 YES 29-JUN-11
    stdby_11 79 YES 29-JUN-11
    stdby_11 80 YES 29-JUN-11
    stdby_11 75 NO 07-JUL-11
    stdby_11 74 NO 07-JUL-11
    stdby_11 76 NO 07-JUL-11
    stdby_11 77 NO 07-JUL-11
    stdby_11 78 NO 07-JUL-11
    I have intentionally given
    sequence# BETWEEN 74 and 80
    because I know in the current incarnaion of the database, max sequence is 78.
    So my understanding is, the rows between 28-29 June are from previous incarnation, correct me if I am wrong
    Archive files of the current incarnation, since I successfully created standby database are shipped but yet to be applied - am I right?
    Then my final question is, when will these archives be applied to standby database?
    I am sorry to ask too many questions but I am just trying to understand how it all works.
    Thanks for your help again

  • Problem while creating Physical standby database on remote Server

    Hi
    I try to create a physical standby datbaase using OEM 10gr2, it is working when I create on same server. No issue but when I try to create same on remote server it is giving below warning and process failing. Please let me know what needs to be down in this senario...
    It is showing redo log information in v$log and v$log_file but not creating physically on PHYSICAL Standby instance..
    I appriciate your help and ur time too..
    These messages are from PRIMARY database alert*.log file
    There is space for up to 12 standby redo logfiles
    Use the following SQL commands on the standby database to create
    standby redo logfiles that match the primary database:
    ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
    ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 52428800;
    WARNING: OMF is enabled on this database. Creating a physical
    standby controlfile, when OMF is enabled on the primary
    database, requires manual RMAN intervention to resolve OMF
    datafile pathnames.
    NOTE: Please refer to the RMAN documentation for procedures
    describing how to manually resolve OMF datafile pathnames.
    Thanks and Regards,
    RK

    Well, it is simply warning that "Creating a physical
    standby controlfile, when OMF is enabled on the primary
    database, requires manual RMAN intervention to resolve OMF
    datafile pathnames.
    NOTE: Please refer to the RMAN documentation for procedures
    describing how to manually resolve OMF datafile pathnames"
    For instance, the path for the logfile name in "ALTER DATABASE ADD STANDBY LOGFILE 'srl5.f' SIZE 52428800" may need to be changed manually. It is advisable to check the mentioned documentation.

Maybe you are looking for