May 5, 2020 at 12:13 pm
I am suggesting to my boss that we start installing SQL 2019 servers instead of continuing with SQL 2017. He wants proof that is reliable because it is a fairly new release. Comments, stats or statements of reliability are appreciated.
-Kevin
May 5, 2020 at 1:24 pm
Stats, no so much. Comments, tons.
The key to understand how Microsoft develops and releases SQL Server in this modern age is Azure SQL Database. With a few exceptions, all the code that you see in SQL Server 2019 was developed, deployed, and tested across millions of instances for upwards of 3-6 months minimum before it made it into the 2019 code. When you look at the SQL Server 2019 release, you're not seeing new code for the first time. You're seeing code that has already been stress tested on more systems than any of us will ever manage.
Because of all this, you can go back and read the histories, 2014 was smoother than 2012. 2017 was smoother than 2014. 2019 is absolutely a superior product to 2017. It's just not the old Microsoft any more. We don't have to wait for SP1 (which may never arrive) to implement new code because it needs to be tested by others first. It's actively being tested inside Azure.
Considering how long it normally takes to move a substantial portion of most enterprises (6-9 months in most cases), of course choosing to move to 2019 makes sense. Why? Even more testing will have gone on before you ever get near having most of your servers in production. You can be absolutely assured that things are stable by the time you really need it.
I wouldn't hesitate.
Now, that said, what if I was already mostly on 2017 with very few, or no, new migrations necessary? I'd probably stay there. It's not that 2019 is problematic so much as there's not enough radically net new functionality to drive me from 2017. However, if I was looking at some substantial portion of remaining servers to migrate from older versions, heck yes. 2019 all the way.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 5, 2020 at 2:23 pm
I don't trust any upgrade. That's why we deploy to Dev, then Staging, and then Prod over a decent period of time. Even then, though, MS fins a way to mess things up. The automatic and irrevocable change to TempDB (equivalent of TF1117 permanently invoked) put the screws to us because of the fault where MS does a full sort of the CI in TempDB when using SET IDENTITY INSERT ON. I think I may have figure out a way around that (thankfully). They also silently screwed us with their "improvement" known as "FAST INSERTS". Fortunately, they provided a way around that nonsense-to-help-stupid-people in the form of TF692.
And, although 2019 has some wonderful stuff in it, like auto-inlining of Scalar Functions, the other "improvements" scare me to death because of the crap they came up with to "help" us cited above for 2016.
Don't get me started on the "improvements" they've recently made in SSMS.
My feeling is that they should make things work correctly for people that know what they're doing before they try to make it easier for people that won't spend the time to know more.
Heh... and seriously... why on this good green earth is Extended Events (or anything else in SQL Server) so bloody reliant on XML?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 5, 2020 at 4:35 pm
Features change, sometimes improve, sometimes cause issues with your code. As Jeff mentioned, you need to test well before changing anything.
However, I haven't seen any reports on reduced reliability from the community on 2019. It works as well as 2017, and has 2 more years of support. If you push the edges, looking at new features, they may not do what you expect, or what it says on the tin. They may evolve as well. I am very, very wary of 1.0 features. That being said, stability of the db code, backups, etc., seem to be rock solid.
May 5, 2020 at 6:43 pm
one of the good features of 2019 vs 2017 - R is available to install on a Cluster on 2019 - not so on 2017.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply