March 16, 2018 at 8:35 am
We are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?
Thanks for your help.
March 16, 2018 at 9:04 am
EasyBoy - Friday, March 16, 2018 8:35 AMWe are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?Thanks for your help.
This is how transactional replication works: you set it all up in metadata, then you initialise (which creates and transfers a snapshot of the data from server A to server B and implements it there). After that, only changes are collected from A and implemented at B.
What appears to be the problem?
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
March 16, 2018 at 9:10 am
ChrisM@Work - Friday, March 16, 2018 9:04 AMEasyBoy - Friday, March 16, 2018 8:35 AMWe are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?Thanks for your help.
This is how transactional replication works: you set it all up in metadata, then you initialise (which creates and transfers a snapshot of the data from server A to server B and implements it there). After that, only changes are collected from A and implemented at B.
What appears to be the problem?
We already have articles with data on Subscriber. Let say Article A exist on both publisher and subscriber and both have data with 1000 rows (Subscriber) and 2000 rows (Publisher). So, we need to keep 1000 rows and insert another 1000 rows and any DML changes afterword.
March 16, 2018 at 9:16 am
EasyBoy - Friday, March 16, 2018 9:10 AMChrisM@Work - Friday, March 16, 2018 9:04 AMEasyBoy - Friday, March 16, 2018 8:35 AMWe are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?Thanks for your help.
This is how transactional replication works: you set it all up in metadata, then you initialise (which creates and transfers a snapshot of the data from server A to server B and implements it there). After that, only changes are collected from A and implemented at B.
What appears to be the problem?We already have articles with data on Subscriber. Let say Article A exist on both publisher and subscriber and both have data with 1000 rows (Subscriber) and 2000 rows (Publisher). So, we need to keep 1000 rows and insert another 1000 rows and any DML changes afterword.
From time to time you may have to reinitialise your publications, e.g. if you have DDL changes at the publisher. I reckon you have two choices: either save off the rows on the subscriber before you initialise, or move the rows from the subscriber to the publisher before you start.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
March 16, 2018 at 9:44 am
ChrisM@Work - Friday, March 16, 2018 9:16 AMEasyBoy - Friday, March 16, 2018 9:10 AMChrisM@Work - Friday, March 16, 2018 9:04 AMEasyBoy - Friday, March 16, 2018 8:35 AMWe are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?Thanks for your help.
This is how transactional replication works: you set it all up in metadata, then you initialise (which creates and transfers a snapshot of the data from server A to server B and implements it there). After that, only changes are collected from A and implemented at B.
What appears to be the problem?We already have articles with data on Subscriber. Let say Article A exist on both publisher and subscriber and both have data with 1000 rows (Subscriber) and 2000 rows (Publisher). So, we need to keep 1000 rows and insert another 1000 rows and any DML changes afterword.
From time to time you may have to reinitialise your publications, e.g. if you have DDL changes at the publisher. I reckon you have two choices: either save off the rows on the subscriber before you initialise, or move the rows from the subscriber to the publisher before you start.
I think better way to do is create subscription with do no initialize, sync data on subscriber once and it will be fine afterword.
Thanks for your help.
March 16, 2018 at 9:48 am
EasyBoy - Friday, March 16, 2018 9:44 AMChrisM@Work - Friday, March 16, 2018 9:16 AMEasyBoy - Friday, March 16, 2018 9:10 AMChrisM@Work - Friday, March 16, 2018 9:04 AMEasyBoy - Friday, March 16, 2018 8:35 AMWe are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?Thanks for your help.
This is how transactional replication works: you set it all up in metadata, then you initialise (which creates and transfers a snapshot of the data from server A to server B and implements it there). After that, only changes are collected from A and implemented at B.
What appears to be the problem?We already have articles with data on Subscriber. Let say Article A exist on both publisher and subscriber and both have data with 1000 rows (Subscriber) and 2000 rows (Publisher). So, we need to keep 1000 rows and insert another 1000 rows and any DML changes afterword.
From time to time you may have to reinitialise your publications, e.g. if you have DDL changes at the publisher. I reckon you have two choices: either save off the rows on the subscriber before you initialise, or move the rows from the subscriber to the publisher before you start.
I think better way to do is create subscription with do no initialize, sync data on subscriber once and it will be fine afterword.
Thanks for your help.
I'm not sure what you mean by that. Also, if you ever have to reinitialise (and that's highly likely), you will lose those 1000 rows on the subscriber.
How do you think "sync" works?
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
March 16, 2018 at 10:02 am
ChrisM@Work - Friday, March 16, 2018 9:48 AMEasyBoy - Friday, March 16, 2018 9:44 AMChrisM@Work - Friday, March 16, 2018 9:16 AMEasyBoy - Friday, March 16, 2018 9:10 AMChrisM@Work - Friday, March 16, 2018 9:04 AMEasyBoy - Friday, March 16, 2018 8:35 AMWe are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?Thanks for your help.
This is how transactional replication works: you set it all up in metadata, then you initialise (which creates and transfers a snapshot of the data from server A to server B and implements it there). After that, only changes are collected from A and implemented at B.
What appears to be the problem?We already have articles with data on Subscriber. Let say Article A exist on both publisher and subscriber and both have data with 1000 rows (Subscriber) and 2000 rows (Publisher). So, we need to keep 1000 rows and insert another 1000 rows and any DML changes afterword.
From time to time you may have to reinitialise your publications, e.g. if you have DDL changes at the publisher. I reckon you have two choices: either save off the rows on the subscriber before you initialise, or move the rows from the subscriber to the publisher before you start.
I think better way to do is create subscription with do no initialize, sync data on subscriber once and it will be fine afterword.
Thanks for your help.I'm not sure what you mean by that. Also, if you ever have to reinitialise (and that's highly likely), you will lose those 1000 rows on the subscriber.
How do you think "sync" works?
What i mean to say it, i created subscription with agent schedule: run continuously but Do Not Initialize. Then i sync the 1000 rows manually from publisher to subscriber. Both are in sync now and thereafter if any changes occur on publisher will be replicated to subscriber. I tested with insert, update, delete and it seems working fine.
March 16, 2018 at 10:07 am
EasyBoy - Friday, March 16, 2018 10:02 AMChrisM@Work - Friday, March 16, 2018 9:48 AMEasyBoy - Friday, March 16, 2018 9:44 AMChrisM@Work - Friday, March 16, 2018 9:16 AMEasyBoy - Friday, March 16, 2018 9:10 AMChrisM@Work - Friday, March 16, 2018 9:04 AMEasyBoy - Friday, March 16, 2018 8:35 AMWe are planning to setup transaction replication for few articles between server A and server B. Server A will be Publisher and B will be subscriber. but we need to keep existing data and structure on subscriber (B) at first initialization and after that we can replicate data from A to B. so, how can we implement this process?Thanks for your help.
This is how transactional replication works: you set it all up in metadata, then you initialise (which creates and transfers a snapshot of the data from server A to server B and implements it there). After that, only changes are collected from A and implemented at B.
What appears to be the problem?We already have articles with data on Subscriber. Let say Article A exist on both publisher and subscriber and both have data with 1000 rows (Subscriber) and 2000 rows (Publisher). So, we need to keep 1000 rows and insert another 1000 rows and any DML changes afterword.
From time to time you may have to reinitialise your publications, e.g. if you have DDL changes at the publisher. I reckon you have two choices: either save off the rows on the subscriber before you initialise, or move the rows from the subscriber to the publisher before you start.
I think better way to do is create subscription with do no initialize, sync data on subscriber once and it will be fine afterword.
Thanks for your help.I'm not sure what you mean by that. Also, if you ever have to reinitialise (and that's highly likely), you will lose those 1000 rows on the subscriber.
How do you think "sync" works?What i mean to say it, i created subscription with agent schedule: run continuously but Do Not Initialize. Then i sync the 1000 rows manually from publisher to subscriber. Both are in sync now and thereafter if any changes occur on publisher will be replicated to subscriber. I tested with insert, update, delete and it seems working fine.
If you've tested properly and it's working fine and as you expect, then that's all you need. I still don't understand what you've done, I guess something is lost in translation - or maybe it's just Friday 😉
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply