I’m almost afraid to look into the SQL ConstantCare® client base to see the answer to this, but let’s put on a pair of rubber gloves and go find out.
SQL Server 2016: <1% out of support. I LOVE YOU PEOPLE. However, you’ve had the luxury of time here: SP1 came out in November 2016, so 99% of you have had the time and motivation to install it. SP2 is already out, but both SP1 and SP2 are supported right now. SP1 drops out of support in July 2019. SP2 came out in April of this year, and 64% of you are already on it!
SQL Server 2014: 10% out of support. Both SP2 and SP3 are supported right now, and SP2 isn’t out of support until a luxuriously long-from-now January 2020. I’m not gonna lie, though: a couple dozen of you didn’t even bother to patch the original install of 2014. Get on the ball.
SQL Server 2012: 38% out of support. Service Pack 3 just dropped out of support last month, so I’m not too surprised that a lot of folks have been caught off guard. SP4 came out just over a year ago.
SQL Server 2008 R2: 27% out of support. Service Pack 3 came out four years ago, and it’s the only remaining supported SP. Thankfully, most of you are on it. However, 14 of you are running a completely unpatched SQL Server 2008 RTM. We’re talking about an eight-year-old set of bits. They’re rotted. Throw them out.
SQL Server 2008: 65% out of support. The only remaining supported Service Pack for SQL Server 2008 is Service Pack 4, and 2/3 of y’all aren’t on it. C’mon, now, SP4 came out over four years ago – get ‘er patched.
When I talk to folks about why they don’t patch more often, I usually hear:
- We can’t get a maintenance window
- The vendor won’t certify their app on the new patch
- It works well enough, no reason to risk it
- I don’t open support calls anyway, but if we had to, we’d patch it then to get support
What about you? Why aren’t you patching your SQL Servers?
5 Comments. Leave new
Our vendor has a soft-requirement that we are on the newest CU/SP of a supported platform (SQL 2014/2016) within 3 months of that CU/SP release. Just installed 2016 SP2 CU4 in TST. I, actually, really appreciate that requirement because I never have to argue about getting that hour maintenance window to install them.
Not only are they out of support, but also a security risk due to unapplied security updates. It should never be an argument with management to regularly patch. If it is, then lay out the risks to them and let them take the responsibility. Planning a few downtimes per year is much less painful than an out of service application or security breach. Also, if you’re not patching regularly, then you are probably not restarting the servers regularly either. A regular restart is always a good thing.
And if a vendor won’t certify their software on a new patch, find a new vendor. They aren’t doing their due diligence. As soon as you tell them you are going to shop for another solution, I’m sure they will comply.
BTW, we patch everything, Windows and SQL, quarterly with whatever is the latest SP and CU available at the time. Well, not anything fresher than a few weeks old. Let them “bake” for a few weeks to ensure there are no major bugs included.
Thank god we are not relying on Microsoft to support anything w/ our “unsupported” versions we are using just fine. The trouble with SPs/CUs is the uncertainty these introduce. Are we going to be the receivers of a performance regression no one found before us?
Applying SPs/CUs does not have to incur downtime on setups with any HA — just failover to a mirror server. If no HA implemented then the server is not critical enough to guard against downtimes in first place.
I have installed SQL server 2012 in my c drive and data files are stored in d drive. I restore data base of 370 gb from another partition. How much storage will be acquired by c,d and another partition
Six cubits