Viewing 15 posts - 14,041 through 14,055 (of 22,227 total)
Jack Corbett (10/25/2010)
Grant Fritchey (10/25/2010)
Jack Corbett (10/25/2010)
"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
October 26, 2010 at 5:21 am
krypto69 (10/25/2010)
Not if the next time your run the proc, you use parameters that have better plans with scans... and then all other parameters are better off using seeks.
I cleared...
"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
October 25, 2010 at 11:47 am
Jack Corbett (10/25/2010)
"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
October 25, 2010 at 11:17 am
krypto69 (10/25/2010)
if this was parameter sniffing .wouldn't I see scans in the execution plan?
I don't see scans...all seeks..the execution plan matches the one in stage which runs fast..
If scans/seeks/whatever, if...
"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
October 25, 2010 at 8:48 am
Have statistics been updated on both servers? The indexes rebuilt the same way? Besides the version of sQL Server, is there more/less memory, faster/slower processors, more/fewer disk drives, more/fewer drive...
"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
October 25, 2010 at 8:47 am
Maybe, so you have data that is suspect, like it might not have the right data types in a column or something? The only way to be sure ahead of...
"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
October 25, 2010 at 6:05 am
Jeff Moden (10/24/2010)
"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
October 25, 2010 at 6:01 am
george sibbald (10/24/2010)
Whats the...
"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
October 25, 2010 at 5:50 am
Stefan Krzywicki (10/23/2010)
Grant Fritchey (10/23/2010)
"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
October 23, 2010 at 8:49 am
Absolutely do not use a table valued function for this. Those things are notorious. Since you're saying you can't see it in the execution plan, it's a multi-statement function, right?...
"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
October 23, 2010 at 5:28 am
You should absolutely not run profiler on a production system as was mentioned. In addition, you should output your trace to file, not a database and especially not a database...
"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
October 23, 2010 at 5:22 am
You really don't need to start putting on index hints yet, no.
Yes, indexes work with the columns in the SELECT clause, the WHERE clause and the ON parts of the...
"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
October 23, 2010 at 5:18 am
Have you looked into using TRY/CATCH blocks within the procedure? That's the best way I know of to handle errors.
"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
October 23, 2010 at 5:12 am
Personally, no I wouldn't bother... but, there is a possibility, remote, rare, but certainly there, that you can get duplicates on GUIDs. So... you might want to leave it 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
October 23, 2010 at 5:02 am
The best suggestion I can give you is, instead of focusing on combining these five procedures, focus on defining the single query that will bring back what you need. Just...
"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
October 23, 2010 at 5:00 am
Viewing 15 posts - 14,041 through 14,055 (of 22,227 total)