RE: DataGuard
- From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
- To: rgoulet@xxxxxxxxxx
- Date: Tue, 16 Jan 2007 00:12:00 +0100
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@xxxxxxxxxx
>
> : POWERING TRANSFORMATION
>
>
>
>
>
>
>
> ______________________________________________________________________
> 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 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@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:
>
>
> 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.
>
Other related posts:
