Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

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

This question already has an answer here:

I have a SQL Server 2008 instance and one table is quite large (log data) so I delete old logs. Now I start to read articles on this problem, here is one.

As I see it there is no solution! If I shrink the database and then rebuild the index, the database will be about the same size as before. If I don't rebuild the index, the database will shrink, but performance will be low, which is not an option.

So shrinking for production databases seems not to be an option. Is there any solution? Does deleting from the database make any sense? How do big companies delete log data from their databases?

share|improve this question

marked as duplicate by Mike Walsh, Max Vernon, Mark Storey-Smith, Paul White, ypercubeᵀᴹ Nov 24 '13 at 12:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Why do you need to shrink the file? Rebuilding the CI after a massive delete (without shrinking the file) will help make those pages available for future data. Shrinking the file just means it has to grow again when you add more data. So there was no benefit to shrinking it in the meantime - ooh, you freed up some space, but only temporarily.

Another thing you should look at is table partitioning (depending on SQL Server edition). It can make disposing of old data much, much easier.

share|improve this answer

Big companies never shrink the database files - and the logs reuse space after a log backup.

Basically, shrink / grow is for low performance. You want performance, you initialize files for a specific planned size, then resize when you need more manually. You MAY use "emergency autogrow" but you do NOT shrink. What for? I mean, seriously. I ahve a small (400 gb right now) database and it lives in DEDICATED DISCS to get performance - I would gain nothing from shrinking. In fact, I am expanding it once I get the next set of discs (on shipment) and I Do that manually.

Same with logs. They live on their own dedicated discs. They are preinitialized for a size I am comfortable with. I do not shrink them - what for?

share|improve this answer

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