Honestly, it looks like this thing is ticking every single code smell in this list. Go through this article and apply everything.

Two options, 3rd party tools are built for a reason. They do all the work so we don't have to. SQL Monitor will give you all that information...

Capture the query metrics to understand which queries are running slow. Extended Events are your friend. Then, for the queries that are slow, look for common...

If your system is taking 11 seconds to move 183 rows, either that data is absolutely huge, or that view is doing a seriously large amount of work. 4gb of...

Well, the second one is using a derived table where clearly none is needed. The other is just a JOIN. Effectively, any JOIN is actually a SELECT * under the...

It could be a ton of things. The best approach is to capture wait statistics and query metrics to understand what is running slowly and why. However, a likely possible...

Enormous performance killer:

September 28, 2018 at 7:01 am

#2007364

Well... to a degree this is true. In terms of storage and retrieval, 40 characters in a NVARCHAR(40) or in NVARCHAR(4000) or even in NVARCHAR(MAX) will perform the same way....

All those SELECT statements used to put the data together could potentially be tuned. I'd check each of the execution plans to see what's happening. Also this:

September 28, 2018 at 6:46 am

#2007358

Reinforcing Thomas' answer. Backup every database on the server (except tempdb) and you've backed up the server. All the logins, etc., are stored in system databases. Capture those, you've captured...

I've generally used two approaches. First, Distributed Replay is free with SQL Server. It will let you replay a captured set of events (trace or extended events) against...

I can't explain the differences in the statistics (and I've reached out to some people to see if someone can). However, I can explain performance hits on failover. You're going...