December 19, 2005 at 10:45 pm
Hi,
I have a situation that is new to us where I have a new location that we need to perform replication to. It is our new site in Germany and I need to replicate our DB in NY out there. I wanted to know;
A) What do I need to consider when picking a methodology for replication
B) What happens in a scenario where I lose communications to Germany for a length of time, can NY and Germany still operate without replication going and if so what happens to those records that are being processed in both sites while we have lost the communication.
Any help and guidance is much appreciated.
December 20, 2005 at 10:31 am
hi, It depends on the situation. If you have static DB structure then you should go for simple pull Merge Agents. with daily replication.
If you have frequent changes in your DB Schema, then you should go both. the merge agents and Snapshot replication as well.
but if you would provide some more details about the database schema and its nature, like static or dynamic. etc. then will be able to give more details.
Thanks may be that will help you at some extent.
December 20, 2005 at 1:58 pm
Hi,
The DB schema for the most part should stay static except for the occasional mods/adds of sp's. Can you explain why this is a consideration?
Also, can you explain to me a little on what happens when and if we had a communication breakdown and replication stops for a temporary amount of time. If changes are still occurring locally what happens to keys/ids in the database? Do transactions get queued up in logs until replication begins again? Sorry for the questions but I am thinking that there are many considerations in a scenario like mine.
Thanks again...
December 21, 2005 at 5:37 am
Use Merge Replication
Both sites can continue working if there is a communication breakdown. Transactions are written to replication tables/conflict tables.
In the "Snapshot Properties", there is an expiration setting for dropping the "Subscription" if it is not synchronized within xx number of days. The default setting is 14 days, but you can change this setting.
As far as the PK's, if during the setup of replication, you chose to let SQL Server handle "Identity Range Management", then you should be fine with the IDENTITY SEED columns. If you chose not to then you'll have many conflicts, unless you have your own identity management in-place. There are many different techniques for this, so I won't elaborate at this time.
NOTE: Merge replication is a replication methodology which needs to be discussed/planned for during the application design phase for at the very least these considerations.
1. A rowguid column is added to every table which will be replicated. This means the application code would need to ensure that a developer isn't doing a "Select * from ..." and populating a datagrid, then complaining about having this rowguid column. Of course, they can handle this in their code, but it needs to be mentioned.
2. Inserting new rows. If you are using identity seeds as the PK to your tables then you'll have to make considerations for how to handle the ranging, as I alluded to above. If not, then you'll need the application code to handle inserts without causing problems. This might mean that you'll need 2 versions of your application, or the developers will need to determine which server they're running on and then handle the "Inserts" accordingly, or etc...
3. The point is replication isn't something that can just be turned on/off at a whim, at least TRANSACTIONAL or MERGE replication cannot. It will take a lot of planning and probably application coding changes.
Steve
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply