I have two sessions hanging in killed/rollback state. These are cancelled selects to PostgreSQL by openquery. What can I do with this? KILL UOW does nothing because I have transaction GUID = '{00000000-0000-0000-0000-000000000000}'.
More disturbingly, the server looks like it's constantly consuming RAM and won't stop.
Kill them on Postgre side if they're still running. Also, not sure what UOW means. As last resort, i think you have to restart the server :/
Related
I am using a SQL Server database with Nodejs. I am using connection pool to perform various queries. When I run sp_who2, I can see that the there are almost 20 processes which have status sleeping and command awaiting command.
Should I go ahead and delete these processes? I read in some other post that this happens when you create a transaction in SQL Server but do not close / commit / rollback that transaction. I do not see any point in my application where I did not commit or rollback transaction on error. So I am not sure where the error came from.
I have a feeling that leaving those processes there is going to cause query timeout issues in the future. Is there a way to see what query caused the sleeping but waiting state?
I normally see many sleeping connections. I consider it normal. If you have sleeping connections with open transactions and locks, then you need to investigate. I would try to identify the host and PID holding the lock. In some cases the resolution is a polite talk with the person responsible for not closing their transaction.
A connection pool is a pool of connections to SQL Server. They will be idle and sleeping unless they are in use. Generally, there is a timeout for the connections in the pool. (For example, if you look at the ODBC control panel, the connection pooling tab will generally show a 60 second timeout. It might also always keep a minimum number of idle connections.) Check if you have a minimum number of idle connections. Once you know your timeout, verify that the connections are timing out as expected...eventually. If not, I would look for a connection leak or a connection pool issue. Is the application releasing the connection when done? Does GC have to run before the connection goes away?
Years ago there was an issue where a connection could go back into the pool with an open transaction. It was not until the connection was being prepared for reuse that it was finally reset. This issue has been fixed.
Another past issue was a broken connection. For example, if the SQL Server was rebooted, all idle connections are broken. However, it was not until the connection was requested that this was checked. A connection failure timeout was required for each connection in the pool before it was replaced. This was a PITA.
My application executes many queries and it is sure that all connections are closed well. PgAdmin shows many queries have gone "Idle in transaction" and finally DB becomes unresponsive. Is there a way to get the query caused to be 'Idle in transaction' ? Or any other tool which can track it ? Postgres 8.1 is used.
Edit: Connection Pool is used. Also, the state ' in transaction' got cleared after couple of minutes. Then, if any connection is opened, how this get cleared ?
If you check information in Postgres documentation regarding this:
idle in transaction (waiting for client inside a BEGIN block), or a
command type name such as SELECT. Also, waiting is attached if the
server process is presently waiting on a lock held by another server
process
I would suggest following things:
enable logging of "long queries" using log_min_duration_statement
and log_lock_waits option in postgresql.conf in Error Reporting and Logging section
check Lock Management parameters of postgresql.conf configuration file,deadlock_timeout option in particular
check Lock Monitoring article on Postgres Wiki and pg_locks view in Postgres
This is clean signal, so some about closing transaction and closing sessions is wrong in your application. The queries works well. Check your application - unexpected exceptions, fails, ... Some applications are pretty buggy - usually it is pretty serious problem. Orphaned transactions block VACUUM and block reusing connections.
I have implemented SQL Server Service Broker with error handling according to this article by Remus Resanu.
When I ran the process and the activation script got kicked off but never stopped processing. According to the SQL Server log file it looks like I have a typo in my error handling and it is now stuck in an infinite loop.
I have tried to kill the process using kill <pid> but I get the message Only user processes can be killed. I have also tried restarting the server but the activation script would start again.
How do I kill the runaway activation process?
I was not able to find a solution through google/bing search. I eventually remembered that we enabled the Service broker through a SQL command, so I tried disabling it and that seems to have worked:
ALTER DATABASE dbname SET DISABLE_BROKER;
It looks like undocumented feature. If activated procedure do not issue END CONVERSATION it keeps restarting in an infinite loop. So, to stop it you need to make it successfully run END CONVERSATION of any dialog. If the queue gets disabled due to poison message detection you need to drop it to stop activation proc - no need to reset broker. I did not found either solution to this problem out there so I played with it a bit and hope this gives you a hint.
I have a batch process that generate one linked server over huge Excel files to fetch data into SQL Server 2012
Sometimes the process is locked by a wait type "OLEDB"
I can't find the root ause but my biggest problem is that I can't kill the process that has the wait_type OLEDB
I have try
KILL spid
Not works, never kill the spid.
SPID 90: transaction rollback in progress. Estimated rollback completion: 0%. Estimated time remaining: 0 seconds.
ALTER DATABASE [DataMigration] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
But never finish (due PRINT_ROLLBACK_PROGRESS)
If I look into the process, I see the file that cause the block, but I don't know how solve the issue
SELECT * FROM SYSPROCESSES where spid=90
-There is any way to kill this process without restart the servers?
-How can avoid the wait type OLEDB? the same file in the same location usually works fine, the process hangs only some times.
This is quite simple. OLEDB as a wait type often indicates some wait on another Server. This is also the reason why you can't kill the process. OLEDB is often (not always) used as a wait type for connections between SQL Server instances.
You kill the connection on your server, but if the process is running on another instance/linked server it will run there too. It will kill the process after the process on the other instance is finished.
So much to the bad news. The good news for you is, that you easily can find the query which runs on another linked server using this query:
SELECT spid, waitresource
FROM sys.sysprocesses
WHERE spid = <yourKilledSpid>
Just filter it for the spid you try to kill. The waitresource will indicate the remote server including the spid on the remote server. Go to the remote server and kill the spid there too. Your connection will immediately be killed/rolledback. Hopefully this solves your issue.
You can additionally try to take a look at the waiting_tasks. Maybe you'll see something helpful like a blocking resource in there.
SELECT *
FROM sys.dm_os_waiting_tasks
We have a process that was running for 4 hours. Because it was running so long, it was causing other issues in the database, so it was decided to kill the process.
Now, the process is in a suspended state. It also states that it's being blocked by itself after querying sp_who2.
In activity monitor, here's the waitresource information:
objectlock lockPartition=0 objid=xxx subresource=FULL dbid=2 id=lockyyyy mode=X associatedObjectid=xxx
You'll notice that the objid and associatedObjectId are the same value.
Querying the sys.objects table shows NO results for that object id.
Is Sql Server waiting for a lock on an object that doesn't exist anymore? How can I get rid of this process without restarting Sql Server? (our DBA's are not responding to help requests).
Keep in mind, this is a test environment, but it is stopping all development/testing because we are unable to deploy any changes to our database, because one of those changes is affecting one of the objects that the process was accessing.
Edit: more info from activity monitor:
Command = 'KILLED/ROLLBACK'
TASK STATE = 'SUSPENDED'
I have experienced this may times. When you kill a large INSERT/UDPATE/DELETE statement, it can take hours to recover (if it ever does recover) from this state.
run kill <spid> with statusonly.
It will give you a percentage and estimated wait time of the ROLLBACK process.
Sometimes it says 0% or 100% and 0 estimated time. If you are patient, it may recover eventually. If you restart the server, the rollback process will be completed offline, and the database will show IN RECOVERY state and usually will be faster than waiting the server to recover itself.
Be aware that users won't be able to use the database until the recovery process ends, but if the SPID in KILLED/ROLLBACK state is locking other process, it might be an option to restart.
Well, this seems to be lock due to parallel processing inside the tempdb.
You can try kill [processid] if you have the rights to?
Another way is to get more detailed process information with this:
SELECT * FROM sys.sysprocesses WHERE spid = YOURSPID
As the Process runs in DB:2 try this:
SELECT * FROM tempdb.sys.all_objects WHERE object_id = OBJECTID
As I've seen, you have edited your question. If the Spid is in KILLED/ROLLBACK you have to wait until your transaction is rolled back. After that the process will be killed and removed. You can't do anything else, as the transaction security must be given.