A Friendly Reminder (Deleting Items From the End User Recycle Bin)

Don't forget - removing items manually from the end user Recycle Bin will lock your Content Database.

If you're deleting a lot of things, that means it will lock your DB for a *while*.

So, unless you have a dire and immediate need for space (in this case, I kinda did), don't do large-scale pruning until off-hours!

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.

SharePoint DB GUID cleanup

With the help of well-publicized articles by Todd Klindt and his bro-crusher Shane Young, I had some admin time today to work on getting my environment set in order. Our Production SP2010 environment was put in place by consultants, which means, amongst other things, databases with long, frilly names.

For reference, see here. (Pictures hosted from the dead SharePoint911 server, go poke Shane about migrating his blog content to Rackspace!)

Shane's article on the Search Service Application DBs indicated that on a vanilla, non-used database, migrating your Crawl Store and Property Store DBs took a base of six minutes. When my databases were going upwards of 25 minutes, I decided to look into it more closely. As it turns out (this isn't entirely unexpected), when SharePoint creates its replacement databases, it ignores the Model DB settings and sets its growth to the agonizing standard of 1 MB increments...and then of course, it proceeds to jam all your old search terms/cache into that DB, one MB at a time.

Save yourself some agony - if you plan to do this yourself, once you apply your changes to the topology, open SQL Server Management Studio and fix the growth settings on both DBs to save yourself present and future headaches.