Viewing 15 posts - 20,566 through 20,580 (of 22,219 total)
Any performance degredation is not linear. Depending on how you're working with the system, there may be very little degredation at all. In the instances within the article, we were...
"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
April 27, 2008 at 8:32 pm
Personally, I would have two schema's within the same database. This will allow you to lock down one schema, but have referential integrity between the schemas where as you would...
"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
April 25, 2008 at 8:59 am
You know if you're getting different plans and different performance, you might have instances where one piece of data generates a plan that it can use and a seperate set...
"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
April 25, 2008 at 8:53 am
I think I'm losing track of the thread. Where are you with this? Have you tried changing the indexes in any of the ways that have been proposed? Have any...
"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
April 25, 2008 at 8:33 am
This is great! What a lot of fun, and really good information. I do like the DBA in traditional DBA garb doing the performance dance.
"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
April 25, 2008 at 6:51 am
Agreed on using JOIN statements instead of IN statements.
Do you really need the DISTINCT? That's usually added when the data is bad, the structure is bad, or the where clauses...
"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
April 25, 2008 at 6:34 am
Unless they're they're the only things in the field, then you could get away with:
SELECT...
FROM...
WHERE MyField = 'Project Managers Book'
OR MyField = 'The Project Book'
...
"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
April 25, 2008 at 6:01 am
There was a time when I was recommending using this code to eliminate dynamic SQL and still have a multi-valued search query:
SELECT....
FROM....
WHERE...
AND CASE WHEN @LocationTypeId...
"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
April 25, 2008 at 5:58 am
For literally the same index, COLA, COLB and COLA, COLB, no, I can't support that. I'd even say that's unsupportable if the first one was clustered and the second one...
"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
April 25, 2008 at 5:47 am
Have you looked at the execution plans for the those specific queries? Scans, hash joins, cursors, anything like that in evidence?
"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
April 25, 2008 at 5:39 am
We might just fit right in...
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
April 24, 2008 at 1:26 pm
{click-whoosh}{click-whossh} I am the master now, Andy {click-whoosh}
Anyway, I finished running the simple tests. Here's a question given the following table & query, what might happen?
CREATE TABLE [dbo].[users](
[LogonID] [nvarchar](20) NOT...
"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
April 24, 2008 at 1:16 pm
Funny you should say that. I'm stepping through writing up samples in C# using nHibernate as I type this (well, right after I type this and right before). So far,...
"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
April 24, 2008 at 11:47 am
Yep. You're in trouble now. I still haven't been able to get it fixed. A friend ripped out everything, including all references in the registry, and reinstalled 2005. He's running...
"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
April 24, 2008 at 11:08 am
Oh, then it's not a covering index. Try adding the date column. It will be then.
"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
April 24, 2008 at 11:05 am
Viewing 15 posts - 20,566 through 20,580 (of 22,219 total)