I appreciate the feedback.

One reason I've used index rebuilds in the past is because some of the third-party apps we rely on can sometimes end up with a query...

Oh!

yeah, the query store data is stored with the database. If you back it up, which you are absolutely NOT doing, when you restore, you will get that data back....

Effectively a varchar(50) and a varchar(4000) are the same, so you won't see an implicit conversion there. It's the varchar to int that you're going to see the most.

All problems won't be fixed in the code, but I'd start there. Get that right, then figure out how the queries really behave. From there, you can make some good...

Query Store is not overwritten during a restore. In fact, it remains completely intact. All Query Store information is in system tables, stored with each database and will get backed...

Piling on.

Sounds like statistics are getting out of date. Focus there, not on index rebuilds (although, those will also update statistics).

ALL cases.

All of them. Statistics are what the optimizer uses to determine how many rows are likely to be returned from a given table or index. Without statistics, the optimizer...

You could provide them with PowerShell commands that run the script. Or, assuming they have a client tool installed, a batch file to run the command. I'd lean towards Powershell....

Check all the settings as suggested. Maybe an application server is misconfigured and using different ANSI settings. Look at the query_hash values to make sure they're the same. Normal behavior,...

Woof!

So, your parameters don't match the data types of the columns. I know you said you can't change the code, but it's wrong. For example, tinyint, which is what's in...

This is an old article, but it shows one way to deal with versioned and backdated data. It's still very applicable. Also a follow-up article showing another mechanism....

A DELETE operation has to find the appropriate rows to delete. That means it has to look at the values. If there are no indexes, it has to scan every...

Oh, and 2019 introduces a bunch of good knobs for tweaking QS behaviors. You really can reduce the overhead quite a bit (QS is amazing, wonderful and cool, but yeah,...

I normally do try.  I even violated my own decision to "black ball" someone last night and tried to figure out what the heck it was they were talking...

Yeah, Jack's right. Query Store is a good way to go. It does aggregate the data you get (by the hour by default), so if you need detailed info, XE...