I've hunted high and low over the years about WSUS and all anyone says is it is slow when doing things like a reset and there's no way to gauge progress, stop it (without the update to singleton data) and so on.
My own WSUS has always had major SQL blocking issues whenever I reset it.
Digging deeper, the SQL server appears to be seriously struggling with process blocking see pic.
When you look at what is causing the blocking, it is a variety of CREATE PROC statements with the ChildEulas one being a major culprit.
So is it that the reason resets are soooooo slow is that the reset is having to drop/re-create the stored procedures for each and every update in the DB and throwing in blocking makes it absolutely ridiculous.
Can we re-write the reset routine to stop it dropping/creating the stored procs and make it lightning fast?
I tried killing the blocking process whenever it was a create proc statement (as the proc was already actually still there, presumably in a transaction) but it keeps halting the WSUS service altogether.
Related
I created a stored procedure which sends an email and accidentally called the stored procedure within itself creating an endless loop. Within a few seconds of executing the stored procedure I realized what I had done and fixed the loop, but it had already created 517 processes. I killed all the SPID's but they are stuck in a KILLED/ROLLBACK state.
This code shows me the processes:
select session_id,handle.percent_complete, *
from sys.dm_exec_requests handle
outer apply sys.fn_get_sql(handle.sql_handle) spname
where cast(handle.start_time as date) = '2022-01-10'
spname.text is showing 'xp_sysmail_format_query' for all the SPID's. It's been two days, and all 517 processes have been stuck in this rollback state with 0% progress. We are still able to use all our business applications and execute queries, with the exception of EXEC msdb.dbo.sp_send_dbmail which, when starting even a test email, gets stuck executing and has to be cancelled. This is not good because any auto generated email warnings will not be sent, and all other sql email functions are blocked. I'm not sure what other jobs are being blocked at this time.
This is a huge problem and I cannot find a solution. I've read every post I can find about this. I've tried everything I can think of except restarting the SQL server. Some posts state that restarting the SQL server can fix this and some state not to restart it or that the tasks will just resume in the killed/rollback state when restarted. I tried killing the spids again with statusonly but that just informs me that they are in a rollback state with 0% complete.
Should I restart the server and will this fix anything? Is there another solution other than restoring the DB to a backup that is more than 2 days old and losing all the work the entire business has done in the last couple days?
Any assistance will be greatly appreciated.
As robust as it is, sometimes (fortunately rarely) SQL Server leaves us no choice when killing a process to adopt the IT mantra of turning it off an on again when the rollback does not complete in a timely fashion.
This can be more prevalent when a transaction enlists external methods or functions, email is notorious for this inparticular.
As unwelcome as it is, it's often the least-expensive in terms of time and should be considered an option soon in the diagnosis process when the low-hanging fruit options have been exhausted.
One of the session that is executing a stored proc from an application is stuck in the killed\rollback phase. Arguably, it shouldn't be this long for the sproc to rollback and it has been stuck there for an eternity. Basically, the sproc is a bunch of select with unions and I am curious as to why this is holding up that long. As far as the waits are concerned below is a snippet of what I see that it is waiting on. I would like to understand how am I going to get rid of this w/o restarting SQL services and most importantly what basically can be done in order to avoid this situation either from the application side or from the SQL side. Let me know if anything else is needed. Also, these stored procedure is using [SalesForce] as linkedserver using DBAmp to fetch the data...would this be a cause and how to overcome the same.
Depending on how long an eternity is here, it's possible it's hung forever.
I previously worked in an environment where we routinely pulled data into SQL Server from a mainframe application. Periodically, the mainframe would unexpectedly terminate a connection, but would not communicate anything back to SQL Server, which would happily sit in an 'Executing' state waiting for the query results. The next day, when the same job would run, the not-executing-executing-query would block the new instance and throw an error.
KILLing the undead connection would allow the new instance to run, but the old instance would stick in KILLED\ROLLBACK until we restarted SQL Services.
Since the zombies weren't interfering with anything, we'd usually let them sit until the monthly maintenance window.
Before implementing this work-around, on several occasions we had our mainframe server engineers verify for us that as far as the mainframe was concerned there really was no active connection. You should check the SalesForce side and see if there's any activity there.
I am trying to resolve a deadlock issue regarding a SQL transaction (which is in a stored procedure called via LINQ-to-SQL). I used SQL Server Profiler and see that the SP is deadlocking on itself.
My client is calling a WCF method in rapid succession, which in turn calls the SP which causes a deadlock.
I have tried setting all the various SQL Server isolation levels as well as trying to set the WCF ConcurrencyMode = Single.
I continue to have many deadlock 'victims' and I am losing insert data as a consequence.
Has anybody solved this kind of problem?
Kind regards,
NickV
To get details of the deadlock, switch traceflag 1204 on. Any time a deadlock occurs, the deadlock graph, including all the details on the contended resource and what the two processes were doing is written to the SQL error log. This really helps in finding the cases of the deadlock.
Keep transcations as small as possible. Do no unneccessary work in a transaction. Never begin a transaction then wait for user input. Ensure that queries within the transaction are as efficient as possible.
Access objects in the same order. If one proc updates tbl1 first, then tbl2 after, all other procs that use those two should use them in the same order. Done properly, this can prevent deadlocks completely.
Hope that helps
I'm just debugging this error which I have suddenly seem to have gotten when I'm writing a row to a table.
Timeout expired. The timeout period
elapsed prior to completion of the
operation or the server is not
responding. The statement has been
terminated.
Does it have something to do with transaction scopes? I was wondering if I create a transaction scope and I debug through and I literally stop the application in the middle of debugging before it's reached the end of the trasnaction scope - is there a chance it'll block the database?
If so, how do I unblock it?
NOTE - This might help, right now, I'm having trouble inserting a row in tables but have accessing and updating existing rows
UPDATE - Well I reset the SQL Server service and it seems to have done the trick. Still, I'm curious to heard how it could've locked in the first place - I do not want some part of my code to be doing that and happening in production.
If opening a DB transaction would lock the entire database, that would be massively disappointing. Generally speaking, SQL Server locks on a per-row basis and then escalates these locks as neccessary (I'm simplifying matters here significantly).
Each transaction has a timeout it's given to complete. If this time elapses and you nether commit nor roll back, you'll get that "Timeout expired" exception.
As far as "unblocking" goes, you don't usually have to worry. Everything's unlocked as soon as you close the connection.
I've tried to read an article on locks and deadlocks, and it just doesn't land, al the different kind of locks.
We're running 2 different processes which try to edit records in the same table.
The first process reads the new data and sends it to an external party and updates the status accordingly, the other one receives the receiveresults form the external party and updates the status accordingly.
Now we more and more get deadlocks (in which case one of the two is the victom and gets aborted). So far so good because you can anticipate on that, and try to rerun the statement, but then allways the same deadlock occurs.
So that's my first question: why does the same deadlock allways reoccur?
And second, is there a way to tell the dbms not to try and get an exclusive lock for a record (we update single records via a stored procedure) when another process is already reading and updating it, but 'wait at the side' till the other process is ready?
Or is that a much too simple thing to say about a deadlock?
and may be third, is there a way to ask LINQ to SQL which locks were causing the problem, so i get a little more insight of which parts of the process are causing the problem.
SQL Profiler is the best tool I've used to start trying to solve deadlock problems in SQL Server.
Start a trace:
On the Events Selection tab:
Uncheck all of the preselected events.
Check "Show all events".
Expand "Locks".
Check "Deadlock graph", "Lock:Deadlock", and "Lock Deadlock Chain".
Run the trace and capture the deadlock events.
View the deadlock events in SQL Profiler. The deadlock display is pretty good. You may still need to look at the raw XML to get additional details.
Using what you find from this first pass, may give you ideas on what to change, or suggest other events to trace in SQL Profiler.
As #Darryl Peterson indicates, SQL Profiler is a good tool to capture deadlock information. If you don't know when the deadlock will occur, you can set a SQL Server trace flag to capture the data.
DBCC TRACEON (1204)
When a deadlock occurs, information about the deadlock will be written to the SQL Server error log.
There are a number of ways to get a deadlock. Your first question "why does the same deadlock always occur" is probably a good sign. If the deadlock is repeatable, then you can catch it and fix it.
Regarding your second question, SQL Server is probably already telling one process to wait while the other completes. However, you can't avoid a deadlock by waiting. A deadlock is a situation where a process is trying to use a resource that is held by another process. But the other process is waiting for a resource that the first process is holding. Neither process will release a resource until it completes its work. Note that this is a simple explanation and there can be more complex deadlock conditions. The point is that processes in the deadlock will never be able to complete.
Once you learn more about the processes involved in the deadlock, you should be able to take steps to avoid it.