Viewing 15 posts - 9,136 through 9,150 (of 22,224 total)
The code looks to me like it will be likely to use that index. Have you checked the execution plan to see what it is doing?
"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 6, 2014 at 4:19 am
What changed on the machine? It's unlikely that the server instance just suddenly decided to stop working. Surely something lead to the initial problem. I'd look there to figure out...
"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 6, 2014 at 3:48 am
If the process you're currently using has a command line, try using PowerShell. You can fire a powershell command right from SQL Agent.
"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 5, 2014 at 2:09 pm
Not a problem.
Just so you know, I cheated in figuring out what was up. I used Red Gate SQL Prompt. It's a software my company makes. It's invaluable when working...
"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 4, 2014 at 1:02 pm
You were missing a parenthesis after the first date operation. You don't need all those parentheses. You can have it just like this:
SELECT [displaydate],
...
"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 4, 2014 at 12:41 pm
The first query is an old style ANSI 89 syntax join with the join criteria in the WHERE clause. The second is a modern style join with the join criteria...
"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 4, 2014 at 4:00 am
Since you know the specific query, your job got easier. You want to look at the code to ensure it's not using functions on columns in the WHERE clause 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
January 4, 2014 at 3:50 am
The single, dead-last thing I would do is utterly preempt the optimizer in that fashion, especially with an undocumented DBCC command. Code, indexes, statistics, statistics, statistics, would all get more...
"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 4, 2014 at 3:34 am
Yep, if you're capturing both start and stop, you could span files.
"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 4, 2014 at 3:27 am
You need to purchase a license from Microsoft. You may then need to reinstall that software after you get the fully licensed copy.
"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 4, 2014 at 3:26 am
I was thinking it could be parallel processes. That would show why you couldn't see the statement and plan on all of them.
"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 4, 2014 at 3:20 am
SELECT queries alone will not cause deadlocks. There has to be data modification queries built in there somewhere.
"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 4, 2014 at 3:19 am
Do you notice if there are other entrees for the same session_id?
"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 3, 2014 at 9:57 am
The deadlock is probably being caused by multiple slow points, not just the select statement. I'd suggest getting the execution plans for the two queries involved in the deadlock 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
January 3, 2014 at 9:57 am
ramana3327 (1/3/2014)
Thanks for the replies.
I am able to create a user defined data collector from a template or create a custom collection but I am not able define this...
"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 3, 2014 at 7:39 am
Viewing 15 posts - 9,136 through 9,150 (of 22,224 total)