Replication [Archive]

Step

01-24-02, 04:31

Hello!

>If for example, i have replicated data from one site A to another B, B >and A both have a same copy of data now. B will now be able to >access this set of data locally. However, how is B going to update the >data back to A, in order to maintain the consistency of data. What if in >he meantime when B is holding these data and has updated them, A >has also update the same set of data?

If I'm right, you are referring to a MS SQL Server terminology, so I'll
answer your question as if concerning MSSQL. Well... If you want to
replicate from A to B, and also B to A, the best practice is I think to
implement a transactional replication. The changes are propagated in
real time. But if it can happen that A and B are updating the same
data locally, and then it needs to be cross-replicated, you would have
to implement Merge replication, for it has a good logic for solving
conflicts (e.g. by latest timestamp).

>Does using updatetable snapshot replication allows B to update the >data directly to A. If this is so, will it defeat the purpose of replicating >data to local DB for better performance?

I wouldn't suggest the snapshot replication, because it takes pretty
much of a system resources and it works pretty slow.

>Another question that i have is: eg, i have a company with some data, >it wants to distribute the data to different branches, however the set of >data to be distributed to each branch is diiferent, say, data A to branch >A, data B to branch B. Should i say that the company is replicating >data to each individual branch or should i say that the company is >fragmenting the data to different branches?

Perhaps fragmenting sounds good. But if it is on recurring (daily, weekly)
base and data is being updated at branch offices, then I'd call it replicating.:cool:

Manish

01-24-02, 21:39

Originally posted by Step
If I'm right, you are referring to a MS SQL Server terminology, so I'll
answer your question as if concerning MSSQL. Well... If you want to
replicate from A to B, and also B to A, the best practice is I think to
implement a transactional replication. The changes are propagated in
real time. But if it can happen that A and B are updating the same
data locally, and then it needs to be cross-replicated, you would have
to implement Merge replication, for it has a good logic for solving
conflicts (e.g. by latest timestamp).

:)

Good advice you have put up there.

venetta, if you have situation where both the sites A and B are modifying the same data, then you might want to take a look at the "frequency" of these "common updates".

If the sites are updating the same data infrquently, then Primary Site Asynchronous Replication (transaction replication as termed by Step) can be utilized, where the secondary copies of data is not updated. The users first publish the relation to the primary site, and then get the updates at secondary site.

If the "common updates" are fequent, then you can't afford to have the above type of replication, given the delay and performance factors. The best bet then is to go for a Peer-to-Peer Replication method (Merge replication as termed by Step), where both copies can be updated, and there exists a conflict resolution strategy to decide which entry should go finally in both databases. (note that there is a LOT to ponder about this strategy instead of just timestamps, because you may have a scenario where the updates at both the sites contain information that cannot be discarded).

:)