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
Related
Am doing some POC with real-time scenarios for SaaS product to handle high volume of message, this will reach peak within few seconds(send/process) and listener side processing message then storing that computed data into Azure SQL Database(Separate Elastic Pool, 100 eDTU with Standard subscription), to mimic this am sending & processing message in parallel with few nodes and threads, in this case am facing some slowness in first few seconds of database operation when DTU reached maximum level the query execution is normal
Is this expected behavior?
What will happen if executes query during scaling of DTU?
How to avoid this?
When you scale up or down the service tier of an Azure SQL Database open transactions are rolled back, server logins may be disconnected, query plans may vary because the number of threads available for query changes, and the data cache and query cache will be cleared.
Since the data cache is empty, the first time you run a query it has to do a lot of physical IO, memory allocation raises and it's slow. You may take a look at queries performing slow and they may be showing the PAGEIOLATCH_SH and MEMORY_ALLOCATION_EXT waits and that corresponds to pages being pulled from disk to the buffer. The second time you run the query the data is stored on the data cache and it runs faster.
If the database faces high DTU usage for a good period of time throttling may see connection timeouts and poor performance on queries.
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.
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 been facing performance issues in the production server; and while reading it about on internet I came across #Brent Ozar article about wait stats.
I want to try that but I am not sure how safe is it to run. My production environment is constantly occupied with SSIS jobs and I don't want to kill any job or server. So, I have few questions
Is it safe to run when queries or SQL Jobs are running on server
DBCC SQLPERF("sys.dm_os_wait_stats",CLEAR);
DBCC SQLPREF("sys.dm_os_latch_stats",CLEAR);
What is the difference between update stats and clearing wait stats?
Clearing wait stats has no affect on performance of SQL Server. It would just remove information related to accumulates wait stats. Now you should have a valid reason to do it and believe me lot of DBA's and SQL Server users do it quite often when troubleshooting performance issue. Only issue is that you loose valuable information about wait stats. But there is a way to get over with it before clearing wait stats run sys.dm_os_wait_stats and get current output of wait stats now clear it and start your monitoring. Atleast you would have statistics before clearing.
•What is the difference between update stats and clearing wait stats?
They both are not related to each other in any way. Statistics (one which you are referring via update stats) is distribution of data. It is how SQL Server data is distributed and is used by SQL Server in cardinality estimation and helps optimizer to prepare cost bases GOOD plan for a query. Clearing wait stats(statistics about on what resource the query was waiting) would not affect SQL Server data distribution statistics.
We have a Windows Server 2003 (x64) running as a Database server.
The Database is equipped with 32GB of RAM
Usually the Database memory usage (Task Manager) is between 5-10%.
However sometimes the Database shoots up suddenly to 100% and remains there, randomly and without any changes to code or executions.
All sort of research, paid or by me, has pointed to a single stored procedure.
When the database is 100%, disabling this procedure, will bring the database back to normal.
Now this sounds quite obvious but here is the strange part.
The stored procedure is optimized and the memory usage (from execution plan) is 0.01, which is extraordinarily good. Normally executing the stored procedure will return the resultset instantaneously. I also paid a RackSpace Fanatic Support DBA to look over this, and he said that he sees no problem with the stored procedure.
Now the extra wierd bit.
Running the SP is instantaneous.
When DB is 100%, running the SP, keeps on executing for minutes upon minutes.
Disabling the SP, sends the DB down to 5-10%.
Although the SP is enabled, DB is 100%, if I open a new query window and run the EXACT code from the SP, but as a query, not as a SP, the results are returned INSTANTANEOUSLY again
So, although at first glance, it sounds that the SP needs optimization, the actual code in the SP is not a problem.
I am desperate!
The execution plan can change depending on input parameters to the SP and the size of the result set.
You could try to add WITH RECOMPILE to the stored procedure to get a fresh execution plan for every call. It will make it a little bit slower but sometimes SQL Server gets stuck with a unusually bad execution plan for the majority of the queries and a recompile helps in those scenarios.
Profiler:
SQL Server comes with a great tool called Profiler which lets you see in real time the queries that are running on the server. You should run the profiler and find out what is actually happening and use that to find the culprit.
There are 4 measurements for Queries: Memory, CPU, Reads, Writes. The SQL statements that take up a lot of these (individually or combined), and are called with high frequency are the best candidates for optimization.
Once you run the profile and capture the output, you should be able to identify the items for optimization. You can then run the SQL Statements, review the execution plans and perform the necessary optimization on it.
(edit: added content)
It could be that it is not the statement itself that is not optimal, but some locking / blocking / deadlocks that could cause this. There may be something else running on the server at the same time that is taking up the resources needed for this SP and is causing the spike in CPU.
Read up on Profiler:
http://msdn.microsoft.com/en-us/library/ms187929.aspx