We have an outdated build of SQL Server 2008 R2(SP1) and therefore we are in need of patching(SP3).

Does this have any impact on SharePoint?

What measures should I take, besides backing everything up and testing before doing in production?


SharePoint 2010 is supported on SQL 20018 R2 SP3, so no, there shouldn't be any issue installing the service pack onto your SQL Server.

I'd test (if at all possible) on a test system first, simply to ensure that any other solution installed within the SharePoint farm also continues to function as expected once the service pack is installed.

Obviously you should also take a set of backups of all of the databases on the SQL Server before you proceed (and test the backups!) in case you have any issues and need to be able to roll back. A SQL alias (as mentioned by Benny) is your friend here as you can run up a new server quickly, change the SQL alias(es) to point to the new server and you're good to go.

During the installation of the service pack there will be downtime to the farm as the database services will be unavailable for a period of time during the patching process. If at all possible, shut down the SharePoint server before starting the work.

  • Should I be worried that the Sql Server 2008 R2 SP3 is not listed as compatible in Microsoft documentation or did they just stop updating this? msdn.microsoft.com/en-us/library/gg492257.aspx – ranbo Feb 8 '17 at 13:07
  • 1
    The link is for Reporting Services and SharePoint, rather than the database engine to support the SharePoint databases. There are no known issues reported for SharePoint 2010 working against SQL 2008 R2 SP3, and I have used this configuration personally without issues. Microsoft usually request that SQL is patched to the most recent service pack for hosting SharePoint databases, and this is best practice for SQL Server anyway. – Andy Dawson Feb 8 '17 at 13:22
  • 1
    You'll also notice at the following link that the requirements are stated as 'minimum requirements' rather than specific requirements: technet.microsoft.com/en-us/library/… – Andy Dawson Feb 8 '17 at 13:25
  • Do I need an order of patching if my Content and Config Databases are in separated servers or it doesn't matter? – ranbo Feb 15 '17 at 14:01
  • 1
    The order of patching SQL Server shouldn't matter, but I'd generally try to patch the instance that hosts the configuration and service application databases first, followed by instances that host content databases afterwards. Be aware that as the SQL patching process impacts SQL operation, there is likely to be downtime for the parts of the system that are hosted on the SQL instance that is being patched. – Andy Dawson Feb 15 '17 at 14:30

I would install a new SQL Server to the level that you require, such as SQL Server 2008 R2. Tehn I would backup from source SQL and restore to destination SQL, with the same permissions and settings as the source SQL.

Then I would run cliconfg on my SharePoint Server(s) and create an alias from the source SQL to the destination SQL and restart services and IIS.

That way you can test the SQL Server without loosing the option to quickly switch back is something bad happens (by removing the SQL Alias).

  • I think I poorly formulated my question. I have the R2 but want to go from SP1 to SP3. Does the same apply? I meant patching and not updating. I will edit my question – ranbo Feb 8 '17 at 12:44
  • 2
    Patching is safer, and it shouldn't be a problem. But to make sure, I'd proceed with my suggestion above, or run the same in acceptance test first. – Benny Skogberg Feb 8 '17 at 12:55

Upgrading / Patching of SQL server is not big issue as compare to patching the SharePoint server. You have to plan it properly.

  • First thing, you have to apply the patches in lower environment and test the behavior of both SQL as well as SharePoint. Once satisfied then move to production.

For Production

  • You have to schedule a downtime as it will interrupt the sharepoint. off hours always great.

    -Backup the SQL Server( all the databases)

  • Shut Down the SharePoint servers, I do this way but if you dont like it then stop the timer & admin services, IIS, Search service.

  • Apply the patches to SQL server.

  • Verify the patches installation.

  • Bring the SharePoint server back.

  • Test the Farm, also check the event log & ULS for unusual activity.

  • Run the Full backup of the SQL again.

  • There is no need to stop SharePoint services. They'll pick up the SQL connection once SQL is available. – Trevor Seward Feb 8 '17 at 15:30
  • But what if user trying to update the document while patching in progress – Waqas Sarwar MVP Feb 8 '17 at 15:36
  • That's what outage alerts are for. But if they're trying to update a document, it just won't succeed. There's no technical reason you need to shutdown SharePoint services during a SQL outage. – Trevor Seward Feb 8 '17 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.