RE: DataGuard

Dick,

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 charm!

Stay away from cascaded redo transport as far as you can. You simply don't want that in HA environments. As Miracleas.dk 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 setup.

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 site.
• 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_at_kanbay.com
>
> : POWERING TRANSFORMATION
>
>
>
>
>
>
>
> ______________________________________________________________________
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark Strickland
> Sent: Monday, January 15, 2007 3:09 PM
> To: Brandon.Allen_at_oneneck.com
> Cc: Richard J. Goulet; oracle-l_at_freelists.org
> Subject: Re: DataGuard
>
>
>
> I setup a 10.1.0.3 (now 10.1.0.5) 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_at_oneneck.com> 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:
>
> http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96653/cascade_appx.htm
>
> 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.
>

--
http://www.freelists.org/webpage/oracle-l