Six months ago today, Microsoft announced that SQL Server 2022 was ready.
Except it wasn’t.
And it still isn’t ready.
See, look at the very first hero in their list of 2022’s new features:
The very first one is “Business continuity through Azure – Bidirectional DR to Azure SQL.” However, buried way down in the footnotes, Microsoft admitted:
The bidirectional disaster recovery capability of the Link feature for Azure SQL Managed Instance is available in limited public preview. Sign up for early access. General availability will occur at a future date.
Well, it’s been 6 months now, and that feature is still only in limited “public” preview, and by “public” I mean you have to apply through a form so the product group can onboard you. The form has some interesting questions that insinuate this thing still needs some baking, like asking how much time per week that you can work with the product group, and asks you to assess your skills:
And at the end of the form:
I applied on April 26th out of curiosity. I haven’t heard a word back.
You might say, “Well, that’s just one of the features – the rest are ready, right?” I’d disagree – the second hero feature was Azure Synapse Link, and the list of current limitations for that is horrific.
- The table can’t use CDC, Always Encrypted, columnstore, etc
- The database can’t have transactional replication
- The database can’t be involved in Azure SQL Managed Instance Link – meaning the very first two hero features can’t even work together
Should you install SQL Server 2022? I think as long as you stay clear of the new features, you’re fine. The new version gets you query performance improvements (especially for Enterprise Edition users) and longer supportability.
But if you want to use these new features, SQL Server 2022 just still isn’t ready.
So next week at Microsoft Build, when you hear folks making grand announcements of upcoming features, just remember that they still haven’t delivered on last year’s “released” features! Take announcements with a grain of salt: until it’s actually in your hands, it’s vaporware. It bums me out to have to say that out loud, but here we are.
Update 2022-05-17: another not-done feature
A reader pointed out to me that Query Store on readable replicas was supposed to be a SQL Server 2022 feature, and that one’s still not done yet after 6 months, either, as the documentation points out:
Update 2023-11-18: still not ready.
At the Microsoft Ignite and PASS Data Community Summit conferences, Microsoft proudly announced that the online disaster recovery between SQL Server 2022 and Managed Instances is getting closer – but… it’s still only in preview. It’s amazing to me that even a year after its release, SQL Server 2022’s flagship feature still isn’t ready yet.
Needless to say, Microsoft didn’t unveil anything about vNext at those conferences – because they can’t. They’re still working on getting SQL Server 2022 out the door.
Here’s to 2024 being the year that SQL Server 2022 is finally ready.
29 Comments. Leave new
YIKES!
Agreed — That’s too long for half-baked primary selling points
I’m having significant issues with SQL Server 2022 Enterprise and Query Store in an Always On Availability Group cluster. We literally had to disable Query Store to prevent recurring memory dumps and access violations. MS Support is stumped and my team is frustrated that we went live on this and now have taken a step back in functionality. Hoping that CU4 might address some of it…
Ouch. Are you trying to use the new functionality for Query Store on the secondaries, or were you only using it on the primaries? (Just curious.)
We were not using it actively on secondaries, but it appears that the secondary tries to write to the primary anyway and causes the access violation.
[redacted per user request]
See this post. Looks like there are workarounds
https://feedback.azure.com/d365community/idea/27e971e1-1dd5-ed11-a81c-000d3a7a9cdb
Hahaha, the workarounds are to turn off Parameter-Sensitive Plan Optimization (PSPO), or to loop through all of Query Store trying to delete the PSPO plans, something that’ll never finish since new queries will keep coming in? Wow.
CU 5 should fix the Parameter-Sensitive Plan Optimization (PSPO) issue with Query Store. Going to apply it today.
Use it since a few month in prod (Enterprise, on premise, stand alone no AG / HA etc.), primary because of the new T-SQL-features as LEAST(), GREATEST(), DATETRUNC() etc., which works well
Cool – so are you using the two major new features I talk about in the post?
No, but the more important features :-), because they make the life easier. But of course you are right, my comment is a little bit off topic, if you focus only onto those two major features, but your caption says, that SQL 2022 is not ready yet, which is only true for those two features, while other new stuff is working fine.
The major features (if they would working) are edge cases that may be nice / very useful in some environments, while the new T-SQL features may be very basic but can be used by everyone without much effort and are helping immediate.
Of course nobody would spend 7.5k USD per Core on some new T-SQL-Keywords, but with Software Assurance it is already covered and when you are going to buy / set up a complete new server, you have to buy the most recent version too (but may downgrade it).
Bingo – like I repeatedly mention through the post, we’re not talking about T-SQL features. We’re talking about the two main features that Microsoft marketing touted as the biggest reasons to get SQL Server 2022.
Hi Brent, I agree on the fact that MI link for DR is not fully ready as well as the QDS on replicas mentioned here, but in regards to the Synapse link limitations , even if I agree that are quite a lot, the feature is on V1 and it it doing what they said it will do. I do remember the first version of OLTP in-memory and also were a lot, but they did remove some of those in upcoming mayor versions
I would not call a feature ready if it won’t work with Change Data Capture, Temporal history table, Always encrypted, In-Memory OLTP, Column Store Index, and Graph. That’s directly word-for-word from the Synapse Link limitations, typos included. (Even the documentation is chock full of typos.)
That’s frustrating. Those features are literally the thing our management was waiting for and I’m having to tell them “its not ready yet” — I think they are understandably upset because we are about to have a need to stand up some more availability groups and they don’t want to use 2019 and lose out on the extra few years of support, meaning that we’ll have to revisit these servers sooner than we should. So I’m stuck having to either accept the hobbled limitations and reconfigure everything in the future when the features are actually usable, or try to convince management to wait.
Matthew, can you not just install 2022 and use as is for your new Availability Groups. And then later, through CUs, start using the Azure-connected features?
I agree with Brent, some of the new stuff is still half-baked and shouldn’t be put into production.
It has one hero feature: The database can’t have transactional replication
Heh heh heh…
We see the same thing with computer games which are released and wont work without one or more large patches – we didn’t get this (as often!) when games were released on floppy disks and online patches weren’t an option – though we do get better games / more features now. Maybe it’s a trade off of more features in exchange for more patches and bugs for both PC games and business critical software?
Synapse Link is a funny one for me. It’s supposed to grab a SQL Server table and replicate that table to Synapse. But if I understand it correctly, it doesn’t go directly into a SQL Dedicated pool (which would be compatible) with SQL Server. Instead, there’s a landing zone in Data Lake Storage where the data is stored before being copied to a SQL Dedicated pool. To me, that sounds like it’s being push to a SQL Serverless pool first, which is actually an Apache SQL table. That’s where I believe the incompatibility fallse. The underlying Apache SQL table can only store and work with tech that it understands, which is outside of the AlwaysEncrypted, CDC, In-Memory, etc… capabilities.
While we’re at it, I would also add all the unsupported data types: image, text, xml, timestamp, and others.
And the limitation of primary keys and number of columns.
Personally, if Synapse is my tool, then I’d consider data virtualization or just using CDC directly with a SQL Dedicated pool and bypass the whole Synapse LInk setup. It’s a bit more old-school, but it’s not ETL and it works.
I know, it’s not what we were promised, but Managed Instance Link for bi-directional DR is still out a ways and HA isn’t ever going to arrive.
It was generally the case a while back, with any new version of SQL Server, that you would wait for at least 6 months after release before installing it in a production environment as that gave plenty of time for major bugs to be identified and ironed out with the first couple of patches. I rather thought that this had improved, however 2022 looks like a retrograde step, particularly for ‘features’ that purport to be available but aren’t, or at least not fully.
Since trying it with CU4 it logs job successes as failures in the agent log, and changed/broke some important latency columns on AG DMVs. And more.
They’re minor issues, but which require redesigns out of the box. For large customers who rely on stability it’s not a good look.
Kinda surprised MS hasn’t piped in yet on this post 😀
I was accepted into the preview program for using the bi-directional link DR feature between an Azure MI and an on-prem SQL AG. It’s a really exciting feature and my boss was all for it. It was really easy to set up – the SSMS team did a good job with the wizard. But.. We kept having issues. After the db seeding from on-prem to MI finished, something on the MI side went wrong and the MI copy of the db just disappeared. On another attempt, something on the MI side stopped the transaction log from clearing, so the on-prem log drive filled up and the DB crashed. (FYI, the process uses distributed AGs behind the scenes, so transactions have to harden in both places.) The lack of insight into MIs makes it really hard to troubleshoot anything there. We ended up opting to wait another year for the feature to get fully baked before trying again.
Has anyone run into issues with SQL Server 2022 removing the SQL Native driver? Could .net program need a redesign on database access/connectivity/code logic?
This is from Microsoft Link: https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/support-policies-for-sql-server-native-client?view=sql-server-ver16
‘The SQL Server Native Client (often abbreviated SNAC) has been removed from SQL Server 2022 (16.x) and SQL Server Management Studio 19 (SSMS). The SQL Server Native Client (SQLNCLI or SQLNCLI11) and the legacy Microsoft OLE DB Provider for SQL Server (SQLOLEDB) are not recommended for new application development. Switch to the new Microsoft OLE DB Driver (MSOLEDBSQL) for SQL Server or the latest Microsoft ODBC Driver for SQL Server going forward. For SQLNCLI that ships as a component of SQL Server Database Engine (versions 2012 through 2019), see this Support Lifecycle exception.’
For unrelated questions, your best bet is a QA forum.
Just upgraded from 16 to 22 and queries with CROSS APPLY and TOP got worse performance in all cases. Plans changes to Nestes Loops…
*Nested