SharePoint in a SQL Server environment

A few weeks back I kicked off a survey asking whether you have SharePoint in your SQL Server environment at all. Here are the results:


The "Other" responses were:

  • 3 x "Not now but I did in a previous role."
  • 3 x "Yes, but the dbas do not manage their servers."
  • 2 x "SharePoint 2007 and 2010."
  • 1 x "My environment no but it's included in an MES environment."

Almost 75% of respondents have some form of SharePoint in their environment. Although I don't think is a statistically valid representation of the installed SQL Server user base, I think it confirms what I've been thinking – there's a *lot* of SharePoint out there. Remember that this is just a survey of people who read my blog – primarily SQL Server professionals – there is a huge amount more SharePoint installations where there is *no* SQL Server professional involved.

The reason that it's interesting whether SharePoint is involved in your SQL Server environment is that it can have an impact on your regular maintenance and your HA/DR strategy. Ordinarily you'd want to treat a SQL Server instance that's running SharePoint just like any other back-end SQL Server for an application, but SharePoint imposes some restrictions on you.

  • It has it's own maintenance jobs which run regularly, which means you either need to exclude that instance from your standardized maintenance setup, or disable the SharePoint jobs completely and run your own, taking into account the SharePoint guidelines.
  • There's more than one database required for SharePoint to work properly, which means that database mirroring or log shipping as HA/DR providers becomes extremely tricky. I usually recommend failover clustering with SAN replication for HA/DR to avoid complicated failover logic. Backup and restore can become more complicated too – especially when using an off-database LOB storage layer like RBS.
  • You can't create additional filegroups in the large content databases and you can't use partitioning (except for the Web Analytics service), which means taking advantage of filegroup piecemeal restore and partial database availability is not possible.
  • Auto-create statistics needs to be disabled for SharePoint, whereas in most situations you want it enabled – a departure from your standardized setup.
  • MAXDOP=1 is strongly recommended – again a departure from your standardized setup.

Some of this guidance is unfortunate, and shows that SharePoint's use of SQL Server is not as optimal as it could be, but all of this means that you need to treat a SQL Server instance that underpins SharePoint differently from your other SQL Servers.

You can read more about SQL Server configuration and maintenance when using SharePoint at:


Survey: do you have SharePoint in your SQL environment?

This question came up on the #sqlhelp tag on Twitter today, and it's something I'm interested in too: what percentage of SQL Server environments include SharePoint somewhere too?

This is interesting because it has implications for standardization of SQL Server maintenance and HA/DR procedures across your company.

If you don't have SharePoint, please take 5 seconds to click No so the results make some sense.

I'll report on the results in a week or two.


SharePoint 2010 database maintenance whitepaper

As you may know, I've been teaching the SQL Server portion of the SharePoint MCM since it started. The old database maintenance whitepaper for SharePoint 2007 had all kinds of things wrong with it and the publishing of the updated whitepaper for SharePoint 2010 was eagerly awaited by the community. Unfortunately it too had a bunch of problems so I offered to get involved and comprehensively review and rewrite it, and did so just before the summer.

It's finally been republished with all my revisions and you can download it from: