I have a bit a funny situation. Our Azure SQL instance maxes out at 100 DTU for a certain query and the query returns a timeout:
SqlException (0x80131904): Timeout expired. The timeout period
elapsed prior to completion of the operation or the server is not
responding. This failure occurred while attempting to connect to the
routing destination.
If I run exactly the same query (with the parameters hardcoded) in SQL Server Management Studio it still takes the DTU up to 25%, but that's still far away from 100%. Nothing else runs on that server. There are a few other queries that run before/after. But if we just run them, nothing spikes out.
Any ideas?
My analysis of the issue goes like this..
First when DTU's are maxed out and if a query fails due to that,you will not get time out..Below is the error message you will get..
Resource ID: %d. The %s limit for the database is %d and has been reached. For more information
You can try testing that by opening multiple resource intensive queries
Secondly when you get time out's as indicated in your question,this is mostly due to query waiting for resources like say some database IO,memory..
we faced similar time out's ,but most of them are fixed by updating stats and rebuilding indexes,rest of them we optimized
Related
we have jobs in sql agent runnig schedually. We know at least about one job (scheduled every day at three different times - morning, afternoon, night) which rarely (apx one per several months) fires/runs twice in same time (like a parallel). But it is scheduled only one time in same moment. Job runs CLR stored procedure which launch console application which process some getting data and recalculating
This behaviour causes problems for us.
Why?
How could it happend?
Where is problem?
But where is reason?
Thank you for all ideas.
(Of course, we should handle it and prevent this behaviour.)
I found error in job history according to time of job execution - error 6535.
This error appears twice for this job iteration. Firstly without addtional message, secondly with additional message "The step suceeded". When I looking for information about his error 6535 - i found that this error occurs on sql server 2005, but due to select ##version, the customer use sql server 2008 R2
Context: SSAS 2005. I run a MDX query in SSMS, the query will throw error 'The operation has been cancelled.' whenever the execution time reaches 50 seconds (or 49 seconds, 48 seconds some times). I have already set ServerTimeOut to 0 and restarted the SSAS server. Any idea? I googled a bit and I am sure there is no processing when the query is running. In SQL Profiler I can only see an error event with the same information as in the SSMS. The log file has nothing recorded regarding this. But I do see the memory going up all the way until the query fails. Any idea?
Update
Ok it turns out I didn't set a relationship between a dimension and a measure group. I am not 100% clear about the issue but not it's sure it's not related to server properties nor processing while executing the query.
In My Console application. i am checking media links which is available in my database through openstream.but one error is raising again and again in diffrent diffrent point.that is "Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. The statement has been terminated"
These 2 similar problems/solutions might give you some ideas.
One was fragmented table and the other was a lock by another db operation.
http://forums.asp.net/t/1513085.aspx/1/10
SQL Server simple Insert statement times out
We have the production server database and Widnows Client project. Suddenly we are getting this error while querying the database.
"The timeout period elapsed prior to completion of the operation or the server is not responding"
How can we resolve this from Database side/ C# Windows ?
Thanks,
Velusamy
The quick-and-dirty answer: set SqlCommand.CommandTimeout to a higher value.
The long answer:
Run the query in SSMS with "Show actual execution plan" turned on. Check the result for index hints.
Check your database server logs for suspicious events
Verify that statistics are not out of date
This query shows the age of statistics:
SELECT Object_Name(ind.object_id)
, ind.name
, STATS_DATE(ind.object_id, ind.index_id)
FROM SYS.INDEXES ind
The query optimizer uses statistics when it chooses how to execute a query. If the statistics are old, it can make (really) bad choices.
What would cause a query being done in Management Studio to get suspended?
I perform a simple select top 60000 from a table (which has 11 million rows) and the results come back within a sec or two.
I change the query to top 70000 and the results take up to 40 min.
From doing a bit of searching on another but related issue I came across someone using DBCC FREEPROCCACHE to fix it.
I run DBCC FREEPROCCACHE and then redo the query for 70000 and it seemmed to work.
However, the issue still occurs with a different query.
I increase to say 90000 or if I try to open the table using [Right->Open Table], it pulls about 8000 records and stops.
Checking the activity log for when I do the Open Table shows the session has been suspended with a wait type of "Async_Network_IO". For the session running the select of 90000 the status is "Sleeping", this is the same status for the above select 70000 query which did return but in 45min. It is strange to me that the status shows "Sleeping" and it does not appear to be changing to "Runable" (I have the activiy monitor refreshing ever 30sec).
Additional notes:
I am not running both the Open Table and select 90000 at the same time. All queries are done one at a time.
I am running 32bit SQL Server 2005 SP2 CU9. I tried upgrading to SP3 but ran into install failurs. The issues was occuring prior to me trying this upgrade.
Server setup is an Active/Active cluster the issue occurs on either node, and the other instance does not have this issue.
I have ~20 other database on this same server instance but only this one DB is seeing the issue.
This database gets fairly large. It is currently at 76756.19MB. Data file is 11,513MB.
I am logged in locally on the Server box using Remote Desktop.
The wait type "Async_Network_IO" means that its waiting for the client to retrieve the result set as SQL Server's network buffer is full. Why your client isn't picking up the data in a timely manner I can't say.
The other case it can happen is with linked servers when SQL Server is querying a remote table, in this case SQL Server is waiting for the remote server to respond.
Something worth looking at is virus scanners, if they are monitoring network connections sometimes they can get lagged, its often apparent by them hogging all the CPU.
Suspended means it is waiting on a resource and will resume when it gets its resource. Judging from the sizes you are pulling back, it seems you are in an OLAP type of query.
Try the following things:
Use NOLOCK or set the TRANSACTION ISOLATION LEVEL at the top of the query
Check your execution plan and tune the query to be more efficient