Viewing 15 posts - 16,996 through 17,010 (of 22,226 total)
TheSQLGuru (7/16/2009)
I think we will have to disagree on this one. I estimate that 90+% of the time a user has a query with a date range comparison to...
"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
July 16, 2009 at 9:30 am
I don't know that I'd recommend recompiling out of hand. The execution plan using a parameter is going to sample the appropriate indexes and arrive at a generic "best" plan....
"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
July 16, 2009 at 8:38 am
Jeff Moden (7/16/2009)
Could it be that the problem is being caused by non-deterministic functions?
Yeah, that's basically it, but it's hard to tell someone exactly why one function turns out like...
"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
July 16, 2009 at 8:23 am
I would strongly recommend you use the OUTPUT clause instead of triggers. Not least because, i think, you won't have access to the identity values inside the trigger.
OUTPUT is pretty...
"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
July 16, 2009 at 8:06 am
Most of the time, when I'm observing client statements in trace events, I see the parameter values on stored procedure calls. And if I run a batch that looks like...
"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
July 16, 2009 at 7:56 am
I'd add a step to design the clustered indexes. They should be part of the fundamental decisions around the database design.
"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
July 16, 2009 at 7:44 am
They're not visible in the textdata column?
"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
July 16, 2009 at 7:43 am
I'd treat it like any other system. Put an index maintenance routine in place that reindexes or reorgs the indexes as needed based on their size and fragmentation levels. Because...
"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
July 16, 2009 at 7:42 am
Exactly. That's why I was trying to clarify the question asked. If I saw more than 4 or 5 indexes I think I'd be quite concerned. 249 would positively freak...
"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
July 16, 2009 at 7:31 am
Checking out the plans, the first thing I'm noticing is that the estimated rows are pretty different. 1 for the slow plan and 584 for the fast plan. That tells...
"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
July 16, 2009 at 7:28 am
Jeff Moden (7/16/2009)
Grant Fritchey (7/16/2009)
Jeff Moden (7/15/2009)
Grant Fritchey (7/15/2009)
J.D. Gonzalez (7/15/2009)
Execution plans attached.
I'm sorry, but can you zip those up & reattach them. I'm having a hard time getting them...
"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
July 16, 2009 at 6:56 am
Yeah, you can just leave that as is. You don't need to add another transaction to it.
It's an update statement and it's within a distributed transaction, so yeah, you're going...
"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
July 16, 2009 at 6:50 am
As far as I know, it's just a limit. In SQL Server 2008, the limit is 999.
Was he asking why you would not want that many indexes? Or was he...
"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
July 16, 2009 at 6:44 am
Inserts will absolutely be slower. There's no way to get around the fact that you'll have to udpate the index as part of the insert. So, as previously stated, you...
"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
July 16, 2009 at 6:12 am
The variable can only be loaded once. So it's going to be set a single time and then when you reference it in the second select statement it will only...
"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
July 16, 2009 at 6:07 am
Viewing 15 posts - 16,996 through 17,010 (of 22,226 total)