Re: Geographically distant DBs.

Re: Geographically distant DBs.

 

  

What you need is replication
Multimaster replication is OK, but if you have star schema (one main
server and many slave servers) you can go for master-to-snapshot. It is
easier to setup and maintain, all conflicts occur only at the master
server, etc.
If you can afford read-only database on the remote servers,
master-to-(readonly snapshot) is your definite choice. It has less
maintenance and network traffic.

Rgds,
Yavor

Dan Rossi wrote:

>Hi folks,
>
>So, yesterday I asked about this question and got a response. I had asked
>if RAC would be an option for allowing a distant remote site to have fast
>access to data. Obviously, I didn't have much of a clue about RAC. RAC
>seems to indicate that you have multiple servers connected via a dedicated
>wire to a central disk array. Since we cannot have this dedicated wire,
>RAC won't work.
>
>Unfortunately, I am getting questions from people who are not giving me
>the entire story at one time, so I've been a bit confused about the
>parameters of my questions here.
>
>People are worried about network latency with a prospective remote site.
>They feel that a DB server at the remote site, with the same data that is
>here locally, is great because it eliminates network latency. OK, so
>replication sounds like a possibility. But what is a reasonable
>estimation for lag time between the primary DB and the replica. IE, do
>you want fast access to slightly stale data, or slower access to fresh
>data.
>
>The other complicating factor, I just found out, is that this wouldn't be
>just a replica thing. They would want the remote site to be able to
>interact and change data in the DB. So, changes would have to flow in
>both directions, from primary to replica and replica to primary. Is this
>possible?
>
>I guess, in theory, they could request data from their local replica, but
>changes would be sent back to the primary DB and not made on the local
>replica. But, that then begs the question, if they make a change on the
>primary, how long will it take before the change gets back to their
>replica?..
>
>Does any of this make sense? My apologies for my confusion on this issue.
>Just lack of experience with the "not day to day" db stuff that I usually
>deal with.
>
>Thanks very much for any assistance.
>
>
>
>


Oracle LazyDBA home page