Re: Help required on Data Guard

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<41acfa8e$0$20379$afc38c87_at_news.optusnet.com.au>...
> Joel Garry wrote:
>
> > Well of course I was oversimplifying for the OP, but I didn't say the
> > files were copied over. Your quibble is correct. But they do wind up
> > there, right?
>
>
> Well, it depends how quibbly you want to get! No, they don't at the

Hey, this is usenet! :-)

> highest level of quibblesomeness. A *facsimile* of them ends up on the
> remote database. A *replica* of them. A *clone*, perhaps. Call it what
> you will. But "they" don't actually move or get moved *themselves*...

But of course, you could have brought up the logical v physical options, thank you for being nice.

>
> But yes, I know what you meant.
>
> If your original sentence had been "Data Guard uses redo to replicate
> transactions" I wouldn't have quibbled in the slightest.

For the benefit of the OP:

A nice picture of one architecture in 10g: http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10823/log_apply.htm#1021538

http://www.oracle.com/technology/deploy/availability/pdf/MAA_DG_NetBestPrac.pdf (esp Appendix F) http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP.pdf (or go to metalink and find the list of dataguard white papers).

And we can all impatiently tap our collective feet until they put up some 10 stuff.

>
> >I have to be careful about talking about FAL, because
> > I'll start ranting about how it doesn't work the way one would hope,
> > ie, up until latter-day 9i's, a network error can kick back through
> > the FAL process and stuff your production instance bigtime.
>
> Entirely agree. I think we've had this discussion before: I tell people
> how it's supposed to work. I leave the minor buggy nigglies to their own
> practical experience and their ability to read Metalink.

Knowing how it is supposed to work is very valuable!

jg

--
@home.com is bogus.
http://www.signonsandiego.com/uniontrib/20041201/news_1b1fugitive.html