I have one stored procedure in SQl Azure is calling periodically at 5 minutes and processing crore of data and it sometimes give Timeout error as per below as per my log.
Timeout expired. The timeout period elapsed prior to completion of
the operation or the server is not responding.
How can i increase Timeout of this query or whole Db? and what would be default Timeout?
Update
I think Time out is not due to connection to sql azure here as per answers of #Ming and #Ruchit because when i have checked the log then below error it will display message like
Warning: Null value is eliminated by an aggregate or other SET
operation.
It means query is being executed, above message because of i have used some aggregate function on NULL value. Am i thinking correct? what should be other possible cause?
Thanks in Advance.
According to http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7070c2f9-07d1-4935-82c2-b74a196908ee/, SQL Azure will close idle connections that are longer than 5 minutes. As you mentioned you’re calling the stored procedure every 5 minutes, thus you may be on the edge of timeout. I would like to suggest you to change to every 4 minutes to see whether it works.
In addition, when using SQL Azure, retry is very important. When a query fails, please close the connection, wait for a few seconds, and then create a new connection, try the query again. Usually the second time will work fine.
Best Regards,
Ming Xu.
Ming Xu is right. the cause of the error is most probably the 5 minute timeout.
If you can not change the time period to call the stored procedure, one option is to make dummy call to SQL Azure every 3 or 4 mins. This will keep the connection from being closed.
Related
I am randomly getting execution timeout expired error using the Entity Framework (EF6). At the time of executing the below update command it gives randomly execution timeout error.
UPDATE [dbo].[EmployeeTable] SET [Name]=#0,[JoiningDate]=#1 WHERE
([EmpId]=#2)
The above update command is simple and it takes 2-5 seconds to update the EmployeeTable. But sometime the same update query takes 40-50 seconds and leads the error as
Execution Timeout Expired. The timeout period elapsed prior to
completion of the operation or the server is not responding. the
statement has been terminated
.
For that I updated my code inside constructor of MyApplicationContext class can be changed to include the following property
this.Database.CommandTimeout = 180;
The above command should resolve my timeout issue. But I can’t find out the root cause of that issue.
For my understanding this type of timeout issue can have three causes;
There's a deadlock somewhere
The database's statistics and/or query plan cache are incorrect
The query is too complex and needs to be tuned
Can you please tell me what the main root cause of that error is?
This query:
UPDATE [dbo].[EmployeeTable]
SET [Name] = #0,
[JoiningDate] = #1
WHERE ([EmpId]=#2);
Should not normally take 2 seconds. It is (presumably) updating a single row and that is not a 2-second operation, even on a pretty large table. Do you have an index on EmployeeTable(EmpId)? If not, that would explain the 2 seconds as well as the potential for deadlock.
If you do have an index, this perhaps something else is going on. One place to look is for any triggers on the table.
If it's random, maybe something else is accessing the database while your application is updating rows.
We got the same exact issue. In our case, the root cause was BO reports being run on the production database. These reports were locking rows and causing timeouts in our applications (randomly since these reports were executed on demand).
Other things that you might want to check:
Do you have complex triggers on your table ?
Does all foreign keys used in your table are indexed in the foreign tables ?
Why below error comes?
System.Data.SqlClient.SqlException Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding
You should normally try to write fast sql (<100ms) otherwise your application will be sluggish for the end users.
If your server reply in time when you send the request manually,
There may be a read lock on a table and the second query keep on waiting for the read lock to end before processing.
In that case try to add WITH(NOLOCK) or WITH(READUNCOMMITTED) to your select statement.
Acccording to your situation and err msg, I think it may be caused by mainly two reasons:
Long running tasks：In default SQL Connection will wait for 30 seconds, but over this time, if you still cannot connect to the db, the kind of error will be thrown out.
For the second reason, that there might be an uncommitted transaction.
Of course, you should Close Connnection at a time when you don't want to use it (using…… statement is recommanded)
See more about this kind of issue, you can refer to:
http://blogs.msdn.com/b/spike/archive/2008/07/31/timeout-expired-the-timeout-period-elapsed-prior-to-completion-of-the-operation-or-the-server-is-not-responding.aspx
I'm starting to use the transient fault block provided by Microsoft for SQL Azure and I'm noticing that some of my functions which have a transient handled block may have reference to other functions with this block also.
I am guessing that the retry wait time will then compound?
What you mean by retry time will then compound?
Each query to the SQL Database is executed with its own Retry Logic. If you have a method or a function call that executes 10 Queries, each one of these 10 Queries will execute with respective retry logic.
If there is transient error while executing just one of the queries. Then wait time will be that wait time. If there is transient error during execution of more than one query, then wait time will be sum of all wait times occurred during execution.
However the transient errors are what their name suggests - transient. It is very unlikely that you will encounter a transient error for more than query executed in consecutive order. But if it happens, then yes - the wait times will sum up. However if you execute queries in parallel, or asynchronously, then you don't really sum up wait times.
And finally, retry policy for one query execution, does not affect retry policy for other query execution.
I have written a stored procedure which retrieves more than 7000 rows. While executing the stored procedure in my VB.NET winforms application, I'm getting an error like as follows.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
I googled and tried like using these lines of codes which wasn't useful.
sqlCmd.CommandTimeout = 0
sqlCmd = New SqlCommand("waitfor delay '00:00:60'")
Please help me with this.
There are multiple places you can be experiencing a timeout. Some things to try.
Run the stored procedure with the exact same parameters in Sql Management Studio. How many seconds does it take? This will give you an idea of how long you need your timeout to be. If it takes more than 30-60 seconds, consider revising your sql, added indexes and otherwise tune your database.
CommandTimeout - This is the timeout for your particular command. You should avoid setting it to 0, although this may work, http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx
ConnectionTimeout - This is the timeout property for your entire connection. If this is less then your CommandTimeout it will override. Again, 0 should be avoided here. http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectiontimeout.aspx
You should increase the commandTimeOut and not put it 0.
Try to put the value 60, which means 1 minute.
It is not advisable to set your timeout to 0. The remaining answer would be only to increase the limit BUT..
Increasing the timeout is like a band-aid solution. What if you have a longer query? Will you just increase the timeout again?
To solve this, please refer to my answer here..
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding
Our application executes a long, hairy stored procedure with multiple result sets. The users are experiencing long wait times for this query, so I set out to determine what is causing the delay.
I put a Stopwatch on executing and reading the data, and it takes 6-7 seconds each time. I timed the execution of the stored procedure, expecting that this would be taking all the time. It wasn't - it took 30ms or so.
So I put timers around each of the ~20 result sets. Each "block" took very little time ( < 10ms) except for one in the middle of the processing, which took 5-6 seconds. Upon further research, I discovered it was the "reader.NextResult()" call that took all the time. This long delay happens in the same spot each time.
If I just exec the stored procedure, it seems to run real snappy, so it doesn't APPEAR to be a problem with the query - but I don't know...
How do I interpret this? Is SQL shipping me the result sets as it gets them, and is the result set in question likely to be a problem area in my SQL query? Or is something else possibly causing the delay?
EDIT:
Thanks for the answer and the comments - I am using SQL Server and .NET
What I was most curious about was WHY my delay happens on the "NextResult()" call. Being new to SQL development, I assumed that a delay due to a long stored procedure execution would show up in my application while waiting for the "ExecuteReader()" call to return. It now seems that SQL will start returning data BEFORE the query is complete, and if there is a delay it will delay on the NextResult() call.
I started out thinking my delay was in the stored procedure. When the ExecuteReader() call came back quickly, I thought my delay was in my code's handling of the reader. When the delay ended up being on the NextResult() call, I was confused. I am now back to reviewing the stored procedure.
Thanks to those of you who took the time to review my problem and offered your help.
When you execute a stored proc from a .Net command, the results will start streaming as soon as SQL has them ready.
This means that you may start seeing results in your .Net app before the entire stored proc has been executed.
Your bottleneck is probably in the stored procedure, run a sql server trace, and trace all the statements running inside the stored procedure (get the durations). You will be able to track down the exact statement in the proc that is slow and you also will be able to pick up on the params that are being passed to the proc so you can test this in Query Analyzer and look at the plan.
Another point that is missing from the question seems to be the amount of data you are moving, though unlikely, it may be that you have some really large chunks of data (like blobs) that are being sent and the time is being spent on the wire. You really need to expand the question a bit to help with the diagnosis.
The answer will be dependent on what RDBMS you are using.
If its SQL Server and .NET then from my experience:
Check other open transactions on the same connection which is used to invoke the sproc. They may have row locks on the table one of your selects is executing against. You can try adding "MultipleActiveResultSets=false" to your SQL Server connection string and see if you get an improvement, or more likely an exception (and you can hunt down the problem from an exception). This can also be an effect from an unreset connection returned to the connection pool (something I've ran into since I've started to use MARS).
You may need to specify the NOLOCK (or READUNCOMMITTED, same thing) table hint in your SELECT query if dirty reads are acceptible.
SELECT * FROM [table] WITH NOLOCK