Viewing 15 posts - 4,591 through 4,605 (of 22,227 total)
The scans and the hash matches make sense. You don't have any kind of a WHERE clause to filter the data so the query is returning 300,000 rows. Scans &...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 20, 2016 at 5:55 am
If you're getting problematic plans, it's probably because of out of date statistics, so getting more up to date statistics is usually the solution. USE PLAN might not work that...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 20, 2016 at 5:36 am
Doctor Who 2 (7/19/2016)
Tonight I have a chance to go through the MSDN article you've posted in response to my question. It looks as though I need to first...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 19, 2016 at 8:23 pm
Jeff Moden (7/19/2016)
And stats. Small change in stats can make for wildly different executions.
Absolutely!
Also, plans can look the same but still be very different on the inside, estimated versus...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 19, 2016 at 4:14 pm
And then check for compression on the one with fewer reads.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 19, 2016 at 12:26 pm
Upwards compatibility is never guaranteed. This is because new functionality is introduced that older software can't cope with.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 19, 2016 at 6:07 am
You just have to set up your network so that the server is visible within it, then you're off to the races.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 19, 2016 at 6:05 am
Rod at work (7/18/2016)
Grant Fritchey (7/18/2016)
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 18, 2016 at 11:37 am
You can't restore to an Azure database. You can create a BACPAC and deploy that to Azure to create a new database, but a backup/restore won't work.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 18, 2016 at 9:10 am
I just recently published a blog post [/url]on this very topic. I'd suggest doing the checks that I did.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 18, 2016 at 9:07 am
I'm pretty sure you asked this question once already. Everyone suggested you use VARCHAR(MAX) but not TEXT, because TEXT is deprecated. Here's the documentation on VARCHAR. It stores up to...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 15, 2016 at 8:45 am
GilaMonster (7/14/2016)
Grant Fritchey (7/14/2016)
Assuming those are the top 3 waits, yeah, you have page latch issues.
I'm not so sure. The average wait time is around 5ms for the SH, 1.5ms...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 14, 2016 at 7:04 am
muth_51 (7/13/2016)
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 14, 2016 at 7:01 am
More information is needed. I'd double check the server configuration, memory settings, etc. Are there other processes running on that machine? What are the wait statistics? This is about investigation...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 14, 2016 at 6:59 am
Assuming those are the top 3 waits, yeah, you have page latch issues. Here is a white paper on the issue from Microsoft. Here is discussion around the issue [/url]from...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 14, 2016 at 6:45 am
Viewing 15 posts - 4,591 through 4,605 (of 22,227 total)