Viewing 15 posts - 20,371 through 20,385 (of 22,219 total)
Two things, get an index on the tables, especially a clustered index. Put that on the most likely access path, meaning, if they always select by PK, on the PK...
"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
May 20, 2008 at 10:52 am
Problem is, in our shop, the developers jumped on it with both feet. It's everywhere. We're slowly backing it out. We get a lot resistance because using it allows 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
May 20, 2008 at 10:39 am
The OUTPUT is an identifier for the trace you just created. You need to capture it as part of the execution, but you don't need to keep it unless 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
May 20, 2008 at 9:07 am
I'd definately check the execution plan on that. It might be easy to write and maintain, but I suspect it's doing multiple table scans. That's going to hurt, a lot.
"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
May 20, 2008 at 9:00 am
Well, don't be stingy, show your solution.
"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
May 20, 2008 at 6:50 am
First, look up JOIN syntax in the Books Online. You're using ANSI 89 syntax. Most database systems support ANSI 92 or better.
You must have more than one row in 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
May 20, 2008 at 6:47 am
Sorry I wasn't clear. I agreed with the outer join approach, assuming your indexes support it.
"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
May 20, 2008 at 6:39 am
Holy cow! You guys posted all that in the time it took me to read the first couple of posts. Slow down doggone it. You're making me look more stupid...
"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
May 20, 2008 at 6:36 am
You set a stop time as part of the trace definition. That will stop the trace automatically for you.
From the BOL:
sp_trace_create [ @traceid = ] trace_id OUTPUT
...
"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
May 20, 2008 at 6:29 am
Sandy (5/20/2008)
But your query is working fine, No issue on that but it may raise a performance issue if the table is large.
Not if it's working off a good 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
May 20, 2008 at 6:22 am
It sure looks like you could just use the ROW_NUMBER function to get the incremental counts that you want instead of looping through with a cursor or a WHILE loop...
"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
May 20, 2008 at 6:19 am
Nice one AJ.
"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
May 20, 2008 at 5:45 am
After you recover and you set up new backup routines, in addition to msdb, be sure to backup the master database too.
Good luck.
"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
May 20, 2008 at 1:06 am
From what I've seen in the past with duplicate indexes, the optimizer will just pick one. To realize the use of two, you'd have to have an index hint forcing...
"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
May 19, 2008 at 12:45 pm
Itzik Ben-Gan gave a presentation last year at the PASS summit that showed the same query getting different results with very small data sets, all because of NOLOCK. It really...
"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
May 19, 2008 at 11:17 am
Viewing 15 posts - 20,371 through 20,385 (of 22,219 total)