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:

Enjoy!

5 thoughts on “SharePoint in a SQL Server environment

  1. Paul,
    Thanks for running the survey, posting the results and tips on SharePoint. I think you’ve found a new niche. The DBA who mantains SharePoint along with other SQL Databases.
    -Tom

  2. Can i also add that if its a large and/or busy sharepoint infrastructure (talking from a 2007 perspective) you need to be monitoring the size of your lists as anything over 2000 items (Microsoft recommendation but i have seen it fine with slightly above that) and you can start to hit performance issues relating to lock escalation. There are ways to tackle large lists so you need to either implement that or track the sizes…..it should be a SP admin’s task in my opinion but many of them don’t/won’t understand the implications of this and tend to ignore it until the site goes down.

  3. Hy all
    first of all a great site…i found a lot of information who was really helpfull.
    But one question is still open…what recommend you guys wich collation you should use for a sharepoint SQL Server,default or Latin1_General_CI_AS_KS_WS ?

    Thanks and have a good day
    Daniel

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Some thoughts on courage

(This is also the Ponderings – editorial – in today’s SQLskills newsletter.) I want to start out this post by sincerely thanking everyone who emailed

Explore

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.