4

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?

Improve this question

3 Answers 3

Reset to default
4

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.

Improve this answer
5
  • 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
    Commented Feb 8, 2017 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
    Commented Feb 8, 2017 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
    Commented Feb 8, 2017 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
    Commented Feb 15, 2017 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
    Commented Feb 15, 2017 at 14:30
4

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).

Improve this answer
2
  • 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
    Commented Feb 8, 2017 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 ♦
    Commented Feb 8, 2017 at 12:55
3

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.

Improve this answer
3
  • There is no need to stop SharePoint services. They'll pick up the SQL connection once SQL is available.
    – user6024
    Commented Feb 8, 2017 at 15:30
  • But what if user trying to update the document while patching in progress
    – Waqas Sarwar MVP ♦
    Commented Feb 8, 2017 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.
    – user6024
    Commented Feb 8, 2017 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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