Viewing 15 posts - 19,141 through 19,155 (of 22,219 total)
You've got a scan going against 6 million rows and returning nothing. That's a problem.
I'd suggest checking the indexes on COI_AppDb. Also, the <> construct can cause problems with index...
"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 8, 2008 at 6:40 am
I'm not sure. I do know that the construct where you're using 'SELECT... (SELECT..) + (SELECT...)' is a bit odd and not how I would have done it. As 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
December 7, 2008 at 7:41 am
sqlguy (12/6/2008)
I knew about using an index to prevent a table scan. What are the most common causes of index scans and how can these be resolved?
I'm not sure...
"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 7, 2008 at 7:30 am
JOINs are pretty much by definition going to be predicated on the PK, an FK or an alternate key that can function as linking mechanism for an FK. You can...
"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 7, 2008 at 7:24 am
The second solution is better. The first is going to set up weird relationships. It'll be difficult to query against and hard to maintain. The second solution will make 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 6, 2008 at 4:55 am
Itzik Ben-Gan just released a new book on TSQL Fundamentals. I can recommend that. Once you've got the fundamentals down, you might want to get his book called Inside Tsql...
"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 6, 2008 at 4:52 am
You might want to pick up a copy of Itzik Ben-Gan's Inside SQL Server TSQL Querying. You're missing out on some core logical constructs as to how TSQL works 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 6, 2008 at 4:49 am
It's not anything I've heard of before.
"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 6, 2008 at 4:43 am
I guess I need to go back to those 25 table joins that are running in under 50ms and start adding temp tables...
Nah. I'll stick with getting indexing right, 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 6, 2008 at 4:41 am
You're getting an error, as you stated above:
However when this query is executed it never completes, eventually failing with a message "8623: The query processor ran out of internal resources...
"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 6, 2008 at 4:25 am
Oooh! Nice trick. I never knew about that one. Sweet.
And yes, '%y%' won't use an index. If you think about it logically, it makes sense. An index stores the key...
"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 6, 2008 at 4:15 am
I've got two systems that we're trying it out on. The first one was getting lots of deadlocks. We know why, but we're not allowed to modify the code... Don'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
December 5, 2008 at 12:05 pm
Actually, I meant:
It is also pretty lazy ...
I thought you summed it up nicely with those five.
"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 5, 2008 at 11:42 am
sqlguy (12/5/2008)
OK - Let's say, for example, that the where clause has conditions where personid = x or lastname like %y%. What type of indexing would you use?
If 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
December 5, 2008 at 11:37 am
You might want to be more lazy. You only needed five words in that last sentence.
"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 5, 2008 at 11:23 am
Viewing 15 posts - 19,141 through 19,155 (of 22,219 total)