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...

You can define it that way if you want. I would not agree that these are universal definitions. In fact, I don't see that differentiation really. I do see a...

Also, please, a join, or even 3 or 7 or 20, is not some OMG HAIR ON FIRE performance issue. It's not. In fact, relational storage engines are very good...

It sure looks like additional processing is occurring. See the VM processor going up at exactly the same point as your memory issues start. You also see that earlier with...