Shrinking Databases

Every time you shrink a database, an angel gets its wings torn off. Or Paul Randal feels a disturbance in The Force. In other words, don’t do it.

But people continually do shrink databases. Despite the constant advice and guidance from Microsoft, MVPs, and more, the fact that shrink is available easily in maintenance plans and with a DBCC command, people do it. I understand it since it’s natural to not waste space and so many other tools, like Access and Outlook, have files that only use the spaced needed.  Why not SQL Server?

It’s Friday, and I thought I might see if there might be a oslution tht makes sense. For this poll, I want to ask you about shrink:

Should shrink be removed or fixed?

By removed, I don’t mean completely take it out of SQL Server, but make it harder. Maybe require a trace flag, maybe something else that might reduce the regularity with which it’s run. I’d certainly recommend it be completely removed from maintenance plans, both the wizard and the designer.

Is there a better solution, however? Should perhaps shrink be fixed to be a more intelligent operation that doesn’t cause lots of fragmentation? Even if it’s slower, or maybe an operation that requires more resources to complete, would it be better to actually “fix” shrink?

Put your answers in the discussion and let us know what you think

Steve Jones

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , , . Bookmark the permalink.