Viewing 15 posts - 7,096 through 7,110 (of 22,226 total)
Good gosh, don't do option 1. That will put additional stress on your production system, removing memory, fighting for CPU and disk access. No. Option 2 is pretty much 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
December 11, 2014 at 8:37 am
Yes. You're going to want to have that date value as a date. Otherwise, you'll have to parse that string and it will prevent index and statistics use leading to...
"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 11, 2014 at 8:26 am
Glad to hear the solution. I was also going to suggest looking into bad parameter sniffing, but it's probably just the stats.
"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 11, 2014 at 8:22 am
Don't do it.
Instead, give them permissions to create extended events[/url]. It's much more lightweight and much less fear of bringing down a production system.
"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 11, 2014 at 8:20 am
No, I'm pretty sure that's a code issue. They're not cleanly disconnecting.
"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 11, 2014 at 6:57 am
Run a query against sys.dm_os_wait_stats before and after running the query. It'll give you a pretty good idea what the query is waiting on.
Also, when you're running queries against sys.dm_exec_requests...
"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 11, 2014 at 6:56 am
You need to check the condition of the server when you're getting the timeouts. Are there lots of connections, or only a few. Of those connections, are any blocked or...
"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 10, 2014 at 8:58 pm
It depends on how your virtual environment is set up and managed. Many of them use physical storage, not virtual storage. In fact, a pretty hefty percentage are set up...
"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 10, 2014 at 3:56 pm
Alvin Ramard (12/10/2014)
Koen Verbeeck (12/10/2014)
Grant Fritchey (12/10/2014)
"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 10, 2014 at 3:54 pm
OK. That certainly makes more sense now. Yeah, I'd go with a derived table of some kind (doesn't have to be a CTE, but no reason not to) to get...
"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 10, 2014 at 3:53 pm
Other than to allow for the use of the MAX field, why are you grouping this data anyway? From the example, you're running no other aggregations.
"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 10, 2014 at 10:30 am
Without seeing the plans, I'm speculating. But, if the data sets are radically different between the two servers, that might explain it. If the cost threshold for parallelism is different....
"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 10, 2014 at 10:24 am
JoshDBGuy (12/10/2014)
Grant Fritchey (12/10/2014)
"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 10, 2014 at 10:21 am
Weirdest thing, my subscription to The Thread got turned off. I just figured after a couple of weeks you guys had finally given up on this thing.
"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 10, 2014 at 8:17 am
Yep. Tell them to stop. Unless of course they're also responsible for running the restores. In which case, check to see if they're running differentials and log backups and have...
"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 10, 2014 at 8:02 am
Viewing 15 posts - 7,096 through 7,110 (of 22,226 total)