Viewing 15 posts - 7,951 through 7,965 (of 22,219 total)
I would suggest completely reconfiguring and reinstalling the system from scratch. I'd even nuke the operating system and start over. You don't want to deal long term with any kind...
"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
June 17, 2014 at 12:13 pm
I'd start any upgrade with the Microsoft SQL Server Upgrade Advisor. You want to know if you've run into issues with that before you do anything else. TechNet has a...
"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
June 17, 2014 at 12:10 pm
ben.brugman (6/17/2014)
Grant Fritchey (6/16/2014)
If filtering on tableA is what you needed, just do that. The INNER JOIN will take care of the rest.
Thanks for you response, offcourse this was a...
"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
June 17, 2014 at 10:07 am
You could be seeing something of what you're talking about, but as the data changes, if you have auto update stats turned on, you should see the stats change, although,...
"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
June 17, 2014 at 10:00 am
Two guesses, possibly out of date statistics on the tables in question or possibly something up with your I/O sub-system since you're seeing an I/O error.
EDIT
Sorry for the duplicate post....
"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
June 17, 2014 at 8:32 am
Two guesses, possibly out of date statistics on the tables in question or possibly something up with your I/O sub-system since you're seeing an I/O error.
"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
June 17, 2014 at 8:32 am
So if you don't have enough log space to do the delete in a single step, break it up.
"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
June 17, 2014 at 8:29 am
Maybe the statistics are out of date on the QA server leading to different execution plans? I know, truncating tables & all, but... Or, maybe statistics have changed sufficiently in...
"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
June 17, 2014 at 8:28 am
There are a fairly large number of performance measures. The best documentation I have on that is in my book on query tuning. There's a link below. It also covers...
"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
June 17, 2014 at 6:11 am
Koen Verbeeck (6/16/2014)
Sean Lange (6/16/2014)
Koen Verbeeck (6/16/2014)
Evil Kraig F (6/16/2014)
"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
June 16, 2014 at 3:26 pm
With log buffer waits, it's hitting conflicts with other processes in and around the log. It might just be slow.
"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
June 16, 2014 at 3:24 pm
Are there waits associated with the process? It's likely that it's just taking a long time or that it's blocked.
"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
June 16, 2014 at 1:05 pm
In general, I'd go with the first query. I think the optimizer will figure it out in most circumstances, but that assumes you have an enforced referential constraint in...
"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
June 16, 2014 at 1:04 pm
Based on the amount of information you have shown, it could be SQL Server. The reads are quite a bit higher I production. I'd suggest getting the execution plan 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
June 16, 2014 at 1:01 pm
And are there differential backups? If so, this stuff could be breaking your backup chain, which could lead to all sorts of fun when you try to recover.
"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
June 16, 2014 at 8:30 am
Viewing 15 posts - 7,951 through 7,965 (of 22,219 total)