Comments on: Shrinking databases

By: GONZI

GONZI — Tue, 07 Feb 2012 09:31:51 +0000

Hi Gail,

wow thanks for the fast reply
No i didn´t consider using a 3rd party tool that creates compresed backups, because i designed 3 Maintenance Plans doing FULL/DIFF/TRN backups.
I really have to check the performance while doing the restore …. because (as i said) the bak File is compressed and should be fast, there should be something wiht the Server.
I am going to check the Performance and write back.

Thanks for the Feedback!
greetings
GONZI

By: Gail

Gail — Tue, 07 Feb 2012 08:36:12 +0000

I don’t recommend keeping databases as small as possible, it’s inefficient causing SQL to grow DBs more often than it should and has a whole set of issues.

If a 40GB backup takes an hour, I suggest checking the performance and throughput of the IO subsystem, I have before backed a 1TB database up in 10 hours uncompressed, 4 hours compressed.

Shrinking the DB before backup won’t reduce the size of the backup or the time the backup takes, because a backup does not include empty space within the data file.

Have you considered a 3rd party tool that creates compressed backups?

By: GONZI

GONZI — Tue, 07 Feb 2012 08:31:13 +0000

so what do you recommend, for keeping the DB as small as possible? I have to restore a 40 GB big Database and it takes more than one hour (i even compressed the bak File).

I thought shrinking the data Files before i make my Backup, would speed up the restore afterwards!

thanks in advance

By: Gail

Gail — Mon, 27 Dec 2010 22:33:17 +0000

Maybe take this to a a forum (like SSC)? Blog comments not really the place to help out on a complex problem

By: Shaun

Shaun — Mon, 27 Dec 2010 21:53:57 +0000

Yeah, don’t think it’s that. Used his script and don’t see any ghost processing going on. Doing some more digging. Narrowed the growth down to a couple of filegroups which only contain indexes – and not ones on the created/dropped tables. Seeing some highly fragmented indexes there but not sure why that would cause file growth with empty space. Pages are fragmented, but pretty full. Will have to dig some more. Thanks for your help!

By: Gail

Gail — Mon, 27 Dec 2010 21:29:30 +0000

Could be that the ghost cleanup’s not keeping up with the deallocation of the pages. Drops complete immediatly, pages are deallocated in the background afterwards.

Some stuff on Paul Randal’s blog on ghost cleanup.

By: Shaun

Shaun — Mon, 27 Dec 2010 20:57:55 +0000

Interesting. I have a db where tables are created and deleted very frequently – like every minute or two. DB size kept growing. 60 GB db with 20 GB free space, yet the OS file size kept increasing (as did the free space). I’ll be blogging about it in a couple weeks.

By: Gail

Gail — Mon, 27 Dec 2010 17:00:16 +0000

SQL can and does reuse the space that was made available by dropping tables.

What it won’t do automatically is release that space to the OS. That’s what shrinking does, and you don’t have to do it, in most cases you shouldn’t do it.

By: Shaun

Shaun — Mon, 27 Dec 2010 16:44:08 +0000

Any idea why SQL can’t reuse the space used by tables that were created then dropped and we have to shrink the DB instead?

By: Jason

Jason — Tue, 28 Sep 2010 21:03:45 +0000

Auto-shrink is default off. Just logically thinking auto-growth is default on, definitely auto-shrink should be off. You should index defrag no matter you shrink or not. There are times shrink makes huge sense especially when you see the sapce removed is not coming back. Run index defrag after shrink, not before shrink. When I shrink, depending on scenario, I always shrink to extra 20% (automatic script generation) and I always know it is not the space that going to immediately grow back. Run shrink before index rebuild/reorg. When you have unlimited space, you don’t even need to shrink. We lease space so I am saving company money by maintaining a good balance.