Sql-server – Restoring data into a replicated table after failed purge process

sql serversql-server-2008sql-server-2008-r2transactional-replication

We have a monthly purge process that purges data from a few tables using a somewhat complex SSIS package.

Up until this time everything is running smooth and fine without any issues.

However, if the purge process does fail then my only resort would be to restore those tables back to the state they were in before the purge stated. We take backups of the affected tables before we start purging data, however my concern is these tables are in replication and in case if I have to restore the data back do I need to just use import/export or insert into and get done with it or do I need to remove the table out of replication, add the data and then add the table back and generate a snapshot for these articles only?

What if I want to restore the complete table. How am I suppose to do it when the tables are part of transactional replication?

Best Answer

I'm going to assume the table in question is a replication publisher, not a replication subscriber (since you shouldn't be changing data in table that has been replicated from another source).

While you can just delete and then re-insert all the fixed data on a replicated table, if it is large enough that's going to generate tons of commands to replicate over to the subscriber, which (in environments I've worked in) may take hours or days to sync across.

So it is usually much easier to:

  1. Remove the table from replication
  2. Fix the table data, via bulk inserts or updates or SSIS or however you want
  3. Re-add the table to replication
  4. Do not re-initialize the subscription (you just want to snapshot that one table, not the whole database)
  5. Run the snapshot job. It will push a snapshot of just the newly re-added table.
  6. Run the distribution job

One further note: if you have already clogged up your replication with 100 million pending delete/insert/update commands, you can still execute these same 6 steps. The moment you remove the table from replication, all those pending records for that table will disappear from the queue, this usually happens very quickly and will cause a bogged-down subscriber to spring back to life.