RE: DataGuard

  • From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
  • To: rgoulet@xxxxxxxxxx
  • Date: Tue, 16 Jan 2007 00:12:00 +0100


In Mon, 2007-01-15 at 15:57 -0500, Richard J. Goulet wrote:
> Thanks guys,  You've given me plenty to read & think upon.  What I
> have to do for a client is have a main database server with a fail
> over standby in the same data center (they did not want to pay for
> RAC, LONGGG story), 

Good decision! Most of my customers do this.

> and a disaster recovery standby database in a disaster recovery
> datacenter 2,000 miles away.  The idea is to have either database in
> the local datacenter be the prime with the other as a standby & the DR
> site maintained automatically.  Looks like I've some fun to have.

This is the setup I have running at over a dozen sites. Works like a

Stay away from cascaded redo transport as far as you can. You simply
don't want that in HA environments. As states:
'..Complexity is the enemy of availability...' (and I'd like to add: '..
but the friend of consultancy...' J). Imagine a switchover with cascaded
transport. The whole redo transport stack has to be reinvented. A
star-configuration (primary points to both standbys) is much easier to

It will take quite some text to explain all the tricks and pitfalls and
so on, and I do not have time to do that right now.
Topics to take care of are:

      * naming conventions. A must to do that right to give yourself a
        true monkeyproof HA environment.
      * Symmetry. Keep everything (filenames, directory tree structures)
        completely symmetric! You do not want to find your way out in a
        completely 'strange' system if you need it for real production
        work after three years! You do not want to know what nice errors
        people can come up with due to lack of symmetry.
      * listener setup. Be careful in separating roles a database can
        play: The most extended setup knows of primary, standby, redo
        transport, FAL and administrator roles. I use separate
        listeners, port numbers and for redo, preferably separated NICs
        for this setup.
      * connect time failover: this allows you to switch over / fail
        over without hassle for the applications. They simply reconnect.
        You can ppoint the FAL_SERVER at the standbys to a FAILOVER
        enabled tns entry too. A standby that is not involved in a
        switchover will smoothly find the new primary then. 
      * switchover itself. When you perform a switchover, this inserts
        an End-of-Redo marker in the redo stream. The standby database
        (both of them!) will switch to a 'switchover pending' state. The
        standby database that is becoming primary can handle this
        perfectly. The 'not involved' standby however will never
        discover there is a new primary and will sit in this 'switchover
        pending' state forever. Solution: shutdown the standby, create a
        new standby controlfile at the (new) primary, copy it to the not
        involved standby replacing its previous controlfile, and let it
        resume the managed recovery.
      * Don't forget to take advantage of the DELAY feature at the DR
      * I prefer to set up a database with a minimum size at the primary
        server, and create standbys of that database. I use a SID of
        DGT, Data Guard Test, most of the times for this purpose. This
        allows the DBA to test the whole stack, including firewalls and
        so on, without faking anything. Using that database to practice
        switchovers, failovers, (re-)instantiations and so on
        contributes a lot to swlf confidence.

A setup like this isn't too cumbersome. Normally (on non-Windows
systems) it takes 2,5 - 4 days to do the whole setup, including test
environment and knowledge transfer. I use scripts (ksh, sql).

I'm preparing the DG special I'm gonna teach for OU, and writing a white
paper that covers this topic. Part of it might be available at RMOUG
training days in February. On the pre-training days afternoon I'll
present a 4-hour 'University session' about DG.

Best regards,

Carel-Jan Engel

If you think education is expensive, try ignorance. (Derek Bok)

> Dick Goulet, Senior Oracle DBA
> 45 Bartlett St  Marlborough, Ma 01752, USA
> Tel.: 598.573.1978 |Fax:  508.229.2019 | Cell:508.742.5795
> RGoulet@xxxxxxxxxx
> ______________________________________________________________________
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mark Strickland
> Sent: Monday, January 15, 2007 3:09 PM
> To: Brandon.Allen@xxxxxxxxxxx
> Cc: Richard J. Goulet; oracle-l@xxxxxxxxxxxxx
> Subject: Re: DataGuard
> I setup a (now cascaded standby configuration with
> Primary --> Physical Standby --> Logical Standby.  Data Guard still
> chose to ship the archived logs directly from the Primary to the
> Logical Standby even though I did what the documentation directed
> AFAIK.  The cascaded approach wasn't a must-have for me and I didn't
> spend any more time trying to figure out why DG did what it did. 
> Mark Strickland
> Seattle, WA 
> On 1/15/07, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote:  
>         Never done it, but I think what you are looking for is
>         officially termed "Cascading Standby" or "Cascading Redo Log
>         Destinations" and is documented here:
>         HTH,
>         Brandon
>         Privileged/Confidential Information may be contained in this
>         message or attachments hereto. Please advise immediately if
>         you or your employer do not consent to Internet email for
>         messages of this kind. Opinions, conclusions and other
>         information in this message that do not relate to the official
>         business of this company shall be understood as neither given
>         nor endorsed by it. 

GIF image

Other related posts: