Database Maintenance Do’s & Dont’s for SharePoint 2010

If you are responsible for a SharePoint Farm or developing things for a SharePoint farm, I bet you’ve heard things like “it’s not supported by Microsoft to do…” and those things mostly dealing with database operations like updating values or settings. But what is about doing administration stuff like defragmentation of indices or shrinking a database?

In this post I try to make some things more clear. My information is based on this technet article, so I was not creative at all. The things I will point out are valid for SharePoint 2010.

Routine database maintenance is essential for the smooth operation of Microsoft SharePoint 2010 databases

That means that we have to do some work on the SQL Server. Microsoft recommends to check database integrity, defragment indexes by reorganizing or rebuilding them as well as set the fill factor for your server.

In SharePoint 2010 the health analyzer evaluate the health of database indexes and statistics daily and reports them at the central administration. But this happens only for some SharePoint databases like

  • Configuration DB
  • Content DBs
  • User Profile Service Application Profile DB
  • User Profile Service Application Social DB
  • Web analytics service application reporting DB
  • Web analytics service application staging DB
  • Word automation services DB

Let’s see what are the details and what you should not do.

Point 1: Consistency Check

This checks ensure that your data and indexes are not corrupted. You can use Database Console Command “CHECKDB” to perform the check.

Do it once per Week on your SP2010 Databases. It’s better not do this operation during production hours, or you do it on a backup, so that the production SharePoint environment is not influenced by this operation.

Point 2: Index fragmentation

Index fragmentation can result in a decrease in performance and inefficient use of space, and indexes might become quickly fragmented on databases that have only moderate use

Microsoft recommends to determine which tables and indexes are most fragmented before implement a index fragmentation plan. In SharePoint 2010 they write, it is often the table AllDocs which becomes fragmented. It contains document libraries. In the technet article is described how to measure the fragmentation.

Recommendation: Always schedule index rebuild activities during periods of low activity.

Reducing fragmentation for a database

SharePoint 2010 offers the health analyzer rules. Those rules can be started from the ribbon by clicking RUN NOW in the central administration Health Analyzer Rules page. These rules evaluate the health of indexes and statistics and they also rebuild and recalculate the index appropriate.

The following databases do not have an automated maintenance mechanism in place. These databases do not typically have much fragmentation. Monitor these databases for fragmentation, and rebuild the indexes in these databases when fragmentation exceeds 30%.

  • Search Administration Database
  • Secure Store Database
  • State Service Database
  • Profile Sync Database
  • Usage Database
  • Managed Metadata Database
  • Business Connectivity Services Database
  • PerformancePoint Services Database


About the fill factor

MS does not recommend that you set the fill factor for individual tables or indexes.

Point 3: Shrinking Database

Shrinking a database causes index fragmentation, so you should not shrink databases regularly, if possible avoid it.

Microsoft offers those guidelines if you have to shrink a databse:

  • Do not use auto-shrink or scheduled shrinking of databases (programmatically)
  • Shrink database only when more than 50% of content is removed
  • Shrink only content databases
  • It is resource-intensive – do not perform this in production-time
  • After shrinking a database reorganize the index

Some “not supported” terms in the use of DBCC:

  • Using the TRUNCATEONLY option is not supported for SharePoint 2010 content databases.
  • Using the EMPTYFILE option is not supported for SharePoint 2010 database files.


If you like to make a maintenance plan look at this Maintenance Plan Wizard.

I would like to close the post with the following summary of the article:

Consistently maintaining the databases that host SharePoint 2010 can significantly improve the health and performance of your system.

Ensure that you have reliable backups for all databases before you implement maintenance operations and maintenance plans.

Before you implement a maintenance plan or specific maintenance operations that run consistently, test the impact of the operations on your system and the time that is required to run them.

As much as possible, set any maintenance operations or maintenance plans to run during off-hours to minimize the performance effect on users.

The article or information provided here represents completely my own personal view & thought. It is recommended to test the content or scripts of the site in the lab, before making use in the production environment & use it completely at your own risk. The articles, scripts, suggestions or tricks published on the site are provided AS-IS with no warranties or guarantees and confers no rights.

About Karsten Schneider 312 Articles
Consultant for Microsoft 365 Applications with a strong focus in Teams, SharePoint Online, OneDrive for Business as well as PowerPlatform with PowerApps, Flow and PowerBI. I provide Workshops for Governance & Security in Office 365 and Development of Solutions in the area of Collaboration and Teamwork based on Microsoft 365 and Azure Cloud Solutions. In his free time he tries to collect tipps and worthy experience in this blog.

1 Trackback / Pingback

  1. Jay

Leave a Reply

Your email address will not be published.