|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Check in with someone who may be lonely or feeling anxious I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
The Slow Upgrade of SQL Server Versions Every so often Brent Ozar releases a report of his Constant Care customers, showing the versions in use. While I don't know this client group is representative of the overall SQL Server customer base, I do think it's close enough to draw some rough conclusions. The top version adoption graph that the summer 2021 report shows has 33-34% of the installed based on 2016, about 34% newer (and under support) versions, leaving the last third running older versions. However, the graph I found interesting is the lower one, which shows the distribution over time. What I see in this graph is that the older versions (2008-2014) held about 45% of installs in Q1 of 2020. Now they have 31%. The 2017/2019 versions went from 19% to 34%. Those are fairly close numbers, which indicates that a fair amount of these older versions were possibly replaced with newer versions. There could be brand new instances as well as retirement of old ones that weren't replaced, but in general I'd think this shows that the ten-ish year lifecycle of an instance is probably a good guess. This is about 12 years for 2008, and 7 for 2014, but that's around ten. I tend to think that many of us dislike upgrading our instances across major versions too often. While some DBAs might want to, there aren't often good business reasons for doing so, and many DBAs are just busy. Taking time to upgrade major versions for the same application, especially on the same hardware, doesn't always seem worth it. In my experience, business people want a long lifetime for a major version. It's just too expensive and time consuming to both doing this too often. I've also found after a couple years, DBAs know the ins and outs of a version, what works well, what tricks are needed to keep things tuned and running. Not to mention that a workload on one version isn't always faster, and sometimes it's slower, on a new version. There are definitely DBAs that might not want to bother changing versions and potentially having issues with their current workload from changes, like the change in the cardinality estimator in 2014. With modern hardware, for most applications, I think that many instances can run for 10 years. This might be even more true when we factor in that many database servers are virtualized, which means adding a few more cores or RAM is much simpler than in years past. How often do you upgrade versions? I'm sure some of you do this regularly, and I know some applications might benefit from upgrades more often then every decade, but I bet a lot of you don't bother to change this too often. After all, "working" is a feature, and if you have that one, why take chances? Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
