RE: Synchronizing database data - intercontinental dependencies...

Regarding the term "instable" lines.  

The customer guessed that a temporary lack, regarding data synchronization, could occur in terms of some minutes upto 1 hour, although I can not confirm or deny this because of my lack in these kinds of international data transport and the problems involved.  

Thanks for the food of thought and new insights on this matter are welcome  

Regards    

Marco

From: Nigel Thomas [mailto:nigel_cl_thomas_at_yahoo.com] Sent: woensdag 13 februari 2008 15:15
To: Marco Gralike; oracle-l_at_freelists.org Subject: Re: Synchronizing database data - intercontinental dependencies...

Marcus  

Multi-master replication is a bitch (logically as well as technically). Ideally you want to know where / when data is updated; and if possible have a single master for each row, or at least a well understood conflict resolution policy.  

Oracle Advanced Replication (now Oracle Streams Replication
<http://www.oracle.com/technology/products/dataint/index.html> ) was
intended (starting while I was still at Oracle - so well over a decade ago) to solve this problem. Not sure if it has yet, and certainly Streams seems to appear as the culprit in many posts here and on the OTN forums. See also OraFaq's (short) list of questions
<http://www.orafaq.com/faq/what_questions_should_one_ask_before_implemen
ting_advanced_replication> . However it should be easier to manage replication if all the sites have the same schema (watch out for application upgrade issues!).  

You could do worse than than look at Hibernate Shards
<http://www.hibernate.org/414.html> - not actually to use it, but to
pick up on some of the issues in the Reference Manual
<http://www.hibernate.org/hib_docs/shards/reference/en/html/> .
 

Remember in your case, you can always master some data in NL and some in Taiwan... so your factory "owns" its own production data (and NL sees a replica of that) while NL "owns" (for example) the product BOM.  

All needs very careful data analysis to understand who needs the data, when, and what for; what might happen if updates are delayed (a day or a week); what's the cost and risk of working with out of date data. The "urgency" of data may vary by table, by row and by column (with complex interdependencies).  

I did some work with Nokia Finland 14 or 15 years ago where they were replicating data to some remote offices (eg, in those days, Beijing) via floppy discs. Not ideal, but it worked for them ... because they understood how to handle the (postal or courier) "network latency" involved. No different to synchronising your Palm with your Outlook really :)  

Anyway - good luck!  

Regards Nigel  

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