RAW primary database and ASM standby database

Hi,
I would like to know if it is possible to have a ASM standby database for a primary database which is on RAW files.Is there any changes in procedure for a switchover to DR site.

Sekar_BLUE4EVER wrote:
Hi,
I would like to know if it is possible to have a ASM standby database for a primary database which is on RAW files.Is there any changes in procedure for a switchover to DR site.Yes, you can. and there is no change in procedure for switchover.
for creation of standby DB, consider these parameters: db_create_file_dest,db_recovery_file_dest,control_files
see an example here: http://pythianpang.wordpress.com/2010/02/18/data-guard-non-asm-primary-to-asm-physical-standby/
HTH
Tobi
Edited by: teits on Nov 20, 2012 12:13 PM

Similar Messages

  • Logical Standby Database Not Getting Sync With Primary Database

    Hi All,
    I am using a Primary DB and Logical Standby DB configuration in Oracle 10g:-
    Version Name:-
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
    PL/SQL Release 10.2.0.5.0 - Production
    CORE 10.2.0.5.0 Production
    TNS for Solaris: Version 10.2.0.5.0 - Production
    NLSRTL Version 10.2.0.5.0 - Production
    We have build the logical standby last week and till date the Logical DB is not sync. I have checked the init parameters and I wont see any problems with it. Also archive log destinations are also fine enough.
    We have a important table named "HPD_HELPDESK" where record count is growing gradually whereas in logical standby it's not growing. There are some 19K record difference in the both the tables.
    I have checked the alert log but it is also not giving any error message. Please find the last few lines of the alert log in logical Database:-
    RFS LogMiner: Registered logfile [oradata_san1/oradata/remedy/arch/ars1_1703_790996778.arc] to LogMiner session id [1]
    Tue Aug 28 14:56:52 GMT 2012
    RFS[2853]: Successfully opened standby log 5: '/oracle_data/oradata/remedy/stbyredo01.log'
    Tue Aug 28 14:56:58 GMT 2012
    RFS LogMiner: Client enabled and ready for notification
    Tue Aug 28 14:57:00 GMT 2012
    RFS LogMiner: Registered logfile [oradata_san1/oradata/remedy/arch/ars1_1704_790996778.arc] to LogMiner session id [1]
    Tue Aug 28 15:06:40 GMT 2012
    RFS[2854]: Successfully opened standby log 5: '/oracle_data/oradata/remedy/stbyredo01.log'
    Tue Aug 28 15:06:47 GMT 2012
    RFS LogMiner: Client enabled and ready for notification
    Tue Aug 28 15:06:49 GMT 2012
    RFS LogMiner: Registered logfile [oradata_san1/oradata/remedy/arch/ars1_1705_790996778.arc] to LogMiner session id [1]
    I am not able to trace the issue that why the records are not growing in logical DB. Please provide your inputs.
    Regards,
    Arijit

    How do you know that there's such a gap between the tables?
    If your standby db is a physical standby, then it is not open and you can't query your table without cancelling the recovery of the managed standby database.
    What does it say if you execute this sql?
    SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;The ARCH processes should be connected and MRP waiting for a file.
    If you query for the archive_gaps, do you get any hits?
    select * from gv$archive_gapIf you're not working in a RAC environment you need to query v$archive_gap, instead!
    Did you check whether the archives generated from the primary instance are transferred and present in the file system of your standby database?
    I believe your standby is not in recovery_mode anymore or has an archive_gap, which is the reason why it doesn't catch up anymore.
    Hope it helps a little,
    Regards,
    Sebastian
    PS: I'm working on 11g, so unfortunately I'm not quite sure if the views are exist in 10gR2. It's worth a try though!
    Edited by: skahlert on 31.08.2012 13:46

  • Primary database switchover problem

    I am getting the following error when i execute 'alter database commit to switchover to standby with session shutdown' in primary database
    ora-16416 no viable physical standby switchover targets available
    What may be the reason???
    I am using Oracle Server-Standard Edition 11g R2
    version: 11.2.0.1

    Hello Gurus,
    I did a switchover and then performed a reverse switchover again. So Primary(original) is Primary now and My Standby(original) is Standby now.
    The Problem is when I monitor the Logs Archived and Applied I noticed below:
    In PRIMARY SIDE
    NAME ARC APPLIED SEQUENCE# DEST_ID
    D:\EDRIVE\PRIMARY\ARC\1_55_815075358.ARC YES YES 55 1
    D:\EDRIVE\PRIMARY\ARC\1_56_815075358.ARC YES YES 56 1
    STANDBY YES YES 56 2
    STANDBY YES YES 55 2
    STANDBY YES YES 54 2
    STANDBY YES YES 53 2
    STANDBY YES YES 52 2
    STANDBY YES YES 50 2
    STANDBY YES YES 51 2
    STANDBY YES YES 57 2
    D:\EDRIVE\PRIMARY\ARC\1_57_815075358.ARC YES YES 57 1
    D:\EDRIVE\PRIMARY\ARC\1_58_815075358.ARC YES YES 58 1
    STANDBY YES YES 58 2
    STANDBY YES YES 59 2
    D:\EDRIVE\PRIMARY\ARC\1_59_815075358.ARC YES YES 59 1
    STANDBY YES YES 60 2
    D:\EDRIVE\PRIMARY\ARC\1_60_815075358.ARC YES YES 60 1
    STANDBY YES YES 61 2
    D:\EDRIVE\PRIMARY\ARC\1_61_815075358.ARC YES YES 61 1
    STANDBY YES YES 62 2
    D:\EDRIVE\PRIMARY\ARC\1_62_815075358.ARC YES YES 62 1
    D:\EDRIVE\PRIMARY\ARC\1_63_815075358.ARC YES YES 63 1
    STANDBY YES YES 63 2
    D:\EDRIVE\PRIMARY\ARC\1_64_815075358.ARC YES YES 64 1
    D:\EDRIVE\PRIMARY\ARC\1_65_815075358.ARC YES YES 65 1
    D:\EDRIVE\PRIMARY\ARC\1_66_815075358.ARC YES YES 66 1
    D:\EDRIVE\PRIMARY\ARC\1_67_815075358.ARC YES YES 67 1
    D:\EDRIVE\PRIMARY\ARC\1_68_815075358.ARC YES YES 68 1
    D:\EDRIVE\PRIMARY\ARC\1_69_815075358.ARC YES NO 69 1
    STANDBY YES YES 69 2
    D:\EDRIVE\PRIMARY\ARC\1_70_815075358.ARC YES NO 70 1
    STANDBY YES YES 70 2
    D:\EDRIVE\PRIMARY\ARC\1_71_815075358.ARC YES NO 71 1
    STANDBY YES YES 71 2
    STANDBY YES YES 72 2
    D:\EDRIVE\PRIMARY\ARC\1_72_815075358.ARC YES NO 72 1
    D:\EDRIVE\PRIMARY\ARC\1_73_815075358.ARC YES NO 73 1
    STANDBY YES YES 73 2
    D:\EDRIVE\PRIMARY\ARC\1_74_815075358.ARC YES NO 74 1
    STANDBY YES YES 74 2
    D:\EDRIVE\PRIMARY\ARC\1_75_815075358.ARC YES NO 75 1
    STANDBY YES YES 75 2
    STANDBY YES YES 76 2
    D:\EDRIVE\PRIMARY\ARC\1_76_815075358.ARC YES NO 76 1
    D:\EDRIVE\PRIMARY\ARC\1_77_815075358.ARC YES NO 77 1
    STANDBY YES YES 77 2
    In STANDBY SIDE
    NAME ARC APPLIED SEQUENCE#
    D:\EDRIVE\STANDBY\ARC\1_55_815075358.ARC YES YES 55
    D:\EDRIVE\STANDBY\ARC\1_54_815075358.ARC YES YES 54
    D:\EDRIVE\STANDBY\ARC\1_53_815075358.ARC YES YES 53
    D:\EDRIVE\STANDBY\ARC\1_52_815075358.ARC YES YES 52
    D:\EDRIVE\STANDBY\ARC\1_50_815075358.ARC YES YES 50
    D:\EDRIVE\STANDBY\ARC\1_51_815075358.ARC YES YES 51
    D:\EDRIVE\STANDBY\ARC\1_56_815075358.ARC YES YES 56
    D:\EDRIVE\STANDBY\ARC\1_57_815075358.ARC YES YES 57
    D:\EDRIVE\STANDBY\ARC\1_58_815075358.ARC YES YES 58
    D:\EDRIVE\STANDBY\ARC\1_59_815075358.ARC YES YES 59
    D:\EDRIVE\STANDBY\ARC\1_60_815075358.ARC YES YES 60
    D:\EDRIVE\STANDBY\ARC\1_61_815075358.ARC YES YES 61
    D:\EDRIVE\STANDBY\ARC\1_62_815075358.ARC YES YES 62
    D:\EDRIVE\STANDBY\ARC\1_63_815075358.ARC YES YES 63
    D:\EDRIVE\STANDBY\ARC\1_64_815075358.ARC YES YES 64
    D:\EDRIVE\STANDBY\ARC\1_65_815075358.ARC YES YES 65
    PRIMARY YES YES 64
    PRIMARY YES YES 65
    D:\EDRIVE\STANDBY\ARC\1_66_815075358.ARC YES YES 66
    PRIMARY YES YES 66
    PRIMARY YES NO 67
    D:\EDRIVE\STANDBY\ARC\1_67_815075358.ARC YES YES 67
    D:\EDRIVE\STANDBY\ARC\1_68_815075358.ARC YES YES 68
    PRIMARY YES NO 68
    D:\EDRIVE\STANDBY\ARC\1_69_815075358.ARC YES YES 69
    D:\EDRIVE\STANDBY\ARC\1_70_815075358.ARC YES YES 70
    D:\EDRIVE\STANDBY\ARC\1_71_815075358.ARC YES YES 71
    D:\EDRIVE\STANDBY\ARC\1_72_815075358.ARC YES YES 72
    D:\EDRIVE\STANDBY\ARC\1_1_815506630.ARC YES NO 1
    D:\EDRIVE\STANDBY\ARC\1_73_815075358.ARC YES YES 73
    D:\EDRIVE\STANDBY\ARC\1_74_815075358.ARC YES YES 74
    D:\EDRIVE\STANDBY\ARC\1_75_815075358.ARC YES YES 75
    D:\EDRIVE\STANDBY\ARC\1_76_815075358.ARC YES YES 76
    D:\EDRIVE\STANDBY\ARC\1_77_815075358.ARC YES YES 77
    I wonder why in Some cases it is coming as APPLIED=NO and both the Primary and Standby.
    Also in Standby D:\EDRIVE\STANDBY\ARC\1_1_815506630.ARC  YES NO                 1 why sequence number 1 is gerenarated an not applied any where?
    Could any one of you please help me to know this?
    -Regards,
    Saha

  • Can Grid Control 10gR2 create a standby database when primary db uses ASM?

    Does anyone know if Grid Control 10gR2 will be able to create a standby database when the primary database uses ASM for data files, redo log files, and archive log files but the standby database will use mounted disks? If it can, would it matter that the primary db will be a RAC cluster and the standby will be a single instance db?

    I appreciate your reply and hope you are correct. Have you had a look at the 10gR2 Grid Control to confirm this or are you only going on published statements? The reason I ask is because previous versions of Grid Control claimed to support ASM but they would only allow you to work with them AFTER you had created a standby database manually but you couldn't actually use Grid Control to create a standby database from a primary database that had its log files on ASM disks.

  • Is the only way to import large amount of data and database objects into a primary database is to shutdown the standby, turn off archive log mode, do the import, then rebuild the standby?

    I have a primary database that need to import large amount of data and database objects. 1.) Do I shutdown the standby? 2.) Turn off archive log mode? 3.) Perform the import? 4.) Rebuild the standby? or is there a better way or best practice?

    Instead of rebuilding the (whole) standby, you take an incremental (from SCN) backup from the Primary and restore it on the Standby.  That way, if, for example
    a. Only two out of 12 tablespaces are affected by the import, the incremental backup would effectively be only the blocks changed in those two tablespaces (and some other changes in system and undo) {provided that there are no other changes in the other ten tablespaces}
    b. if the size of the import is only 15% of the database, the incremental backup to restore to the standby is small
    Hemant K Chitale

  • Creating standby database and replication of primary database in 9i

    Hi,
    We have a 9i database on Windows Server.Now recently we are planning to replicate the primary database to standby database once after creating the standby database.Can anyone guide me with the procedure or documentation with this . We were asked to do this without the data guard set-up. Please do help me regarding this ASAP.
    Regards,

    specifiying ASAP isnt a way to get people to help on a volunteer forum.
    If you dont have dataguard You need to search for "manual standby apply".
    lots and lots and lots of google hits for you but this is the official cookbook
    http://docs.oracle.com/cd/B10500_01/server.920/a96653/manual_recovery.htm

  • SECURITY PATCH ON STANDBY DATABASE AND PRIMARY DATABASE

    I have a question on applying CPU on standby and primary database
    I have a standby database on machine2 and primary on machine1
    I applied a CPU patch on the Oracle Home of Standby database and
    did not run the catcpu.sql as standbydatabase is in mount state.
    Now i am going to apply the CPU patch on primary database.
    What i need to confirm is that after i apply the patch on primary database oracle home
    and run the cat cpu.sql on that do i have to do anything on the standby database
    for instance rebuilding it or something or the change would be shipped to the standby
    server automatically.
    The purpose is to have the primary and standby database on the same patch level
    in case of a failover
    Please let me know asap

    Any one has any idea on this. Any ideas would be appreciated

  • Primary and Physical Standby databases hanging on sqlplus shell command...

    I am primarily a java developer that has had the task of oracle dba thrust upon me due to circumstances that are beyond my control. In the QA lab we have two oracle 10 g release 1 instances running. They set up in a dataguard configuration: one is the primary and the other is in a physical standby.
    Last week I noticed that the disk space on the primary database was at 100%. After some investigation I discovered that a good deal of the files taking up space on the box were log files and the best solution that I could think of would be to delete all old archive files. So I deleted the old archive files that were at least two weeks old using RMAN.
    During this week the database started to shutdown automatically. The QA associate restarted the database twice using the ‘STARTUP’ command from sqlplus. Additionally, the standby database began to have issues: when login in to sqlplus the application would just hang: no ‘SQL” prompt or anything. Finally today the primary database has also begun to hang in a similar manner.
    I have looked at many of the trace files and alert logs but haven’t been able to really discern what the real problem is with the database and the proper rectification for the database. Does anyone have a clue into what is going on? If someone could even point me in the right direction it would be greatly appreciated.

    Guessing that your flash recovery area is full, archiving is stopped so the instance appears to hang.
    Do you see messages like so in the alert log:
    You have following choices to free up space from flash recovery area:
    1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
       then consider changing RMAN ARCHIVELOG DELETION POLICY.
    2. Back up files to tertiary device such as tape using RMAN
       BACKUP RECOVERY AREA command.
    3. Add disk space and increase db_recovery_file_dest_size parameter to
       reflect the new space.
    4. Delete unnecessary files using RMAN DELETE command. If an operating
       system command was used to delete files, then use RMAN CROSSCHECK and
       DELETE EXPIRED commands.
    ************************************************************************

  • Primary database is RAC and Physical standby is single instance

    Hello All,
    I am using Oracle RAC 11.2.0.3 as primary database, we are going to start using Oracle data guard.
    So I am designing my infrastructure and planing to use Oracle 11.2.0.3 Single instance as my physical stand by database.
    My question is it feasible to have my standby database as single instance while the primary is RAC?
    is it feasible to build my Oracle single instance standby database from the RMAN backup of the RAC primary database?
    Is there any restrictions (or any points to be taken into consideration) since my primary database is RAC while the physical standby is Oracle single instance?
    in the below link
    [http://docs.oracle.com/cd/B28359_01/server.111/b28294/concepts.htm#i1039416]
    it was mentioned that primary can be RAC or single and same for standby, but my question is it feasible to have primary as RAC while standby as single instance? or it should be like each others?
    The primary database can be either a single-instance Oracle database or an Oracle Real Application Clusters (RAC) database.
    Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle RAC database.Regards,

    My question is it feasible to have my standby database as single instance while the primary is RAC?Yes...quite a common setup.
    is it feasible to build my Oracle single instance standby database from the RMAN backup of the RAC primary database?Yes.
    Is there any restrictions (or any points to be taken into consideration) since my primary database is RAC while the physical standby is Oracle single instance?No show stoppers.

  • Primary Database and Standby Database sync

    How to know that standby database is in sync with primary database?

    Query the V$LOG_HISTORY view on the standby database, which records the latest log sequence number that has been applied. For example, issue the following query:
    SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
    2> FROM V$LOG_HISTORY
    3> GROUP BY THREAD#;
    THREAD# LAST_APPLIED_LOG
    1 967In this example, the archived redo log with log sequence number 967 is the most recently applied log.
    You can also use the APPLIED column in the V$ARCHIVED_LOG fixed view on the standby database to find out which log is applied on the standby database. The column displays YES for the log that has been applied. For example:
    SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;
    THREAD# SEQUENCE# APP
    1 2 YES
    1 3 YES
    1 4 YES
    1 5 YES
    1 6 YES
    1 7 YES
    1 8 YES
    1 9 YES
    1 10 YES
    1 11 NO

  • Delete standby redo log from primary database

    Hi all,
    I'm trying to drop standby logfiles on primary database (other database that I'm configuring the DG).
    The members of the standby log groups don't exists on file system.
    Somebody have deleted these files. Its old configuration where the files were in file system. Now they are in ASM.
    When I try to drop the standby logfiles I got the following error:
    SQL> alter database clear logfile group 7;
    alter database clear logfile group 7
    ERROR at line 1:
    ORA-19528: redo logs being cleared may need access to files
    SQL> select * from v$logfile order by 1;
        GROUP# STATUS  TYPE    MEMBER                                                                           IS_
             1         ONLINE  +REDO1/proj/onlinelog/group_1.256.340558657                                     NO
             1         ONLINE  +REDO2/proj/onlinelog/group_1.256.340558659                                     NO
             2         ONLINE  +REDO1/proj/onlinelog/group_2.257.340558879                                     NO
             2         ONLINE  +REDO2/proj/onlinelog/group_2.259.340558879                                     NO
             3         ONLINE  +REDO1/proj/onlinelog/group_3.258.340558707                                     NO
             3         ONLINE  +REDO2/proj/onlinelog/group_3.257.340558709                                     NO
             4         ONLINE  +REDO2/proj/onlinelog/group_4.258.340558713                                     NO
             4         ONLINE  +REDO1/proj/onlinelog/group_4.259.340558711                                     NO
             5         ONLINE  +REDO2/proj/onlinelog/group_5.260.340558965                                     NO
             5         ONLINE  +REDO1/proj/onlinelog/group_5.260.340558963                                     NO
             6         ONLINE  +REDO1/proj/onlinelog/group_6.261.340558967                                     NO
             6         ONLINE  +REDO2/proj/onlinelog/group_6.261.340558967                                     NO
             7         STANDBY /oracle/proj/onlinelog2/redo_702.log                                            NO
             7         STANDBY /oracle/proj/onlinelog1/redo_701.log                                            NO
             8         STANDBY /oracle/proj/onlinelog2/redo_802.log                                            NO
             8         STANDBY /oracle/proj/onlinelog1/redo_801.log                                            NO
             9         STANDBY /oracle/proj/onlinelog2/redo_902.log                                            NO
             9         STANDBY /oracle/proj/onlinelog1/redo_901.log                                            NO
            10         STANDBY /oracle/proj/onlinelog1/redo_1001.log                                           NO
            10         STANDBY /oracle/proj/onlinelog2/redo_1002.log                                           NO
    20 rows selected.
    SQL> select * from v$standby_log order by 1;
        GROUP# DBID            THREAD#  SEQUENCE#      BYTES       USED ARC STATUS     FIRST_CHANGE# FIRST_TIM LAST_CHANGE# LAST_TIME
             7 UNASSIGNED            0          0  104854601        512 YES UNASSIGNED             0                      0
             8 UNASSIGNED            0          0  104854601        512 YES UNASSIGNED             0                      0
             9 UNASSIGNED            0          0  104854601        512 YES UNASSIGNED             0                      0
            10 UNASSIGNED            0          0  104854601        512 YES UNASSIGNED             0                      0What can I do to drop these reference?
    Any other solution instead of edit the controlfile and stop/start tghe database?
    thank you!!!!

    Hello;
    Well Oracle thinks the files are there, but I remember a bug on metalink where the controlfile still had them, but they were not on the file system. Can you confirm they exist?
    Meanwhile I check my notes for the Oracle doc nunber.
    Bug 6128242: TRYING TO DROP STANDBY LOG FAILS WITH ORA-19528
    So if you are Oracle 10 this might be the issue.
    workaround is to re-create the controlfile without the incorrect logfile. ( Yuk!! )
    ORA-01156 When Adding Or Dropping Redo Logs [ID 452152.1]
    Best Regards
    mseberg
    Edited by: mseberg on Oct 31, 2011 5:09 PM

  • ASM on primary and physical standby on normal filesystem

    Hi
    I have seen he white paper by oracle on migrating a database to ASM with minimal downtime using ASM for a physical standby my requirement is reverse.
    I need to have a ASM for a primary database but no ASM for standby database.
    How do we set the parameter db_file_name_convert
    regards
    Hrishy

    db_file_name_convert covers the folder path for the files. I don't think, there will be issue.
    If we use rman, it will use the folder path per db_file_name_convert and retain the old file names. OMF naming will apply for the new files.
    Ashok

  • Configuring both logical and physical standby databases.

    Hi,
    I am trying to set up one primary and two standby databases which are physical and logical. together. What I am wondering is if i tis posiible to set both log_archive_dest_n parameters in init.ora of primary db to 'LGWR ASYNC'.. I tried to do that but I noticed that while redo data goes the first remote log destination including LGWR statement properly but for the second it does not.
    So my assumption is only one remote archive dest. can be set for the LGWR process. Is ıt right?
    Regards
    ALPER ONEY
    email:[email protected]

    Hi,
    when I set remote archive dest _n parameter for logical  standby database to the value like 'LGWR AYSNC' and for the phy. standby to 'ARCH', it is ok. But if I change both parameters to 'LGWR'. I can see that only one destination receives the redo data and this destination is also the first destination configured for receiving redodata . I am just wondering that LGWR process is able to serve two or more to destinations at the same time. If it is ok, I am wrong and I better to try harder to solve the problem. I read the Dataguard document for 10GR' and the example for the case I created (two standby databases),, it uses ARCH process to send redo data and so everything is ok in that example.
    P.S I also configured standbys for real time apply.
    Waiting for your comments.
    Regards.
    ALPER ONEY

  • CPU patch procedure with physical and logical standby database in place

    Hello All,
    I've also placed this in the Upgrades forum, but perhaps this is the best place to have put it.
    I'm trying to compile a decent set of steps for applying the CPUOCT2008 patch to our production RAC cluster which has both a logical and physical standby in place. I've read a tonne of documentation, including the CPU readme, DOCID 437276.1 and 278641.1. I''ve also read through the Upgrading Databases in a Data Guard Configuration chapter of Dataguard Concepts and Administration. The last doc mentioned is really for upgrading a full version of Oracle rather than applying a CPU (at least I think that's the case). DocID 437276.1 is rather sparse on details.
    I guess what I'm trying to understand is the proper method for applying the patch with the logical standby in place. The physical standby looks pretty straightforward. After running opatch on it as well, it will basically have all of the changes applied to the primary shipped over and applied as per the normal primary/standby relationship. Will the same be true for the logical (having applied the patch, and then re-enabling SQL apply)? Should I aim to have it work that way? By that I mean start it up and re-enable sql apply and then upgrade the primary. Or, am I to apply the catcpu.sql script to it as well before re-enabling the sql apply? Am I wrong in regards to the physical standby as well i.e. should the catcpu also be applied directly to it?
    Thanks very much in advance.
    Cheers,
    Chris
    Edited by: chris.baron on Dec 12, 2008 11:38 AM

    Given the fact that your system is far from main-stream I'd recommend opening an SR with Oracle Support Services (metalink) and asking them.
    If you would like to publish a White Paper on your experience after you have successfully completed the project let me know off-line.

  • Why do we need standby redo log on Primary database.

    Hi Gurus,
    I was going through the document in OBE,
    http://www.oracle.com/technology/obe/11gr1_db/ha/dataguard/physstby/physstdby.htm
    I have two queries:
    1) I noticed the statement -
    "Configure the primary database to receive redo data, by adding the standby logfiles to the primary. "
    Why do we have to create standby redo log on a primary database?
    2) There is another statement --
    "It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. The files must be the same size or larger than the primary database’s online redo logs. "
    Why do we need one additional standby redo log group than in Primary database.
    Could anyone please explain to me in simple words.
    Thanks
    Cherrish Vaidiyan

    Hi,
    1. Standby redo logs are used only when the database_role is standby, it is recommended to be added in primary also so that they can be used on role reversal, however during normal working standby redo logs will not be used at all on primary.
    2. In case of 3 online redo log groups, it is recommended to use 4 standby redo log group this is in case if log switching is happening frequently on primary and all 3 standby redo logs are still not completely archived on the standby and 4th can be used here as there will be some delay on standby due to network or slowness of arch on standby.
    Use of the standby redo log groups depends on the redo generation rate, you can see only 2 standby redo logs are getting used while you have 4 standby redo log groups, when the redo generation rate is less.
    So it is recommended to have one more standby redo log group when redo generation rate is high and all of the existing standby redo log group are getting used.
    Regards
    Anudeep

Maybe you are looking for