In what situation would a simple update statement
UPDATE [BasicUserTable]
SET [DateTimeCol] = '9/6/2022'
WHERE [UniqueIntPKCol] = 123
take 1m 30s to complete, AND THEN all subsequent updates using the same statement and lines of code (except for id and datetime), execute in < 100 ms?
The table has less than 10,000 records, standard int auto incrementing primary key.
Background: our app was timing out (standard 30 sec timeout) while it waited for SQL Server to execute the statement above. We manually tried the statement using SSMS on the same server, and it took ~1m 30s to execute.
Immediately afterward, all other attempts to run the same code were blazing fast as expected. We can't walk past this issue without knowing the real reason that it happened, so we can prevent it in the future.
After looking at logs, there were no apparent blocking locks on the records, nor code that could intervene an cause issue.
SQL Logs did not have any errors
Microsoft.EntityFrameworkCore.DbUpdateException
Inner exception: Microsoft.Data.SqlClient.SqlException: Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
Has anyone run into this before, or do you have a plausible working theory? (index rebuild, caching, etc.)
A lock wait is the only thing I can imagine that would cause this.
After looking at logs, there were no apparent blocking locks
Lock waits don't cause any logging. You might see logs if you configure the blocked process report, but it's not on by default.
Turning on the Query Store can help by helping track query resource utilization and waits.
Although extremely unlikely here, file growth can also cause sporadic delays, as the statement that needs the additional log file or data file space has to wait for the file to be resized.
Related
When running CREATE INDEX CONCURRENTLY, can you lock up a table while the SHARE UPDATE EXCLUSIVE is being acquired? If it took 10 minutes to acquire the lock, would anyone be blocked from using the table during that time?
The point of running CONCURRENTLY is to safely add an index to an active table. But what I can't find a clear answer on is whether the initial lock being acquired can cause queries to queue up.
The documentation for a particular safe postgres migrations library mentions (https://github.com/doctolib/safe-pg-migrations#user-content-safe_add_remove_index):
If you still get lock timeout while adding / removing indexes, it
might be for one of those reasons:
Long-running queries are active on the table. To create / remove an index, PG needs to wait for the queries that are actually running to
finish before starting the index creation / removal. The blocking
activity logger might help you to pinpoint the culprit queries.
A vacuum / autovacuum is running on the table, holding a ShareUpdateExclusiveLock, you are most likely out of luck for the
current migration, but you may try to optimize your autovacuums
settings.
But even that doesn't clearly tell me - if I don't set a timeout (so the timeout is 0), and I wait a long time for the lock to get acquired - will that cause other queries to wait until the lock is acquired or will the ADD INDEX be the only thing blocked during this time?
It will block the things that ShareUpdateExclusive blocks. But not ordinary SELECT, INSERT, UPDATE, DELETE.
The most troubling thing it blocks might be ANALYZE. If the stats get too out of date and can't be repaired, your SELECTs might start choosing ridiculous plans which never finish, despite not being formally blocked.
It does have to transiently acquire stronger locks than ShareUpdateExclusive, but if it has to wait for them it does so in an indirect way which doesn't block others.
I have a query that I've spent some time optimizing, it will normally run in less than a second. Occasionally, though, it will take a minute or two to run which causes the calling application to throw a timeout error.
It is just a report query, it's not updating. I'm using SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED.
Question: How can I tell what is blocking this query and get it fixed?
When you notice a long-running query, try this in a new query window:
exec sp_who2
Peruse the BlkBy column to see if you're getting blocked by something, then find its SPID in the left column. This will let you know the SPID of the blocker, as well as some general context about the cause of the block. If you think it advisable, you could run KILL to stop the blocking SPID, but keep in mind it will disrupt whomever initiated that query. First, you might want to check with whomever's Login or HostName is blocking.
Alternatively, if you have a cached execution plan for an expensive query, it may have expired.
If there's any particular pattern to the performance dive, that will be a helpful clue, but if it seems random, then I'd keep an eye on sp_who2 so you can fire that off when you notice it happening.
I have a SQL Server database in production and it has been live for 2 months. A while ago the web application associated with it loading takes too long time. And sometimes it says timeout occurred.
Found a quick fix by running a command 'exec sp_updatestats' will fixed the problem. But I need to be run that one consistently (for every 5 minutes).
So I created a Windows service with timer and started on server. My question is what are the root causes and possible permanent solutions? Anyone?
Here is a Most expensive query from Activity Monitor
WAITFOR(RECEIVE TOP (1) message_type_name, conversation_handle, cast(message_body AS XML) as message_body from [SqlQueryNotificationService-2eea594b-f994-43be-a5ed-d9a47837a391]), TIMEOUT #p2;
To diagnose a poorly performing queries you need to:
Identify the poorly performing query, e.g. via application logging, a SQL Profiler trace filtered to show only queries with a longer duration than a certain threshold etc...
Get an execution plan for the query
At that point you can start to try to figure out what the performance issue is.
Given that exec sp_updatestats fixes your issue it could be that statistics on certain tables are out of date (this is a pretty common cause of performance issues). If thats the case then you might be able to tweak your statistics or at least rebuild only those statistics that are causing issues.
Its worth noting that updating statistics will also cause cached execution plans to become invalid, and so its plausible that your issue is unrelated to statistics - you need to collect more information about the poorly performing queries before looking at solutions.
Your most expensive query looks like its waiting for a message, i.e. its in your list of long running queries because its designed to run for a long time, not because its expensive.
Thanks for everyone i found a solution for my issue . Its quite different I've enabled sql dependency module on my sql server by setting up enable broker on , thats the one causing timeout query so by setting it to false everything is fine working now.
I have a service which has been scheduled to run several times in a day. The service will execute a select query each time it fires.
It runs perfectly for sometimes but eventually it will hit the "Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding." exception after sometime. This happens very randomly.
I run a trace in the sql profiler and see DBCC shrinkdatabase started around the time and used quite a lot of time but it is for another database on the same server.
I wonder if the shrinkdatabase action will slow down the sql server and is it possible for it to cause my query timeout?
The short answer would be yes but there are a lot of different things happening on the machine when you run the shrink database command which would all contribute towards slow queries.
There would be high Disk I/O when the data in the files are being re-arranged
Since the data has been re-arranged you would most likely have fragmentation on the indexes which could slow down your queries.
The operation is also very CPU intensive
You can get a lot of information on the shrink process on this page http://sqlmag.com/sql-server/shrinking-data-files
On a client is being raised the error "Timeout" to trigger some commands against the database.
My first test option for correction is to increase the CommandTimeout to 99999 ... but I am afraid that this treatment generates further problems.
Have experienced it ...?
I wonder if my question is relevant, and/or if there is another option more robust and elegant correction.
You are correct to assume that upping the timeout is not the correct approach. Typically, I look for log running queries that are running around the timeouts. They will typically stand out in the areas of duration and reads.
Then I'll work to reduce the query run time using this method:
https://www.simple-talk.com/sql/performance/simple-query-tuning-with-statistics-io-and-execution-plans/
If it's a report causing issues and you can't get it running faster, you may need to start thinking about setting up a reporting database.
CommandTimeout is a time, that the client is waiting for a response from server. If the query is run in the main VCL thread then the whole application is "frozen" and might be marked "not responding" by Windows. So, would you expect your users to wait at frozen app for 99999 sec?
Generally, leave the Timeout values at default and rather concentrate on tunning the queries as Sam suggests. If you happen to have long running queries (ie. some background data movement, calculations etc in Stored Procedures) set the CommandTimeout to 0 (=INFINITE) but run them in a separate thread.