Is it possible to limit the amount of time SQL Server takes to query a database?
Having the program returning all results that fit the query that it could find in the time frame?
Ok, this is my opinion about this question:
Please do not do this to your database. Perhaps you could play with the timeout on a connection level and stream results asap, however... if your database is that big, I guess it's important. Do not abuse your infrastructure like this...
Consider limiting the number of results (SELECT TOP <rows> * FROM ...)
Or use some other sort of (virtual) paging. Again: do not abuse the connection timeout on purpose...
No sql server does this, it's possible to configure a job that will make a kill process with a long lead time, but this is all very wrong. For this use sys.dm_exec_query_stats
https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-query-stats-transact-sql
But this is a very wrong tactic
If you're writing a web application for example you can specify command timeout. This will send a kill signal for the query when the timeout expires. The kill signal is not handled immediately by the SQL engine but during the next opportunity.
Background Information
I found a bug in some code we have where a function connects to a postgresql database, but then "returns" out of it before closing the database connection.
This issue was only caught because at one point, we had a huge number of concurrent connections that exceeded the MAX_CONNECTIONS value and I found a bunch of "idle" records in the pg_stat_activity table
'Question
I only see these idle connections if I create a load on the database by looping in my script and calling this function a bunch of times...
Meaning, if I use the buggy code that doesn't close the db, and connect once, I don't see any "idle" records in the pg_stat_activity table. Mind you, it takes me a second or two to switch between the window that is running the script and the one that has the psql client running.
So here are my questions.
What's the best way to track idle connections? Am I using the right approach?
After the postgresql session selects the data I've requested and returns it to the client, how long does it wait before killing idle sessions? Or, are these idle records getting killed off when my script has finished running through all its logic?
I've tried using TCP keep alives with very low values just in case that's relevant... and I get the same results.
If my question is not clear enough, please let me know and I will revise.
Thanks
We are having multi server and multi DB instances in EC2. In one of the Server we have the Main DB(Master DB), but in other servers we have only the Transaction DB's. We are using SQL linked server to connect everything.
Initially there was no problem with my infrastructure. But now as the data load increased, am often getting Time Out expired error even for an normal select query.
Its not for all the processes. If there are 500 processes running in a particular server, in that at-least 200 processes are throwing this Time out expired error.
Recently, I moved all my servers into VPC.
Note:
All my queries will be running only from Master DB because only master DB knows what transaction DB is connected to respective transaction requests. All EC2 instances are in the same region.
Is there a solution for my problem ( time out error exception ). Kindly help me with your suggestions. This is really turning out into an critical business affecting issue.
Error Msg:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Since it worked fine before and started to fail with as load increased, sounds like you are running out or resources (mostly hardware). There are two things to do:
1) Buy more hardware;
2) Tunning your queries to do more work with less (hardware).
The first thing is (maybe) cheaper. To tuning your DB it ill take a lot of time for learning and test out whatever you learn.
I suggest you to get the hard way and try to optimize your queries/isolation level/schema etc.
I have a web application that occasionally will throw this error….
Exception message: Timeout expired.
The timeout period elapsed prior to
completion of the operation or the
server is not responding.
When I does I am unable to connect to SQL server, even through management studio, it’s says the server timed out and cannot connect.
As soon as I reset iis, it comes back instantly. So this obviously means it’s something in my code that’s causing this. I have an MVC site that uses Linq to SQL and SQL cache dependency with service broker enabled.
I have used the using statement thoroughly throughout the code, so im sure it’s not leaky connections. Reading through the server logs makes things more confusing as there are so many information and warning events, im not a sys admin so it’s hard to know what’s going on.
It begins with me getting an ASP.net 4.xxxxx Event ID 1309 Exception message: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. error
I think I got round it last time on my previous server by restating IIS when ever this error popped up, this is something I don’t want to resort to on this new server.
So my question is, what steps can I take to try and reduce but ideally eliminate this timeout error ?
Any help is most appreciated
Truegilly
This type of problem usually boils down to one of two things. Either you are not disposing of your connections properly or you have a number of heavy queries that are completely taking over your database server.
If you don't dispose of the connections properly then IIS will happily keep them around until garbage collection runs and/or they timeout. If you have a very lightly trafficked site then you won't see the problem.
However, once traffic reaches the point where the number of connections hanging around exceeds the number of times you are trying to make a connection to the database server.. well, you are going to start seeing one of a couple possible errors. Timeout expired is one. The exact error is going to depend on which part is falling over: the connection pool, the sql server itself, etc.
The fix you commented on is a temporary solution. As your traffic continues to increase (good problem to have) then other areas of your code are going to cause the issue to come up again.
I've got a scenario when sometimes a user selects the right parameters and makes a query which takes several minutes or more to execute. I cannot prevent him to select such a combination of parameters (it's quite legal), so I'd like to set a timeout on the query.
Note that I really want to stop the query execution itself and rollback any transactions, because otherwise it hogs up most of server resources. Add an impatient user who restarts the application and tries the combination again, and you've got a recipe for a disaster (read: SQL Server DoS).
Can this be done and how?
As far as I know, apart from setting the command or connection timeouts in the client, there is no way to change timeouts on a query by query basis in the server.
You can indeed change the default 600 seconds using sp_configure, but these are server scoped.
Humm!
did you try LOCK_TIMEOUT
Note down what it was orginally before running the query
set it for your query
after running your query set it back to original value
SET LOCK_TIMEOUT 1800;
SELECT ##LOCK_TIMEOUT AS [Lock Timeout];
I might suggest 2 things.
1)
If your query takes a lot of time because it´s using several tables that might involve locks, a quite fast solution is to run your queries with the "NoLock" hint.
Simply add Select * from YourTable WITH (NOLOCK) in all your table references an that will prevent your query to block for concurrent transactions.
2) if you want to be sure that all of your queries runs in (let´s say) less than 5 seconds, then you could add what #talha proposed, that worked sweet for me
Just add at the top of your execution
SET LOCK_TIMEOUT 5000; --5 seconds.
And that will cause that your query takes less than 5 or fail. Then you should catch the exception and rollback if needed.
Hope it helps.
In management studio you can set the timeout in seconds.
menu Tools => Options set the field and then Ok
It sounds like more of an architectual issue, and any timeout/disconnect you can do would be more or less a band-aid. This has to be solved on SQL server side, by the way of read-only replica, transaction log shipping (to give you a read-only server to connect to), replication and such. Basically you give the DMZ sql server that heavy read can go to without killing stuff. This is very common. A well-designed SQL system won't be taken down by DDoS - that'd be like a car that dies if you step on the gas.
That said, if you are at the liberty to change the code, you could guesstimate if the query is too heavy and you could either reject or return only X rows in your stored procedure. If you are mated to some reporting tool and such and can't control the SELECT it generates, you could point it to a view and then do the safety valve in the view.
Also, if up-to-the-minute freshness isn't critical and you could compromise on that, like monthly sales data, then compiling a physical table of complex joins by job to avoid complex joins might do the trick - that way everything would be sub-second per query.
It entirely depends on what you are doing, but there is always a solution. Sometimes it takes extra coding to optimize it, sometimes it takes extra money to get you the secondary read-only DB, sometimes it needs time and attention in index tuning.
So it entirely depends, but I'd start with "what can I compromise? what can I change?" and go from there.
You can set Execution time-out in seconds.
If you have just one query I don't know how to set timeout on T-SQL level.
However if you have a few queries (i.e. collecting data into temporary tables) inside stored procedure you can just control time of execution with GETDATE(), DATEDIFF() and a few INT variables storing time of execution of each part.
You can specify the connection timeout within the SQL connection string, when you connect to the database, like so:
"Data Source=localhost;Initial Catalog=database;Connect Timeout=15"
On the server level, use MSSQLMS to view the server properties, and on the Connections page you can specify the default query timeout.
I'm not quite sure that queries keep on running after the client connection has closed. Queries should not take that long either, MSSQL can handle large databases, I've worked with GB's of data on it before. Run a performance profile on the queries, prehaps some well-placed indexes could speed it up, or rewriting the query could too.
Update:
According to this list, SQL timeouts happen when waiting for attention acknowledgement from server:
Suppose you execute a command, then the command times out. When this happens the SqlClient driver sends a special 8 byte packet to the server called an attention packet. This tells the server to stop executing the current command. When we send the attention packet, we have to wait for the attention acknowledgement from the server and this can in theory take a long time and time out. You can also send this packet by calling SqlCommand.Cancel on an asynchronous SqlCommand object. This one is a special case where we use a 5 second timeout. In most cases you will never hit this one, the server is usually very responsive to attention packets because these are handled very low in the network layer.
So it seems that after the client connection times out, a signal is sent to the server to cancel the running query too.