I got the warning message
The query had to wait xx seconds for MemoryGrant during execution
from the SQL execution plan. May I know what are the reasons/possibilities that would cause this warning message to appear?
Is it due to system memory leak or waiting for others pending SQL queries to be finished?
I extracted the query from SQL profile which is generated from Entity Framework(Linq) and run in SSMS 2019.
Related
I have some query, that run from client and have 5 sec timeout.
In most cases query work faster then 1 second, but sometimes it got timeout after 5 sec and the query execution does not start.
I added a message at the beginning of the procedure that it is running, but even that is not saved in the database.
I ran a profiler trace and this is what it shows
I also turned on the blocked process report with paramert 4 sec, but i don`t see any blocking processes in that time (17:29-17:30).
How to investigate this problem?
What is the difference between cancel execution in SSMS and using kill(spid). In testing, I've discovered that when you cancel an execution, using kill (spid) with statusonly returns the error that the rollback operation is not in progress.
It's probably applicable to all recent versions of SQL Server, but in my case I'm using 2017. SSMS is V18.
KILL will rollback a transaction, cancelling the execution of a command will stop the query at the soonest opportunity and will not automatically roll it back.
We are using dbeaver quite happily with Snowflake back end but I can't execute queries that last around 5 minutes or more.
It looks like there is sometimeout somewhere and the execution seems cancelled by DBeaver.
The error message is "SQL Error [604] [57014]: SQL execution canceled"
Any idea how I could instruct DBeaver to wait for whatever it takes?
This is probably because the STATEMENT_TIMEOUT_IN_SECONDS parameter has been set to cancel all queries after they run for 5 minutes or more.
You can check what it is set to by running this in dbeaver.
show parameters like '%STATEMENT_TIMEOUT%' in session;
We have BizTalk 2016 running on SQL Server 2016 AlwaysOn.
The SQL Server Agent Job MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb is doing its thing but after some hours it fails. Sometimes 10 hours sometimes 90 hours or anything in between. I know, the job is designed to run forever and in a case of an error restarts itself within a minute. But I would like to know the actual error message for this failed job. The job history is not helpful because the job log entry is truncated.
A failover is not happening. The question is: WHY is this job failing and ultimately: how do I stop it from doing that?
I have set-up the extended monitoring of the failing step and it revealed, that the job failed because of a deadlock and it was chosen as the deadlock victim. So now is the question, why is there a deadlock? Is MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDbknown for deadlock issues?
Check the documentation at Description of the SQL Server Agent Jobs in BizTalk Server, it says:
Important At first, the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job status icon displays a status of Success. However, there will be no corresponding success entry in the job history. If one of the jobs in the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job fails, a failure entry appears in the job history and the status icon displays a status of Failure. The job will always display a status of Failure after the first failure. To verify that the other BizTalk Server SQL Server Agent jobs run correctly, check the status of the other BizTalk Server SQL Server Agent jobs.
Hope this answer your question.
When I try to run crystal reports the following Error is appears:
Transaction (Process ID 159) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction
Note: Report is connect directly to stored procedure.
This sounds to me like it's a SQL Server issue and not Crystal. The query that you are executing is causing a deadlock situation. Try running SQL Profiler while executing your report and see what's causing the deadlock.