New answers tagged performance-tuning
The indexes that were created and dropped by DTA were most likely hypothetical indexes - ones that DTA creates while running to perform its analysis and should (but doesn't always) delete once done. These hypothetical indexes can be created even if you weren't looking at tuning that specific table! I'd recommend you query some of the system DMVs directly ...
How is the maintenance of these two database? The first have a lot of reads and the second have a lot of writes The first database needs update statistic before the process and the second database needs a dbcc dbreindex() to avoid prevent space alocation and page split
Alternatively, SELECT MAX(LEN(column)) FROM table; would work equally as good (if not better as it should eliminate the Sort operator)
You can achieve this with this code snippet: SELECT TOP 1 LEN(column), column FROM yourTable ORDER BY LEN(column) DESC Just replace column with your column which holds the nvarchar(100)
Your max_connect_errors is way too low. You have it at 1000. That means after 1000 consecutive connect failures, you cannot connect to MySQL any longer. Your status variable Aborted_connects should be the dead giveaway if it climbs fast. When you can no longer connect to MySQL even with bunch of open DB Connections, you would have to execute FLUSH HOSTS; ...
Is it possible? Sure. Is there likely to be an improvement in performance? No. If there is a change in performance (barring cases where you discover that a join is missing or otherwise fix a query), it'm more likely that the old implicit join syntax will be more efficient. But that's pretty unlikely. Behind the scenes, when you have a query using the ...
Try: WHERE FileName >= N'ATT000' AND filename < N'ATT001' And make sure you have included columns to avoid lookups.
Top 50 recent answers are included