Who's Minding the SharePoint Servers?

Let's not ignore some of those SQL Server instances that have been put into place. First up: what you need to remember about SharePoint.

Many of us who manage SQL Server environments spend a great deal of time being watchful over servers that house main-line applications, such as your online sales system, your credit card system, et al. However, there are often SQL Servers that get forgotten in the mix. Typically, these are SQL Server instances that exist for the sole purpose of a third-party application. In the next few posts, I’d like to point out some of the oft-forgotten SQL Servers, and discuss some specific needs.

As Microsoft Office SharePoint Server and Windows SharePoint Services have matured, they’ve seen much wider acceptance in various organizations. With this comes the inevitable SQL Server instances that support them.

In many cases, SharePoint is installed without the DBA’s knowledge, and the DBA isn’t brought in until there are problems with the supporting SQL Server. Usually this is either because:

  1. the SQL Server instance needs to be moved because it’s taking up too much disk space, or
  2. the SharePoint server has screeched to a halt in terms of performance, and the system administrator wants to know if the SQL Server is the bottleneck.

First, if your organization doesn't use SharePoint, be sure to keep an ear out for it in case someone starts talking about it. You’ll want to make sure you’re in on the ground floor to be sure that the server meets your standard configuration (backups, etc.).

Second, if your company has SharePoint but you don’t manage it, make sure to ask some questions about whether or not anyone has paid attention to the SQL Server where the SharePoint databases live.

There’s also a relatively common issue with SQL Server 2005 (pre SP2) and SharePoint. Specifically, if SharePoint’s databases are located in a pre-SP2 instance and someone creates a maintenance plan to reindex the indexes in the databases, the maintenance plan will break some very specific indexes. This is because some of the SharePoint indexes require duplicate values, and the maintenance plan task that performs reindexing removes the “Ignore Duplicate Values” option by default, and then it blows away the index. You can take some relatively easy steps to fix it, outlined in this KB article. This issue is fixed in SQL Server 2005 SP2. However, many SharePoint servers don’t get updated with SQL Service packs because again, they tend to fly under the radar. Be sure to check this out, just in case.

Finally, be sure that the SharePoint SQL Server is being backed up properly, and has regular maintenance being performed on it (reindexing, DBCC CHECKDB, Microsoft patches). Until next time, have fun!

About the Author

Joshua Jones is co-author of A Developer's Guide to Data Modeling for SQL Server: Covering SQL Server 2005 and 2008 (Addison-Wesley Professional, 2008) and is a principal with Denver-based Consortio Services LLC.