Viewing 15 posts - 20,086 through 20,100 (of 22,220 total)
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
Sounds like it could be parameter sniffing. Check the execution plans to see if they're changing between the non-parameratized values and the parameratized values. You can try a couple 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
June 23, 2008 at 8:19 am
And, deadlocks are an error that can be captured with a TRY/CATCH statement in TSQL. You can try resubmitting the query a certain number of times before you finally give...
"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:12 am
The proc cache is your bestest buddy. Why on earth do you want it cleared out all the time? What problem are you trying to solve?
"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:10 am
Gail's 100% on the money here.
If you just look at the differences you can see why. A view is simply a select statement kept around in a way that sort...
"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:07 am
Viewing 15 posts - 20,086 through 20,100 (of 22,220 total)