Re: Expert help

Joel,

It's difficult to give upfront any advice. It's easier to add more questions:
- 80% of transactions, but what is the transaction rate? Several per seconds? A couple per hour?
- Do you really need global vision in near real-time, or do people work mostly on locally generated data?
- You must also bring the application server(s) into the equation. Will there be only one? Where do you intend to put it or them? Is it feasible to cache a part of the data in the application servers? - Do you have an idea about how much redo is generated per unit of time (V$LOG_HISTORY might help)? Is it reasonable to ship it from Florida to Seattle?

 From my experience, even the question of latency is questionable. It really depends on requirements and how everything is coded. If the web server is local and you perform mostly bulk operations, if you manage to inject some asynchronism in your application, operating remotely may work very well. I have no experience of Florida/Washington but I have used SQL*Plus comfortably across the Atlantic more than once. I know of one application where people insert into a Paris database from Paris, London, New York and Hong Kong, and read in NY and HK from a local database where everything is replicated (one-way) by Streams, and so far it works ...

In your options, the one I like least is the dataguard one.

HTH Stéphane Faroult

Joel.Patterson_at_crowley.com wrote:
>
> Hi guys, (gals),
>
> I’m clearly over my head here, so I need some guidance. I’m not asking
> absorb 5 books and 3 years experience via an email chat, but if you
> feel that pointing to particular manuals, or even consultants would
> help please do so.
>
> I have been posed a problem by management whether concerning a J2EE
> project where the database will be designed and modeled, and the
> database(s) architected to best serve the business, based both in
> Florida and Seattle.
>
> 20% of the transactions will occur on the west coast and about 80% on
> the east coast. The initial proposal was to master/master replicate
> two databases. The thinking being that to have one database in Florida
> would be a big slow down for the end user experience due to latency.
> The server to server pipe is prioritized and big, but the end user
> would not at this point enjoy as large a bandwidth.
>
> The later scenario would incorporate Seattle as a data guard failover
> site. The replication idea envisions failover to the surviving
> instance/database.
>
> The question really is which way to go and why, (or another way)!
> Master/Master replication to complicated? Is latency assumed,
> directing attention to replication? Is there a better idea out there?
>

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