I love how Microsoft treats deprecated and discontinued features in SQL Server.
No, seriously. I give Microsoft a lot of sarcasm and lip around here, but Microsoft takes serious care to make it easy to upgrade versions without worrying about your application breaking. If you disagree, hear me out for a minute.
“Discontinued” means it’s dead and removed.
The Books Online page for discontinued database engine functionality is pretty doggone short. There have only been a few things deprecated in the last several years:
- Big Data Clusters
- PolyBase scale-out groups
- A few database-scoped configuration options
- And a few others you’re not gonna miss, like the 32-bit version of SQL Server
This is fantastic. If you’ve written a new app in the last 10 years and it used SQL Server as a back end, odds are every query you wrote is still going to compile and execute today. Contrast that with the nightmare that developers have to deal with around .NET and .NET Core, and the difference is night and day. SQL Server queries just work, and they’ve worked the same for decades, with almost all additive changes only.
Deprecated means alive,
but it’s walking dead.
The Books Online page for SQL Server 2022’s deprecated features is tomorrow’s obituaries. These are features Microsoft has publicly walked away from, and while the features are still in the product, they’re not getting any love, and they might be removed at any time.
For SQL Server 2022, Microsoft deprecated Distributed Replay.
The idea behind the feature was that you’d capture a trace against your production environment, set up another environment for load testing or QA testing, and then replay that exact same workload against it. You’d be able to measure which queries got better or worse, and how.
The reality was a complete mess. It was a giant pain in the rear to set up and use, to the point where I got frustrated with it within a few hours and asked my peers about their experiences with it. I got back a string of four-letter words – everybody really struggled to get it across the finish line. Over subsequent versions, Microsoft made token efforts to improve it, but never really gave it the love it required.
The writing was on the wall when Distributed Replay didn’t support collecting a trace from SQL Server 2019.
Now, the writing’s getting carved into stone. My guess is that even in SQL Server 2022, Microsoft still won’t support gathering data from SQL Server 2019, which means this thing’s already dead. Sure, you can technically use it with SQL Server 2017, but…
So what do you use instead?
Me personally, I don’t believe that capturing a production workload trace has ever been a good long-term idea. I’ve written about the problems with database load testing before, and my opinion still stands: it’s a really, really hard problem, much harder than it looks at first glance.
If you do wanna try it, check out Gianluca Sartori’s open source WorkloadTools.
Otherwise, you need application-level load testing instead. Something needs to call the app’s APIs, generate the relevant workload, and get the app to send in the appropriate queries. Plus, then you’re testing the entire stack – not just the database server.