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.
