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:

 moss SharePoint in a SQL Server environment

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:

Enjoy!