Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Replication Scenario


Replication Scenario

Author
Message
Renju
Renju
Forum Newbie
Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)

Group: General Forum Members
Points: 2 Visits: 30
Hi all,

Am a newbie into SQL 2008 R2 Replication.

My requirement is as follows.

We have differrent branches in differrent cities and each branch has an SQL Server with a Database specific for that branch. In the HeadQuarters we have a central DB to which the branch DB's should copy the data.

So in the end if table1 in BranchA database has 5 rows and table1 in BranchB database has 4 rows. After replication the centralDB table1 should contain 10 rows..

Is this scenario possible with replication?

If yes which one I have to use

I have gone through some books online and websites and I tried with those samples. But my centralDB got replicated by only 5 rows..

Can anyone help me to find a solution with which server to be the Distributor,WHich one to be the Publisher and which one to be the publisher..

Thanks and Regards

Renju
happycat59
happycat59
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3563 Visits: 3101
I assume that each site is responsible for the creation of the records in table1 and that all of the records in question (at both remote sites) are intended to be unique. If you want to replicate these to a single database you need to think about how you would identify each of the records when they arrive at the central database (the subscriber).

If, for instance, both publishers use the same values for their primary keys (e.g. IDENTITY (1, 1) at both databases), when you send data to the central subscriber, you will end up with errors (duplicates on INSERT) for the second record to attempt to use a key value or, if configure replication to ignore these errors, the second INSERT will fail and result in no further action. The result of this would be just the 5 records you are seeing

Ideally, you would change the primary keys so that each site uses a unique set of keys. You could use different IDENTITY ranges for each source table or add another column that identifies the source. There are many ways to achieve this but if you don't, you will run into problems.



Renju
Renju
Forum Newbie
Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)

Group: General Forum Members
Points: 2 Visits: 30
Happycat,

Thanks for the reply.As you have mentioned, we are using the identity(1,1) in our table.but each row has a foreign key branchid which will be unique for each database, say for DatabaseA is 1 and DatabaseB its 2 and so on..

Also if we try the merge replication, it will add the rowguid column too..Is that ok?

can you shed some more light into this?

Thanks in advance

Renju
MissTippsInOz
MissTippsInOz
SSC Veteran
SSC Veteran (289 reputation)SSC Veteran (289 reputation)SSC Veteran (289 reputation)SSC Veteran (289 reputation)SSC Veteran (289 reputation)SSC Veteran (289 reputation)SSC Veteran (289 reputation)SSC Veteran (289 reputation)

Group: General Forum Members
Points: 289 Visits: 597
Sounds like you have your partitioning covered by your natural, 'branchID' key so that's fine.

Each of your branches will be a publisher and can also be its own distributor.

I have a suspicion that the reason you have only 5 rows at the subscriber, despite pushing out two sets of data from your publishers is that you have not reconfigured the properties of the article from their default. The default behaviour of the 'Action if name is in use' property, at the Destination is 'Drop existing object and create a new one'. So what I envisage happened is that your first publication was pushed out successfully, then the second one came along, dropped the existing table with your ?4 rows in it, created a new table and populated it with 5?

Clare
_________________________________________________________________________________________________________________
Measure twice; cut once (and have a good saw)

Hey, just a thought.....did you check Books Online yet?
happycat59
happycat59
Hall of Fame
Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)Hall of Fame (3.6K reputation)

Group: General Forum Members
Points: 3563 Visits: 3101
I agree with Clare - perhaps initialising the second subscription removed all trace of the first.

As for the Identity and BranchID - that is fine PROVIDED that you declare the combination of these 2 columns as the primary key. This is what transactional replication will use to determine what to update/insert/delete. I am not sure that it makes sense to have the identity property on the subscriber - I have never tried it but it seems to me that you normally expect one and only one record with a value for this column. You would end up with 2 or more - not sure that SQL Server will be all that happy with this. You might need to test this (especially check what reseeding does for this table on the subscriber).

As for merge replication, you still need a primary key. Merge also needs a rowguid column. Whilst this would be unique, it may or may not be the primary key. That is up to you. The same issue with identity would exist. Merge could work.

I have implemented solutions with both merge and transactional replication in similar environments in the past and they work quite well. The only difference between those and yours is that instead of identity, we generated the key values (using something similar to the branchid plus a sequence number).



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search