var sidebar_align = 'right';
var content_container_margin = parseInt('290px');
var sidebar_width = parseInt('270px');
Unanswered: Delete Data without impacting Tempdb
This is a SQL 2005 production server.
I have to delete around 51 million rows from a table which has 149 million rows.
Can't use truncate option as the other rows in the table are still needed.
How can I delete the rows without filling up the tempdb ?
If the tempdb fills up I can't bounce the server.
Set your recovery mode to Simple so you don't log all the deletes. Consider deleting your data in smaller batches.
I've been doing this exact thing for the past week, and did exactly that.
Just remember to defrag/rebuild indexes following this.
tempdb? maybe you need to check whether you are trying to support snapshot isolation. In that case, the deleted rows will end up in tempdb prior to the commit.
The recovery mode is "simple". Its still putting all the transaction in the log file.
The Tempdb detail was an error from my side.
in that case, simply break the delete down into smaller chunks. The entire delete will always be logged. So instead of one big delete, make it 10 smaller deletes.
thanks for all the responses.
The only solution seems to delete in small batches and then truncate the log.
You should not need to truncate the log in simple recovery mode.
Somehow it seems that some of the transaction log keeps getting held after large transactions. I find running checkpoint in the affected database brings things back in line. Checkpoint is also a side effect of truncating the log.
That is exactly the issue I have. I have to truncate the log after doing the large delete inspite of recovery mode simple.
After your done truncate with no_log and dbcc shrinkfile it back down.
Bear in mind if you are performing this delete operation during normal day time it will have stress on tempdb too in addition to user database's transaction log.
So better to perform this operation during less traffic hours and also perform CHECKPOINT after couple of thousand rows to keep up the log size.