Creating Corrupted SharePoint Sites - How it Happens

Corruption is definitely a problem. Often it can be prevented by simply following operational processes and best practices such as using drainstop or draining connections before rebooting a server or cycling a service. SQL DBAs would know you should never simply turn off SQL. First you’d bleed the connections and watching the processes bleed down to prevent corruption in the databases. In this same way you should pay attention to what’s going on before cycling your servers or service. You notice a long running and blocking worker process so you kill it… was it search or was it a create or large list deletion?

Here’s 5 Ways to Create Corruption & Orphans


  1. Delete a site and kill the SQL Process ID or cycle the SQL Service before delete has succeeded.
  2. Create a site then cycle IIS before it’s created
  3. Create 2 databases run an STSADM backup command then restore it, command to a different database then disconect all the databases and reconnect them. (May not work depending on service pack you’re running)
  4. Run an STSADM Restore and kill the process
  5. Delete and kill the worker process
  6. Some may work better than others, but you get the idea. You can also see how simple operational procedures could result in corruption. On an operational basis you might consider drainstop when using NLB or simply bleeding off connections in a network load balancing environment to avoid orphans from being created. I’ve met a few people who says they’ve never seen one. That’s great! There are many who get these more often than they should. Some of those are from restores and renames and reconnected databases.


On my other blog I put together a post on both identifying and deleting corrupted SharePoint sites also known as orphans.