Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a large table in MS SQL that I am having issues reading from while a third party application writes to it. My plan to resolve the problem is to move all of the data from one database and delete the data in the source database periodically. The problem arises when the table has too much data ( hundreds of millions of rows), but I need to be able to read all of the data for a rows which could top a billion rows. I don't have the ability to modify the source database because it is third party.

I'm curious what some options might be to help facilitate this. Is it possible to replicate a table in a way that when I delete the data in the source table, it's not deleted in the destination table?

share|improve this question

There are a number of potential solutions to this problem. Picking the right one is dependent on your environment and your requirements, which aren't flushed out in much detail here.

Based on your stated need to query the entirety of the multimillion (or billion) row table, I expect that you need to do some reporting on from the vendors' database. Here are some potential solutions that I would consider to meet that goal:

  • READ UNCOMMITTED: Execute your queries as READ UNCOMMITTED (e.g. WITH NOLOCK). This will ensure that the queries and the OLTP activities are not interfering with one another, though your results may get a little dirty if you're querying up-to-the-second data.
  • Snapshots: Create database snapshots for read-only queries. Refresh them on a regular schedule, or prior to running the reports (if they are ad hoc). If reporting performance is the only reason you want to clear the data out of the table, this might be your best solution.
  • ETL: Create an _Archive database on the same server containing the required table(s). Populate them from the prod DB with a daily/weekly/monthly archiving job that moves data into it from the prod DB, then deletes from prod after the insert is successful.

A little more information might help us to better assist you.

share|improve this answer

THe standard approahc is to use an ETL script of some kind to make a copy of the data prior to deletion.

share|improve this answer
  • Insert triggers that copy every new entry on creation
  • Scripts run at regular intervals or before deletion that insert non-duplicate rows.

There's no reason that your data warehouse tables need to even be on the same server, much less tied to the live database with constraints. Deletion shouldn't affect the warehouse. Just have commands that add data.

share|improve this answer
I can't modify the source database, so adding triggers is not an option. – scottm Jun 8 '12 at 14:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.