September 18, 2013 at 10:05 am
The issue occurred last week on 9/9/2013. First email received at 1:20pm EST. Last email received at 1:45pm EST.
During that time, we received Application Error emails with the Traces referencing the following message:
“The HTTP request to 'https://xyz.com/xyz.svc' has exceeded the allotted timeout of 00:02:00.”
The purpose of this review is to see if we find what causes the service to timeout before the errors occur. In the logs we saw the same call take milliseconds at one point and then drastically jumps to 7+ minutes without any clear indication why. We need your help to start looking a few minutes before 1:20pm EST (maybe 10-15 mins. before) to see if we have Locking or other issues occurring which could cause the issue.
This was the issue from one of my fellow team member I fount that for that particular time frame Lock waits per min was high now I want to fetch what queries generated those locks??
Can anyone help me on this?? How to find out which queries and tables were affected? Any clues? ideas?
Sagar Sonawane
** Every DBA has his day!!:cool:
September 18, 2013 at 12:43 pm
With high lock wait times, you MIGHT have a chance by checking the system_health Extended Events session - if you are on SQL Server 2012. Because in 2012 onwards there will be 4 x 5MB files kept historical. Better rush.
Otherwise you have to wait for the next time this occurs and react much more quickly. Of course you could also set up a more extensive trace for locks.. maybe using blocked_process_report - also via Extended Events in SQL 2012 onwards. In lower versions you might have to use SQL Trace.
Andreas
---------------------------------------------------
MVP SQL Server
Microsoft Certified Master SQL Server 2008
Microsoft Certified Solutions Master Data Platform, SQL Server 2012
www.insidesql.org/blogs/andreaswolter
www.andreas-wolter.com
September 20, 2013 at 10:35 am
Andreas.Wolter (9/18/2013)
With high lock wait times, you MIGHT have a chance by checking the system_health Extended Events session - if you are on SQL Server 2012. Because in 2012 onwards there will be 4 x 5MB files kept historical. Better rush.Otherwise you have to wait for the next time this occurs and react much more quickly. Of course you could also set up a more extensive trace for locks.. maybe using blocked_process_report - also via Extended Events in SQL 2012 onwards. In lower versions you might have to use SQL Trace.
Hi Andreas... Thanks for reply.....Server is SQL 2008R2... I thought of setting up a trace in case if we need to replicate issue.... But I was looking for some without replicating same issue on Production.
Sagar Sonawane
** Every DBA has his day!!:cool:
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply