July 5, 2011 at 5:03 am
Hi,
Well, unless you can get some downtime, I'm not sure you are going avoid losing some records..but i could be wrong.
You will need to remove the table from the publication and then apply the schema changes and republish. Then push out a new snapshot of those tables. You can check which site has the most records and use that as the republished data.
But unless you stop data updates...it's going to be tricky to avoid data loss.
Can you temporarily direct the remote users to the publisher so updating is only happening in one place ?
How big are the tables ?
Graeme
July 5, 2011 at 8:56 am
thanks for your reply.
I talked with the client yesterday and we came up with a plan. I will stop the replication and the client give me a window where production will also be stop at the subscribers sites, but not at the publisher's (the main production plant). I apply all the changes to the "master" database and restart the replication. This way, all data from the publisher will be replicated to the subscribers and no data will be lost, am I right?
By stopping the replication, do I have to completly delete it and recreate it, or there is a "stop/start" function that will let me modify the design of some tables?
thanks!
July 6, 2011 at 8:02 am
You'll want to stop replication - stop the log reader agent job.
Then remove the tables, the ones that you need to alter, from replication.
Make your table altercations on the publisher.
Then re-add the tables to your replication.
Start the snapshot agent job - it should only need to resnapshot the altered tables.
Then restart the log reader agent job.
The only downtime on the publisher should be while you're altering the tables.
July 6, 2011 at 11:03 am
ok, l'Ill try that!
thanks a lot for your help!
Viewing 4 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply