This discussion is archived
7 Replies Latest reply: Mar 15, 2013 7:24 AM by jhall RSS

Running a physical standby database in noarchivelog mode

jhall Newbie
Currently Being Moderated
Primary Database: 2 node rac cluster, 11.2.0.2 GI and RDBMS
Standby Database: single instance 11.2.0.2
OS: AIX 7.1

Hello,

I'm in the process of implementing a data guard standby system. To make this system simpler to admin, I want to run the standby database in NOARCHIVELOG mode. This standby is used only as a mirror of production (to be copied to a 3rd site for separate user activity) and will never be switched to active mode. Maintaining another set of archive logs seems to be redundant to me and another point of failure, so I want to disable archiving. I wanted to ask if any of the DG experts on the forums have ever had experience with this? Does anyone know if this is recommended? I've searched the Oracle Data guard documentation online... it says that the primary obviously needs to be in archive mode, but I'm not seeing anything specific about the standby. Please let me know if anyone has experience with this.

Thanks
  • 1. Re: Running a physical standby database in noarchivelog mode
    mseberg Guru
    Currently Being Moderated
    Hello;
     
    I wanted to ask if any of the DG experts on the forums have ever had experience with this? 
    I'm thinking no.
    Does anyone know if this is recommended? 
    I cannot imagine it would be.


    Not sure what you are trying to do or what the purpose is. A Standby does not generate Archive unless its in Primary mode. In which case you want archivelog mode.

    What is your goal or business requirement?


    Best Regards

    mseberg
  • 2. Re: Running a physical standby database in noarchivelog mode
    jhall Newbie
    Currently Being Moderated
    Hi mseberg,

    I'll try to explain in a little more detail.

    The high level concept of what we're trying to do is:

    a) create an active mirror of the production system, using data guard
    b) monthly, shutdown this system and copy it to a 3rd site to host a separate set of business activity
    c) resync the "mirror" with production

    The production system is very busy and produces a lot of archive logs. I was concerned that the standby would also create a lot of archive logs, and I'd have to perform frequent backups to keep them cleaned up.

    I think you may have answered my question though... you said: "A Standby does not generate Archive unless its in Primary mode." I was not aware that the standby doesn't generate it's own logs. If this is the case, then I have nothing to worry about here. Does that sound right to you?
  • 3. Re: Running a physical standby database in noarchivelog mode
    mseberg Guru
    Currently Being Moderated
    Hello again;
    If this is the case, then I have nothing to worry about here. Does that sound right to you?
    Yes.

    For this :
    b) monthly, shutdown this system and copy it to a 3rd site to host a separate set of business activity
    I would consider RMAN Duplicate in which case you may avoid the shutdown.


    And for this :

     resync the "mirror" with production
    All you have to do if DEFER the primary to the standby, then ENABLE and Data Guard will catch up.


    --- Will post a detailed example here in a moment.

    Right at the first of the year they wanted to work on our Primary server room ( Power ). What I did was switchover to the Standby but I kept log_archive_dest_state_2 on the new primary set to DEFER. Then I shutdown
    all the databases at the Primary site. At the end of work two days later I started the databases at the Primary site in standby mode. Switched log_archive_dest_state_2 to ENABLE. When the databases were back in SYNC
    I did another switchover and it was done. I used TAF and none of the users even noticed.





    Best Regards

    mseberg
  • 4. Re: Running a physical standby database in noarchivelog mode
    jhall Newbie
    Currently Being Moderated
    Thanks mseberg, we are new to data guard, so thanks for the clarification here with how the logging works.

    Per your comment: "I would consider RMAN Duplicate in which case you may avoid the shutdown."

    That is actually the other method we're investigating to host this business need. We use duplicate a lot and it is very clean and easy to use... we could script a refresh, and that would be it. The only issue is that the primary db is 8tb in size. What the standby buys us is an active mirror. We then use IBM flashcopy, which copies the physical storage of 1 system to another. This tool copies the data very quickly, in a fraction of the time of a standard copy. So, there are pros and cons to both methods. As you pointed out, the duplicate is certainly simpler.

    Thanks again for your clarification about the logs. And yes, anything you can share about how exactly to resync the data guard "mirror" with production is appreciated.
  • 5. Re: Running a physical standby database in noarchivelog mode
    jhall Newbie
    Currently Being Moderated
    Thanks for the info about the 'defer' archive setting. I'll basically be doing the same thing, minus the switchover.

    Just out of curiousity, how busy is your application, and how long did it take for your standby to sync back up?
  • 6. Re: Running a physical standby database in noarchivelog mode
    mseberg Guru
    Currently Being Moderated
    Hello;

    OK. SAN copy swap or similar.

    On resync. Just DEFER the Primary. If the outage is too long you can use RMAN to roll a Standby forward :

    My friend CKPT has this on that.

    RMAN Incremental Backups to Roll Forward a Physical Standby Database


    http://www.oracle-ckpt.com/?s=standby+scn&op.x=0&op.y=0


    While a Standby does not create Archive, Archive is transported to a Standby from a Primary database. Generally this can be removed right after its applied and there are many options to do this.

    Best Regards

    mseberg
  • 7. Re: Running a physical standby database in noarchivelog mode
    jhall Newbie
    Currently Being Moderated
    Wow, that is great you can use rman incrementals to roll forward the standby database. I have an old copy of production out there now, and I was just planning on doing a fresh copy when we actually take the outage to initiate the data guard standby. Using a set of incrementals prior to the outage to get the standby close to sync'd with the primary will save a TON of time.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points