Look in the Best Practices section of http://msdn.microsoft.com/en-us/library/ms190488.aspx that I put in when I owned the Storage Engine. Only reason shrink is still that way is that I never had time to rewrite it.

OK, I’m convinced. I’ve removed all the Shrink database statements from all my maintenance plans. And when I check the DMV, I see that the indexes are indeed horribly fragmented.

Now I have a problem. My senior DBA says I should leave well alone – no-one is complaining and if it ain’t broke, I shouldn’t try to fix it. Plus unless Microsoft says that Shrink Database is a bad idea, he doesn’t believe it. Can you point me to a MSDN source to back yourself up?

It’s not just space at the end of the file that will be left out, it’s unused extents anywhere in the file. Only way you’ll get space saving in a backup after a shrink is if you have lots and lots and lots of partially allocated extents (blocks of 8 pages with < 8 pages used by the table).

Between the shrink and the index rebuild that you need to do after, you're probably spending more time doing the backup than if you just backed up normally.

Do you mean that it reclaims empty pages from extents, thus compacting the table/index? Yes, it will do this, but at the expense of causing horrible index fragmentation.

To address another point – a backup not only does not include empty space at the end of the file, it also does not include unallocated extents spread throughout the file. An extent is only included in a backup if one or more pages in the extent are allocated.

Thanks

I cant get my infrastructure guy to spring for litespeed and 2008 is still a year a way for us, so no I dont the benifit of streaming compression during the backups. Instead there are ugly scripts that gunzip them after the backups are complete. =(

You are correct in that a backup does not include the empty space at the end of the file. That is true. But after large deletes where free space is now scattered over mixed data pages, only a shrindb will free this space. And without it , yes your backup is larger.

“I’ve also used it after partitioning to reduce the size of backups.”

I’m curious – do you use any backup compression products like LiteSpeed? If so, they don’t back up empty space in the database, so it won’t matter whether the database is shrunk or not – the backup will still be the same size. I haven’t done a native backup of a large database in quite a while, so I’m not even sure if this is true with native backups either.