On proper care and feeding of content databases

This one will be quick.

Good SharePoint administrators know not to let their databases autogrow. (Note that this is not the same thing as saying "turn off autogrowth"!)

Good SharePoint administrators also know not to grow their databases during regular hours. (The mysterious "w" at SQLTact does a fabulous job of explaining why.)

Presumably, good SharePoint administrators also know not to do large-scale emptying of the recycle bin during regular hours.

I suppose this means I'm not a good SharePoint administrator...because I didn't know about this until just now!

I moved a project site into its own site collection last week as part of a broader effort to try and partition our monolithic SharePoint environment. That went fairly well, and I deleted the original site, but in looking at my space reporting this morning, I see that egads-We only have 2.5 GB free in the root content database! It's growing even faster than I had planned for. I ask myself..."Did I forget to empty the second-stage recycle bin in order to dispose of the deleted site?"

Apparently I did. So, I proceed to clean out my contributions to the bitbucket. Now I see free space is ticking back up in the database, so that's good to see.

However...the DB appears to be locked during this operation, and so now our main site won't load anymore. Yikes! And I can't exactly stop it, lest I break something in the process of trying to get the site to respond again. Thankfully I know ahead of time that this content is about 10 GB, and I can tell when the deletions will finish based on that figure, so it's almost over.