SQLServerCentral Editorial

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

The Voice of the DBA Podcasts

Everyday Jones

The podcast feeds are available at sqlservercentral.mevio.com. You can also follow Steve Jones on Twitter:

Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.