Viewing 15 posts - 9,046 through 9,060 (of 22,219 total)
sys.dm_exec_requests is my bestest buddy in the whole world. It's my go to position for this type of scenario. Assuming no long running query or blocking scenario, I might expand...
"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
January 19, 2014 at 4:03 am
Further, it's completely dependent on a number of factors that you haven't outlined. You're not comparing apples to apples in this question.
"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
January 19, 2014 at 4:01 am
Remember, while it has the word "table" in the definition of Common Table Expression, a CTE is nothing but a query. It's not a table. Comparing it to a temp...
"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
January 19, 2014 at 4:00 am
Sure. You can. I'd be cautious about adding unique indexes because if you don't have a matching constraint on the other side, you could get incorrect data input and 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
January 19, 2014 at 3:54 am
Jeff has already addressed question 1. On question 2, yeah, most tables ought to have a clustered index. Much of SQL Server's storage and retrieval optimizations are built around 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
January 19, 2014 at 3:49 am
There are basically two good ways to get query metrics out of the system. You can query the cache and see what's there for query performance, or you can audit...
"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
January 19, 2014 at 3:43 am
Yeah, just run a query on the server that uses RAISEERROR and the appropriate error level. Nothing else needed. It won't hurt the server or any processes on the server.
"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
January 17, 2014 at 5:57 am
Any login can have a query that causes blocking. That's just how SQL Server works. Based on what you've described, that's about all I can see. To minimize blocking, go...
"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
January 17, 2014 at 4:51 am
Looking it over, the only hope for tuning is, as was already pointed out, to eliminate the key lookup. Otherwise, we're just processing a lot of data and that's 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
January 17, 2014 at 4:49 am
Access.
But seriously, Access & ODBC and... yeah... Access.
"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
January 16, 2014 at 12:39 pm
There must be differences. No such thing as magic. Differing data sets leading to an error, maybe corruption on that database, something. Keep looking and look in and around settings...
"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
January 16, 2014 at 8:05 am
If the same code doesn't work, then I'd start checking settings. First, default ANSI settings on the server. Collation on the server and the database. Also check collation on tempdb....
"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
January 16, 2014 at 7:21 am
It's usually not a network problem, but it might be. It's usually an issue where the client code is doing row-by-row processing. There is no other wait occurring. It's literally...
"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
January 16, 2014 at 7:16 am
UNION is an aggregate function that is basically going to give you unique values. If you want to eliminate them from the query any other way, it's probably through having...
"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
January 16, 2014 at 7:03 am
And remember, those costs are just estimated values. They don't represent a literal real-world performance metric. It's just a measure of what the optimizer thinks a given operation will cost...
"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
January 16, 2014 at 7:01 am
Viewing 15 posts - 9,046 through 9,060 (of 22,219 total)