CU or SP - What to do? What to do?

Question

CU or SP - What to do? What to do?

CavyPrincess

Hall of Fame

Points: 3336
More actions
November 23, 2016 at 2:43 pm

#401115

The new patching recommendation from Microsoft is now "recommend ongoing, proactive installation of CU’s as they become available". No more waiting for the service pack.
https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-updates-to-the-sql-server-incremental-servicing-model-ism/
I'm curious as to how others are addressing with this recommendation. I know I don't want to be first to apply the latest CU released. Plus, depending on how frequent the CUs are released, I'm leaning towards maybe a quarterly patching schedule.
Are you applying the CUs as they become available or taking a "wait and see" approach?
Thanks for your input.
Cindy

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 1

CavyPrincess (11/23/2016)
The new patching recommendation from Microsoft is now "recommend ongoing, proactive installation of CU’s as they become available". No more waiting for the service pack.
https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-updates-to-the-sql-server-incremental-servicing-model-ism/
I'm curious as to how others are addressing with this recommendation. I know I don't want to be first to apply the latest CU released. Plus, depending on how frequent the CUs are released, I'm leaning towards maybe a quarterly patching schedule.
Are you applying the CUs as they become available or taking a "wait and see" approach?
Thanks for your input.
Cindy

With 2012, it was almost essential to keep up to date all the time because of some of the problems MS had. With the 2014 SP1 problem they had with SSIS, staying on the bleeding edge of updates scares the hell out of me. It's always scared me. Remember SP3 and the emergency release of SP3A to fix SP3 for SQL Server 2000?

With all that in mind, we wait a month and then update the Dev boxes, which also contains the QA databases. We wait a week and, if nothing goes haywire, we then update the Staging boxes (lots of UAT and other testing always going on there). Same process for Prod after that. Wait a week (the changes are now 6 weeks old) and then update prod.

Unfortunately, corporate makes us do Windows updates without waiting the month because of "reasons of security". Fortunately, our NetOps team is really on the ball. We had a Windows Update break some custom code and they were able to rollback the Windows Update(s) until a fix could be investigated, constructed, and tested. It was a spooky moment because it was our telephone system that took the hit.

So, Plan (A) is move slowly and Plan (B) is when something goes wrong, be prepared with a tested mulligan.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

kevaburg SSCoach Points: 18131 More actions · Answer 2

The majority of our databases reside on a 3-node Standard Cluster under SQL Server 2014. Initial patch testing is done on a machine for exactly that purpose.

We believe in patching as soon as we can but update only one node, a passive node. Once we Switch over to the patched node we can test the Patches productively (i sense shaking heads here but what other way is there when so many application databases share the same instance?).

If we have Problems we can Switch back over to an unpatched node and we still have our untouched 2-node Cluster, otherwise we can assume a safe Installation can be done on the other two nodes.

So, my answer to your question: If you have the resources to ensure continuity in the case that a patch update doesn't work then stay as actual as possible. Otherwise, let others find out the hard way and use their experiences to help you!

Summer90 SSC-Dedicated Points: 32891 More actions · Answer 3

Each version of SQL Server had had at least one SP or CU that within a week or so gets pulled or updated for some reason so I am hesitant to apply them right away. If we were to keep up-to-date with these we would have to hire more testers and another DBA with the sheer number of database servers we have. Also, for purchased apps they don't test against the latest SP or CU for older versions of their software and a lot of vendors will not support you if you have an issue if you apply these. We try to keep somewhat up to date. We DO apply the security patches supplied for SQL Server within a month though.

Steve Jones - SSC Editor SSC Guru Points: 734449 More actions · Answer 4

My thought is:

- security patches - apply ASAP after testing. There are too many automated bots and scripts out there looking for issues. Or on your network because someone clicked the wrong link.

- CUs - apply after testing only if you have an issue. I would look to apply patches at least once a year, even without issues. If we do 12 months w/o an SP, get closer to up to date with CUs. Maybe one back.

- SPs - Apply after testing. If you call support, you'll want to be close to up to date and this gets you closer to current.