Viewing 15 posts - 21,421 through 21,435 (of 22,232 total)
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
You wanted four rows instead of three, right? Try this:
select typeId, trypename, typeInfoDesc
from types t left join typeinfo ti
on t.typeId = ti.typeInfoId
AND typeinfoId2 = @infoNr
"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:37 am
In a case like this, use the tool above or, if you want to roll your own, SMO (SQL Management Objects) allows you generate SQL scripts by object or for...
"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:05 am
Viewing 15 posts - 21,421 through 21,435 (of 22,232 total)