Viewing 15 posts - 20,461 through 20,475 (of 22,219 total)
First, you've got one index that's completely a waste (there may be more). Index 11 eliminates the need for index 7 because they both have the same leading edge. 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
May 7, 2008 at 6:46 am
Queries submitted to SQL Server go through a process called the optimizer. It makes decisions based on the data in the database as to what order to do certain processing...
"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 7, 2008 at 6:39 am
No, each one is executed serially. Maybe the first one is holding a transaction open?
"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 7, 2008 at 6:34 am
Much better query. But this part:
AND ds.LINK_ID NOT IN (Select LINK_ID from Demography_Summary where PRAC_ID IS NULL)
Again could be written as an OUTER JOIN. That's possibly your issue right there....
"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 7, 2008 at 6:28 am
Not knowing your structure I can't rewrite the query myself, but I suspect the issue is you've got a join that's preventing you from eleminating the NULL values. Instead 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
May 7, 2008 at 6:15 am
Are you able to select data from the tables in SQL Server using Management Studio? If so, the error is on the Sybase side.
"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 7, 2008 at 6:10 am
Here's a pretty basic intro to Try/Catch[/url].
"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 7, 2008 at 6:08 am
That depends. It could be that it's returned to an application as a result set and then run as a script by the app. It could be that it gets...
"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 7, 2008 at 6:06 am
We pretty much rely on the application side checks after a successful restore. As you point out, restoring successfully doesn't mean you restored the right thing successfully. DBCC and other...
"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 7, 2008 at 6:03 am
No, no, no. Jeff's smarter and better looking. I'm.... uh, I'm.... Hey!
"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 7, 2008 at 5:57 am
I've been staying out of this one, but I have to agree with Jeff. The more you practice writing set based queries the easier they get. Add to that the...
"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 7, 2008 at 5:52 am
Don't substitute table variables for temp tables unless your data sets are very small. Table variables don't have statistics generated against them (except when they have a primary key 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
May 7, 2008 at 5:47 am
I'll have you know I'm down to 203 and at 6'1" that's not big, just a tad plump. It's sitting on my brain all day long that causes the problems....
"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 6, 2008 at 1:25 pm
Everything already stated is very true. Code, tables and indexes are going to be your worst problems. However, you can be sure that you've identified the really simple stuff if...
"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 6, 2008 at 12:34 pm
I should be too embarassed to reply, but what the heck...
Scans are usually bad, but not always. Depending on the scan itself, it means it's reading all, or a substantial...
"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 6, 2008 at 12:29 pm
Viewing 15 posts - 20,461 through 20,475 (of 22,219 total)