Viewing 15 posts - 21,406 through 21,420 (of 22,219 total)
That's just what I was going to point out. I even went & checked it in BOL.
"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
December 12, 2007 at 6:32 am
No. This wouldn't be helpful to you at all. In fact, it would probably hurt performance.
"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
December 12, 2007 at 6:22 am
You're operating under a slight misconception. FAST 'n' (or FASTFIRSTROW) doesn't give you faster response time. It gives you slower response time with the appearance of faster responses. The hint...
"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
December 12, 2007 at 5:37 am
That's certainly not a ringing endorsement. Anything in particular force the change back?
"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
December 12, 2007 at 5:31 am
Still sounds like you might want to try out VSDB.
"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
December 11, 2007 at 12:53 pm
First off, get out of the monolithic file. That's going to create headaches no matter what tool you use.
After that, talking about this stuff is almost like talking about religion...
"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
December 11, 2007 at 11:04 am
Oh, one other option, you could look at increasing the Parallelism Threshold for the server so that it's less likely to put this query into a parallel operation. That's another...
"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
December 11, 2007 at 10:58 am
What you've done with sp_getapplock is completely lock down all the resources used by all the transactions within a given connection. It's a very harsh method for eliminating deadlocks. I...
"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
December 11, 2007 at 10:55 am
Whoops. Assumptions will get you. Sorry.
BOL = Books Online. The documentation that comes with SQL Server.
If you can't modify the code directly, but you're getting this error, you may want...
"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
December 11, 2007 at 10:51 am
Well, see, I'm 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
December 11, 2007 at 9:31 am
It's basically telling you that the procedure had a high enough cost that it thought parallel execution would help. When executing in parallel, it caused a deadlock. First one I've...
"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
December 11, 2007 at 9:28 am
SriSun (12/11/2007)
Actual process: I check for @geolevel (doesn't exist), call another procedure (proc1 which takes couple of parameters along with @geolevel) and...
"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
December 11, 2007 at 9:15 am
You only want to put that stuff in as a last resort, usually because of some sort of design error, bad index, or something else that you can't spend time...
"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
December 11, 2007 at 7:01 am
What Jason said.
But remember, it's going to force the optimizer to make other choices. Every so often those other choices might work better, but then it's because the HASH join...
"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
December 11, 2007 at 6:59 am
Connect with a user that has more restricted rights to the file.
"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
December 11, 2007 at 6:39 am
Viewing 15 posts - 21,406 through 21,420 (of 22,219 total)