Not really. More memory. Parameterization so that queries aren't ad hoc. Optimize for ad hoc so plan stubs are used for the one-off queries, reducing memory use, increasing the chances...

That's a sysallocations error. You should restore from a good, tested, backup. Or, you can run repair allow data loss, but I'm not sure it'll work. Here's a bit...

Your choices are pretty limited. Plans that are negatively affected by the 2014 Cardinality Estimation engine are generally marginal in terms of performance and behavior, prior to getting the new...

For the feedback to work, there has to more than one execution. No other possibility exists. There's not a switch or a setting that will affect this. You could look...

What you're looking for are the INSERTED and DELETED tables that are available within a trigger. For an INSERT operation, you'll only see detail in the INSERTED table. For...

Let's be clear up front, there is no such thing as an "estimated" or "actual" plan. There is an execution plan. And then, there's an execution plan with the...

On top of all this, remember that the execution plan for a MERGE operation is made based on the values initially passed. So, you may have a merge that's all...

I agree with Johan, DBATools is the better approach. You can just script out the logins using SSMS or ADS and then run the scripts on the second server.

Someone has to set the recovery model of the database. They don't change randomly. Now, if the full backup of a database was in a different recovery model than the...

Well, I hope you both get a little refresh going. I'm feeling a bit more on it today after playing radio all day Saturday (Tour De Tulsa, bike rides and...

Through SQL? No. It's a command line driven process. Powershell is how I would do it. Check out DBATools.

Were both these generated by ChatGPT?

The first question ranges all over the place. The first paragraph is all about performance, then the second is data analysis. Which are you really...

Why not take a backup, transfer that, restore it? I'm lazy too.

Just remember, Managed Instance is a SQL Server instance. The server aspects are gone, so no worries about that. However, all the internals are still there. So, database consistency, that's...

I don't have an answer or even a guess. Hang on though. I'll see if I can get some help.