Viewing 15 posts - 20,086 through 20,100 (of 22,224 total)
Yeah, I have to agree. A blanket statement like that is not good.
"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 30, 2008 at 6:31 am
Yes, you want to analyze the trace. A standard trace, using the defaults, will capture the execution time, I/O and CPU costs. That's what you need to look at. It's...
"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 30, 2008 at 6:08 am
Be afraid. Be very afraid.
I do the technical interviews for our team. We go through about 20-30 phone screens in order to find someone worth bringing in for an interview....
"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 30, 2008 at 6:04 am
One thing not mentioned is the use of copy & paste. We have a project that's actually, honestly, a little complex. In one place, we found we needed a query...
"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 30, 2008 at 5:39 am
Jeff Moden (6/24/2008)
jimige257 (6/24/2008)
Is it worth spending 2 hours optimizing a prodedure that works now and is needed last week? Many would say not.
And, THAT is why I tell folks...
"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 30, 2008 at 5:34 am
Convert the NOT IN statement to a LEFT JOIN and only select values where the key from the second table are NOT NULL. That's much more likely to make good...
"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 24, 2008 at 12:16 pm
You have to issue a USE statement or quantify the object names in the queries with the database name. Neither method supports using a parameter which is why all you'll...
"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 24, 2008 at 9:24 am
This will work with 2000:
SELECT
A.RetailerID,
b.RetailerIDTheirs
FROM TableA AS A
LEFT JOIN TableB AS B
ON A.RetailerID =...
"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 24, 2008 at 9:22 am
The short and long answer in this case is, it depends.
There are a lot of variables involved in this sort of thing and the right answer in one case isn't...
"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 24, 2008 at 8:39 am
Only 62 tables. We had one that was 85 and we got it to run in under 2 seconds (of course, it took 12 minutes to recompile).
But seriously, everyone else...
"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 24, 2008 at 5:35 am
I'm not sure this is what you're looking for, but maybe using the OUTPUT clause?:
INSERT INTO Person
OUTPUT PersonId INTO #Temp
.....
"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 24, 2008 at 5:28 am
There's not really fine-grained control that will allow you to manipulate the cache in that manner. I have heard of a number cache problems with the release version and SP1....
"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 24, 2008 at 5:23 am
Excellent. Thanks for reporting back what worked.
"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 24, 2008 at 5:12 am
It's a general rule that you should have a clustered index on every table (there are exceptions and exceptions to the exceptions). For detailed discussion of why this is so,...
"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 23, 2008 at 9:52 am
Yes, that's true. It won't help you bury the bodies. In fact, it usually digs them up, like a dog. Traitors!
"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 23, 2008 at 8:29 am
Viewing 15 posts - 20,086 through 20,100 (of 22,224 total)